-
Notifications
You must be signed in to change notification settings - Fork 139
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
Cannot access EEPROM on some bootloader/part combinations #970
Comments
The AVR8X family refer to the new AVR DA/DB family, right? I intend to get one of the Curiosity board with the DA or DB parts. Not so sure if that is useful for the testing here. If I have the affected parts, what should I do to reproduce what you mentioned? I think I have at lease the ATMega8515 part and maybe some other parts. Step 1: to burn the bootloader. Which bootloader to choose for ATmega8515? Step 2: run your test
|
Well, this issue is about protocol incompatibility between AVRDUDE and some parts for a typical My test makes AVRDUDE pretend it is a certain part (ATmega161 in this instance) but actually uses a different board (urclockUSB, an ATmega328p board) with a bootloader that, like optiboot, only uses STK_PROG_PAGE and STK_READ_PAGE for EEPROM. Needs If you want to test with a real board, I recommend you try the optiboot bootloader for the ATmega8515 that has EEPROM r/w enabled. You may need to compile that yourself from source, burn it onto the MCU and set the fuses for a bootloader of the right size (optiboot with EEPROM r/w will probably be 512 or 1024 bytes). You can test with the shorter sequence that only tries to store 13 bytes to EEPROM (14 in windows?):
I know optiboot well and expect it to behave as above provided EEPROM page size of the ATmega8515 in your I don't think optiboot caters for the new AVR DA/DB family yet, but if their EEPROM page size remains 1 in I know exactly what options exist to make this protocol incompatibility go away in AVRDUDE, and neither is particularly hard to implement, but it may take some time until the right approach is agreed on and finds its way into AVRDUDE. |
I believe AVRDUDE works well with typical Arduino boards (limited to certain MCU type like ATmega328P, ATmega32U4, ATmega2560, ATMega4809, etc) with the official Arduino bootloader. On the other hand, Optiboot (https://github.com/Optiboot/optiboot) is more widely available for many AVRs. So supposedly the user may encounter issues when using EEPROMs if they use the affected parts. I guess this is a niche use case as most of the users may not need to access EEPROMs. But yes it is still good to fix avrdude in this case.
Looks like there is a working solution here. |
BTW, I do not know much of the internal working of avrdude (I am not a programmer myself. My initial intention is to use avrdude as a test bed to test libusb, hidapi and libftdi. I also test OpenOCD because it relies on libusb, hidapi and libftdi as well). On the other hand, I am also interested in knowing more about AVR as I am interested in MCUs as well, now mainly in STM32 and Microchip PIC/AVR. I am more familiar with PIC but we (Travis and I) did get some support from Atmel last time when working on the libusbk project. So this dicussion is an interesting read. |
Not so sure if the bug report here is relevant or not (avrdude problem or bootloader problem). |
One more old issue related to EEPROM And a very old one (may or may not be valid now) |
OK, optiboot has supported EEPROM from at least 2016, I think. The current version 8.3 certainly does. Historically EEPROM access did not fit into 512 bytes, but it does now, I hear. |
@mcuee Thanks for unearthing AVR8X self-programming implementations (vvv useful) and for digging out other EEPROM related issues. None of these relate to this particular issue (though Issue no 421 is actually the same as Issue no 967). The issue here is a capability mismatch between compact bootloaders that only implement paged access and AVRDUDE's way of reading/writing EEPROM memories, which is correct but assumes the programmer can carry out (protocol) byte acccess. |
Yes I understand. What I am trying to say is that they probably should not use |
Correct. Actually, no one should :) As you have seen #940 argues
Correct. Yet, there are not many games in town. AVRDUDE has the likes of wiring, micronucleus, xbee. I would never call a new one I am still trying to figure out how AVRDUDE best could support generic bootloaders. And it remains unclear, whether my ideas of better bootloader support are something the AVRDUDE project is willing to entertain and, more importantly, accept. Main technical differences that I sense so far are that the AVRDUDE project seems to favour stand-alone chip and page erase in the bootloader code while I am reluctant to recommend bootloaders implement much more than atomic page erase and write (to save a few dozen code bytes in the bootloader). |
Valid and interesting comments by @dl8dtl
|
I can reproduce the issue as well.
|
Reading will not fail but the results are wrong.
|
OK, turns out that various bootloaders for which it is important to deal with EEPROM have solved this issue, particularly for those UPDI parts. Closing this issue |
@stefanrueger |
Unfortunately #1110 has issues with optiboot and it can not be merged even though it may help in solving this issue. |
Just wondering if you can get EEPROM write to work with your ATtiny1616 with current git using optiboot_x (with or without changing a_div = 1). Thanks. I know it has issues with Flash as mentioned in #1120. Somehow I can not get the optiboot_dx bootloader working for my avr128db48 Curiosity Nano anymore, even with the |
For example, for optiboot_dx, the latest git main (e14e5d2) will still have the same issue.
|
From #1110 (comment).
|
From #1110 (comment)
|
@stefanrueger |
@mcuee I (perhaps mistakenly) thought that optiboot_x and optiboot_dx can access EEPROM. Happy to stand corrected. How about I create a PR (sometime) that invokes paged access if programmer is for a bootloader |
@stefanrueger
Yes, that will be great. As mentioned in other threads, we may need to add the fuctionality to differentiate different capability of the bootloaders. We can always do that for ppular optiboot (stk500v1) first. In that case, we can decide which is the best access method for a paticular bootloader implementation. |
@MCUdude has a very nice test results summary here for optiboot_x and optiboot_dx, for git main.
|
#1121 (comment)
|
AVRDUE only invokes the programmer's *_paged_load() and *_paged_write() when the memory page size exceeds 1. Compact bootloaders (think optiboot et al) typically only ever implement paged memory access for flash and EEPROM. Hence, this leads to a clash of expectations for some parts. Example (using a bootloader with EEPROM r/w)
Flash. Affected parts are
ATtiny11
ATtiny12
ATtiny15
AT90S1200
AT90S4414
AT90S2313
AT90S2333
AT90S2343
AT90S4433
AT90S4434
AT90S8515
AT90S8535
. None of this matters as there won't be a rush of bootloaders for these (no SPM opcode).EEPROM. Affected parts are
ATtiny11
ATtiny12
ATtiny15
AT90S1200
AT90S4414
AT90S2313
AT90S2333
AT90S2343
AT90S4433
AT90S4434
AT90S8515
AT90S8535
ATmega103
ATmega163
ATmega161
ATmega8515
ATmega8535
ATtiny26
and all AVRX8 family parts. Here it isATmega161
ATmega163
ATmega8515
ATmega8535
and the AVR8X family parts that matter for bootloader, but for these AVRDUDE won't send paged memory access.Suggestions for solutions:
is_bootloader
in.conf
; AVRDUDE can then also invoke paged access if programmer "is_bootloader" and memory is flash/eepromarduino
) change the part's EEPROM page size to 16 or similar at their earliest convenience; can be slipped in when programmer is asked to read the signature; also makes for neater-sized chunks for EEPROM upload/download (but take care not to choose too big chunks lest WDT timeout is caught out by EEPROM write times)STK_PROG_DATA
andSTK_READ_DATA
) though to be realistic they might find it bewildering to have to implement different communication protocols for different parts and it's not efficient.Thoughts?
The text was updated successfully, but these errors were encountered: