Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arduino Nano Every EEPROM Regression from avrdude 7.3 #1899

Closed
mcuee opened this issue Aug 22, 2024 · 6 comments · Fixed by #1911
Closed

Arduino Nano Every EEPROM Regression from avrdude 7.3 #1899

mcuee opened this issue Aug 22, 2024 · 6 comments · Fixed by #1911
Labels
not our bug A bug elsewhere causes this

Comments

@mcuee
Copy link
Collaborator

mcuee commented Aug 22, 2024

From @askn37 here.

@stefanrueger

@MCUdude @askn37 @mcuee I still don't know what to do about the curiosity nano not erasing the page for EEPROM... Maybe we just leave the FW bug exposed.

As of 7.3, page erase was not used, so this could be considered a regression for Nano Every.

Testing /opt/local/bin/avrdude 7.3
Prepare "-cjtag2updi -P/dev/cu.usbmodem2301 -r -pm4809" and press 'enter' or 'space' to continue. Press any other key to skip
✅   3.288 s: fuse access: clear, set and read eesave fuse bit
✅   3.276 s: fuse access: set eesave fusebit to delete EEPROM on chip erase
✅   3.660 s: chip erase
✅  10.798 s: flash -U write/verify holes_rjmp_loops_49152B.hex
✅   4.529 s: flash -T write/verify holes_rjmp_loops_49152B.hex
✅   3.433 s: eeprom check whether programmer can flip 0s to 1s
✅   3.429 s: eeprom -U write/verify holes_pack_my_box_256B.hex
✅   3.567 s: eeprom -T write/verify holes_{the_five_boxing_wizards,pack_my_box}_256B.hex
✅   4.901 s: chip erase and spot check flash is actually erased
✅   3.302 s: spot check eeprom is erased, too
✅   3.436 s: usersig -T/-U write/read random_data_64B.bin

NVMCTRL in UPDI silicon does not have EEPROM page erase function. Normally you can write 0xFF anytime. You can erase 1/2/4/8 bytes or the whole thing. There is no known JTAG command for this.

The cause is EEPROM page erase, so don't use JTAG command for that. EEPROM can always be overwritten with 0xFF from 1 byte to page size. Nano Every, JTAG2UPDI and UPDI4AVR are such types.

FW that doesn't allow 0xFF overwrite may have its own trick to erase EEPROM page by overwriting with 0xFF internally.

As in 7.3, shouldn't EEPROM page erase be disabled by default and the -x option be used when needed?

Or.

The correct solution is probably to provide an alias driver like -c nevery_updi, check the name with strcat, and branch the exception. It would be even better if -r was turned on automatically.

@mcuee mcuee added the bug Something isn't working label Aug 22, 2024
@mcuee
Copy link
Collaborator Author

mcuee commented Aug 22, 2024

Behavior of current avrdude git main.

$ ./test-avrdude -e ../build_mingw64_nt-10.0-22631/src/avrdude.exe -d 2 -t. -p "-c jtag2updi -P COM5 -r -p m4809"
Testing ../build_mingw64_nt-10.0-22631/src/avrdude.exe 7.3-20240819 (1fe0857e)
Prepare "-c jtag2updi -P COM5 -r -p m4809" and press 'enter' or 'space' to continue. Press any other key to skip
✅   3.496 s: fuse access: clear, set and read eesave fuse bit
✅   3.471 s: fuse access: set eesave fusebit to delete EEPROM on chip erase
✅   3.750 s: chip erase
✅  11.429 s: flash -U write/verify holes_rjmp_loops_49152B.hex
✅   4.790 s: flash -T write/verify holes_rjmp_loops_49152B.hex
✅   4.008 s: eeprom check whether programmer can flip 0s to 1s
❌  38.948 s: eeprom -U write/verify holes_pack_my_box_256B.hex (failed command below)
$ ../build_mingw64_nt-10.0-22631/src/avrdude.exe -qq -c jtag2updi -P COM5 -r -p m4809 -Ueeprom:w:./test_files/holes_pack_my_box_256B.hex
❌  38.876 s: eeprom -U write/verify the_quick_brown_fox_256B.hex (failed command below)
$ ../build_mingw64_nt-10.0-22631/src/avrdude.exe -qq -c jtag2updi -P COM5 -r -p m4809 -Ueeprom:w:./test_files/the_quick_brown_fox_256B.hex
✅   3.671 s: eeprom -T write/verify holes_{the_five_boxing_wizards,pack_my_box}_256B.hex
✅   5.122 s: chip erase and spot check flash is actually erased
✅   3.464 s: spot check eeprom is erased, too
✅   3.656 s: usersig -T/-U write/read random_data_64B.bin

One or more AVRDUDE "-c jtag2updi -P COM5 -r -p m4809" tests failed. Do you want to retry this particular test? (y/n): n

@mcuee mcuee changed the title Arduino Nano Every Regression from avrdude 7.3 Arduino Nano Every EEPROM Regression from avrdude 7.3 Aug 22, 2024
@stefanrueger
Copy link
Collaborator

Is it the Arduino Nano or the Curiosity nano? Why isn't there a log file with the -vvv output?

@askn37's analysis is that EEPROM page erase does not work with this board. Even though there have been some discussion around this problem elsewhere, no clear picture has evolved of the extent of what parts/boards are affected. Is it all UPDI parts? Is it jtag2? jtag3? Only the Curiosity nano's FW? This would be helpful for addressing this issue.

I suspect, but do not know, that it's not our bug, yet the issue boldly asserts it is our bug.

It is out of question to go back to 7.3 where only Xmegas were using page erase, but not UPDI parts.

There is a workaround: one can use -D to switch off page erase and (if needed!) -e.

@askn37
Copy link
Contributor

askn37 commented Aug 23, 2024

@stefanrueger

From what I've observed, this EEPROM page erase issue is mainly related to PM_UPDI + jtagmkII.c (over serial communication).

Why it matters: ATMEL/Microchip official debuggers do not implement this combination. Historically, this was first conceived in the JTAG2UPDI open source implementation.

At the time, support for PDI+JTAG2 (XMEGA) was already there, so the protocol was borrowed from there. The original JTAG2 rules are restrictive and there is no UPDI-specific device descriptor (unlike JTAG3), so you can't expect full support right from the start.

@stefanrueger
Copy link
Collaborator

@askn37 Thanks for a crisp and clear answer. I now understand a lot better what's going on. So, looks like jtagmkII wasn't sufficiently back-fitted for UPDI when they came out. For the time being I suggest users of jtagmkII need to specify -D and, if needed, request -e. This is not the only problem jtagmkII has with newer parts (but also apptable and boot memories of XMEGAS). So an independent review of jtagmkII is needed similarly to the one that was recently carried out for jtag3.c.

@stefanrueger
Copy link
Collaborator

Looking at the details, I think it is not our bug if nanoevery FW does not offer a page erase command for non-flash memories.

Nevertheless, PR #1911 does two relevant changes affecting the Nano every:

  • AVRDUDE will no longer issue a page erase for EEPROM memories (both PDI and UPDI parts irrespective of programmer)
  • Terminal pgerase eeprom <addr> and pgerase usersig <addr> will both be emulated by writing 0xff for jtagmkII

The first one might cause regressions (is there programmer with page erase serves EEPROM that need be erased before writing?) but will speed up -U eeprom write by foregoing eeprom page erases

@stefanrueger stefanrueger added not our bug A bug elsewhere causes this and removed bug Something isn't working labels Aug 24, 2024
@askn37
Copy link
Contributor

askn37 commented Aug 24, 2024

The results are good.

Nano Every

Testing ../build_darwin/src/avrdude 7.3-20240824 (943ee419)
Prepare "-cjtag2updi -P/dev/cu.usbmodem2301 -pm4809 -r" and press 'enter' or 'space' to continue. Press any other key to skip
✅   3.280 s: fuse access: clear, set and read eesave fuse bit
✅   3.296 s: fuse access: set eesave fusebit to delete EEPROM on chip erase
✅   3.664 s: chip erase
✅  10.913 s: flash -U write/verify holes_rjmp_loops_49152B.hex
✅   4.557 s: flash -T write/verify holes_rjmp_loops_49152B.hex
✅   3.434 s: eeprom check whether programmer can flip 0s to 1s
✅   3.446 s: eeprom -U write/verify holes_pack_my_box_256B.hex
✅   3.560 s: eeprom -T write/verify holes_{the_five_boxing_wizards,pack_my_box}_256B.hex
✅   4.922 s: chip erase and spot check flash is actually erased
✅   3.307 s: spot check eeprom is erased, too
✅   3.477 s: usersig -T/-U write/read random_data_64B.bin
./test8 -e ../build_darwin/src/avrdude -r1 -a-P -a/dev/cu.usbmodem2301 -a-r jtag2updi m4809
Reading 49643 bytes for multiple memories from input file bak-jtag2updi-m4809.hex
Writing 256 bytes to eeprom
Writing | ################################################## | 100% 0.21 s 
Reading | ################################################## | 100% 0.05 s 
256 bytes of eeprom verified
Writing 49152 bytes to flash
Writing | ################################################## | 100% 38.04 s 
Reading | ################################################## | 100% 7.53 s 
49152 bytes of flash verified
Writing 10 bytes to fuses, 10 bytes written, 10 verified
Writing 1 byte (0x00) to fuse0/wdtcfg, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse1/bodcfg, 1 byte written, 1 verified
Writing 1 byte (0x7E) to fuse2/osccfg, 1 byte written, 1 verified
Writing 1 byte (0xF6) to fuse5/syscfg0, 1 byte written, 1 verified
Writing 1 byte (0xFF) to fuse6/syscfg1, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse7/append, 1 byte written, 1 verified
Writing 1 byte (0x18) to fuse8/bootend, 1 byte written, 1 verified
Writing 1 byte (0xC5) to lock, 1 byte written, 1 verified
Writing 64 bytes to userrow/usersig
Writing | ################################################## | 100% 0.10 s 
Reading | ################################################## | 100% 0.01 s 
64 bytes of userrow/usersig verified

Avrdude done.  Thank you.
test8: m4809 initialised

JTAG2UPDI

Testing ../build_darwin/src/avrdude 7.3-20240824 (943ee419)
Prepare "-cjtag2updi -P/dev/cu.usbserial-230 -pm4808" and press 'enter' or 'space' to continue. Press any other key to skip
✅   0.861 s: fuse access: clear, set and read eesave fuse bit
✅   0.906 s: fuse access: set eesave fusebit to delete EEPROM on chip erase
✅   0.958 s: chip erase
✅   4.677 s: flash -U write/verify holes_rjmp_loops_49152B.hex
✅   2.440 s: flash -T write/verify holes_rjmp_loops_49152B.hex
✅   0.963 s: eeprom check whether programmer can flip 0s to 1s
✅   0.958 s: eeprom -U write/verify holes_pack_my_box_256B.hex
✅   1.044 s: eeprom -T write/verify holes_{the_five_boxing_wizards,pack_my_box}_256B.hex
✅   2.544 s: chip erase and spot check flash is actually erased
✅   0.904 s: spot check eeprom is erased, too
✅   1.015 s: usersig -T/-U write/read random_data_64B.bin
./test8 -e ../build_darwin/src/avrdude -r1 -a-P -a/dev/cu.usbserial-230 -a-r jtag2updi m4808
Reading 49643 bytes for multiple memories from input file bak-jtag2updi-m4808.hex
Writing 256 bytes to eeprom
Writing | ################################################## | 100% 0.07 s 
Reading | ################################################## | 100% 0.06 s 
256 bytes of eeprom verified
Writing 49152 bytes to flash
Writing | ################################################## | 100% 13.27 s 
Reading | ################################################## | 100% 9.41 s 
49152 bytes of flash verified
Writing 10 bytes to fuses, 10 bytes written, 10 verified
Writing 1 byte (0x00) to fuse0/wdtcfg, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse1/bodcfg, 1 byte written, 1 verified
Writing 1 byte (0x7E) to fuse2/osccfg, 1 byte written, 1 verified
Writing 1 byte (0xF6) to fuse5/syscfg0, 1 byte written, 1 verified
Writing 1 byte (0xFF) to fuse6/syscfg1, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse7/append, 1 byte written, 1 verified
Writing 1 byte (0x18) to fuse8/bootend, 1 byte written, 1 verified
Writing 1 byte (0xC5) to lock, 1 byte written, 1 verified
Writing 64 bytes to userrow/usersig
Writing | ################################################## | 100% 0.04 s 
Reading | ################################################## | 100% 0.02 s 
64 bytes of userrow/usersig verified

Avrdude done.  Thank you.
test8: m4808 initialised

The only official JTAG2 clone still on the market is probably the Arduino Nano Every. At the time, the only UPDI-type PGM was JTAG2UPDI. The USBasp clone was a no-no. JTAG2 clones are easier to implement because they can be implemented with USB-CDC and can use any VID:PID.

But now we have serialupdi, which is obviously more popular. The downside is that you have to wait for pymcuprog and/or AVRDUDE updates every time a new part is released.

On the other hand, AVRDUDE's JTAG3 was recently improved to allow any VID:PID, so nEDBG clones with USB-HID might become popular. If you can do it with WCH552G, you can make a PGM for $2-5 (if you're familiar with 8051 clones).

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not our bug A bug elsewhere causes this
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants