Closed askn37 closed 10 months ago
Thanks for your code snippets @askn37.
I had not known that the terminal times out with jtagmkii_updi
programmers. Neat.
I don't think further development of the arduino
programmer is useful. It has so many deficiencies, almost all of which can be remedied by using urclock
instead of arduino
. In the long run it might be better to make arduino
another id of the urclock
programmer and remove the code arduino.c
.
The userrow/bootrow is a neat trick. I wonder what the limitations are, eg, will using a linear 16-bit address space work with larger parts?
@stefanrueger
"urclock" is a good project, but I haven't touched on it yet as the whole thing is too big for me as I am only focusing on AVR-LIBC+PM_UPDI devices. That is a challenge for the future.
(Personally, I also use many-to-one single-wire RS485 and high-speed synchronous serial, so I prefer a single source code that is easy to modify and extend.)
USERROW/USER_SIGNATURE also exists in XMEGA, but is outside of the flat address space and requires the STK500v1 extension. PM_UPDI is fully accessible with a 24-bit flat address and can be read with Cmnd_STK_READ_PAGE + EorF
. Rest assured, there are no other AVR chips with USERROW.
You can only write to USERROW if you are using his NVMCTRL version 0, such as "optiboot_x". The 0.5KiB bootloader leaves little room to add code for other versions. Therefore, we restricted the patch to the read direction. This is probably enough to see inside the chip where ICSP is blocked.
"JTAG2UPDI" keepalive looks like a useful enhancement, please submit a PR, so it can be tested by the team.
The USERROW and BOOTROW trick is neat. It would be good if
Prepare PR for jtagmkII_term_keep_alive
.
There are at least two users who use -c jtag2updi
.
Reading USERROW by the bootloader is closely related to the fact that USERROW is write-only to locked devices. You need to install a user program to check if the data was written correctly, but it's a hassle to physically change the USB port every time. If this is read by the bootloader and the serial port connection is switched remotely (e.g. -xrtsdtr), you can simply use AVRDUDE
to complete the test, simplifying script/batch automation. This will help whenever new chips are released in the future.
P.S. I later realized that you can use the same trick to read sernum. However, paged_load doesn't pass, so it doesn't seem worth the trouble to fix it.
P.S. 2 Nano Every will time out unconditionally after up to 60 seconds due to firmware limitations. AVRDUDE cannot detect frame errors until an additional 60 seconds have elapsed. During this time, AVRDUDE is silent. AVRDUDE will eventually exit, but will also throw a malloc error if paged_load is already running. This is a known issue that cannot be avoided.
you can use the same trick to read sernum
Yes. It looks like that at least the UPDI parts can r/w most (all?) memory segments using a 24-bit address and one bootloader r/w routine. The uploader (avrdude -c urclock
) knows the mapping of fuses/lock bytes/memories to the single 24-bit address space of the part, so could be modified in a way that the bootloader would not even have to implement different routines for EEPROM and flash.
I have not yet started extending the urboot bootloader to XMEGA and UPDI parts. I kind of hoped (and still do) that some gifted programmer would continue the urboot project for modern parts. Urboot is vvv small, so with a bit of fair wind a version that is able to access all memories could fit into 256 bytes but I am sure that definitely would fit into 512 bytes.
Resolved in #1603 and #1604
The following three separate small patches were created for my own personal needs and may not be of interest to others. First of all, I would like to inform you that something like this exists. (I will think about whether to create a PR later)
One is the "JTAG2UPDI" keepalive. (for interactive mode) Previously, using JTAG2UPDI in interactive mode required disabling host timeout (on the JTAG2UPDI side).
One is the "Arduino compatible bootloader" keepalive. (for interactive mode)
One is to load USERROW and BOOTROW using an "Arduino compatible bootloader". This only works with PM_UPDI parts. USERROW and (and BOOTROW) are not present in any other parts, so they are unrelated. This only works with bootloader implementations that can read EEPROM. Writing is currently not possible. Even if it were possible, only a small number of bootloader implementations would be able to do it.