-
Notifications
You must be signed in to change notification settings - Fork 136
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
Comments
Behavior of current avrdude git main.
|
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 |
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. |
@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 |
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:
The first one might cause regressions (is there programmer with page erase serves EEPROM that need be erased before writing?) but will speed up |
The results are good. Nano Every
JTAG2UPDI
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). |
From @askn37 here.
@stefanrueger
As of 7.3, page erase was not used, so this could be considered a regression for Nano Every.
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 withstrcat
, and branch the exception. It would be even better if-r
was turned on automatically.The text was updated successfully, but these errors were encountered: