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

Cannot access EEPROM on some bootloader/part combinations #970

Closed
stefanrueger opened this issue May 19, 2022 · 26 comments · Fixed by #1141
Closed

Cannot access EEPROM on some bootloader/part combinations #970

stefanrueger opened this issue May 19, 2022 · 26 comments · Fixed by #1141
Labels
bug Something isn't working

Comments

@stefanrueger
Copy link
Collaborator

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)

$ yes hello, world | head -512c | avrdude -qq -p m161 -F -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:w:-:r
avrdude: Expected signature for ATmega161 is 1E 94 01
***failed;
***failed;
***failed;
...

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 is ATmega161 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:

  1. Wait for the Discussion Core SPM programmer: request for comments #940 to finish; one recommendation might be a programmer feature is_bootloader in .conf; AVRDUDE can then also invoke paged access if programmer "is_bootloader" and memory is flash/eeprom
  2. AVRDUDE programmers that are for bootloaders (eg, arduino) 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)
  3. Recommend people add parts in their ~/.avrduderc that changes the EEPROM page size (untested)
  4. Let bootloaders implement one byte EEPROM read/write (STK_PROG_DATA and STK_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?

@mcuee
Copy link
Collaborator

mcuee commented May 21, 2022

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?
I guess this MightyCore can be the choice, right?
https://github.com/MCUdude/MightyCore

Step 2: run your test

yes hello, world | head -512c | avrdude -qq -p m161 -F -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:w:-:r

@stefanrueger
Copy link
Collaborator Author

Well, this issue is about protocol incompatibility between AVRDUDE and some parts for a typical -c arduino bootoloader.

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 -F so AVRDUDE ignores the m328p's signature.

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?):

$ echo hello, world | avrdude -qq -p m8515 -c arduino -P /dev/ttyUSB0 -U eeprom:w:-:r

I know optiboot well and expect it to behave as above provided EEPROM page size of the ATmega8515 in your .conf is 1.

I don't think optiboot caters for the new AVR DA/DB family yet, but if their EEPROM page size remains 1 in avrdude.conf then they will show the same problem once/when optiboot compiles for this. (Anyone has a working code for EEPROM/flash self-programming for these newer parts, I'd be interested so see a working implementation.)

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.

@mcuee
Copy link
Collaborator

mcuee commented May 22, 2022

Well, this issue is about protocol incompatibility between AVRDUDE and some parts for a typical -c arduino bootoloader.

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.

I don't think optiboot caters for the new AVR DA/DB family yet.

Looks like there is a working solution here.
Ref: Optiboot/optiboot#294
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/bootloaders/optiboot_dx/optiboot_dx.c

@mcuee
Copy link
Collaborator

mcuee commented May 22, 2022

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.
https://github.com/mcuee/libusbk/tree/master/BmFW

So this dicussion is an interesting read.
#940

@mcuee
Copy link
Collaborator

mcuee commented May 22, 2022

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.

It seems to me Arduino's implemenation of Optiboot does not support EEPROM.
Ref: https://github.com/arduino/ArduinoCore-avr/blob/master/bootloaders/optiboot/optiboot.c

For MegaAVR core (eg:ATmega4809), Arduino does not use Optiboot but Microchip's bootloader which does not support EEPROM either.
Ref: https://github.com/arduino/ArduinoCore-megaavr/blob/master/bootloaders/boot.c

Or course alternative Arduino Core Implementation may have Optiboot implemenatation which may support EEPROM.
Eg:
https://github.com/MCUdude/MiniCore/tree/master/avr/bootloaders/optiboot_flash
https://github.com/MCUdude/MightyCore/tree/master/avr/bootloaders/optiboot_flash
https://github.com/MCUdude/MegaCore/tree/master/avr/bootloaders/optiboot_flash

The following seem to have the option to enable EEPROM support as well.
https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/bootloaders/optiboot/optiboot.c
https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/bootloaders/optiboot_x/optiboot_x.c
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/bootloaders/optiboot_dx/optiboot_dx.c (for DA/DB family)

@mcuee
Copy link
Collaborator

mcuee commented May 22, 2022

Not so sure if the bug report here is relevant or not (avrdude problem or bootloader problem).

@mcuee
Copy link
Collaborator

mcuee commented May 22, 2022

@stefanrueger
Copy link
Collaborator Author

It seems to me Arduino's implemenation of Optiboot does not support EEPROM.

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.

https://github.com/Optiboot/optiboot

@stefanrueger
Copy link
Collaborator Author

@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.

@mcuee
Copy link
Collaborator

mcuee commented May 23, 2022

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 access.

Yes I understand.

What I am trying to say is that they probably should not use -c arduino as -c arduino was probably designed for those official and compatible Arduino clones and works fine for that purpose. Maybe a -c optiboot or things like that makes sense. This is different from your proposed solution.

@stefanrueger
Copy link
Collaborator Author

they probably should not use -c arduino

Correct. Actually, no one should :) As you have seen #940 argues -c arduino is not a great match for bootloader needs.

Maybe a -c optiboot or things like that makes sense

Correct. Yet, there are not many games in town. AVRDUDE has the likes of wiring, micronucleus, xbee. I would never call a new one -c optiboot, though, principally because optiboot is not opti: my r/w bootloaders are 224-384 bytes, not 512-1024 :) Working names are urclock (tongue in cheek analogy to arduino, long story) or the more generic urboot.

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).

@mcuee
Copy link
Collaborator

mcuee commented Jun 12, 2022

Valid and interesting comments by @dl8dtl

Just keep in mind, if you call it STK500, it must behave as if it were an STK500. If you'd do something similar on a real STK500,

@mcuee
Copy link
Collaborator

mcuee commented Jun 14, 2022

I can reproduce the issue as well.

$ yes hello, world | head -512c | ./avrdude.exe -qq -p m161 -F -c arduino -b 115200 -P COM29 -U eeprom:w:-:r
avrdude.exe: Expected signature for ATmega161 is 1E 94 01
 ***failed;
 ***failed;
 ***failed;
 ***failed;


@mcuee
Copy link
Collaborator

mcuee commented Jun 14, 2022

Reading will not fail but the results are wrong.

$ ./avrdude.exe -p m328p -c arduino -b 115200 -P COM29 -U eeprom:w:entest.eep:i -vv

avrdude.exe: Version 7.0
             Copyright (c) Brian Dean, http://www.bdmicro.com/
             Copyright (c) Joerg Wunsch

             System wide configuration file is "C:/work/avr/binary/avrdude-7.0_bin64/avrdude.conf"

             Using Port                    : COM29
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
             AVR Part                      : ATmega328P
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PC2
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             Serial program mode           : yes
             Parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                               Block Poll               Page                       Polled
               Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom                 65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
               flash                  65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
               lfuse                   0     0     0    0 no          1    1      0  4500  4500 0x00 0x00
               hfuse                   0     0     0    0 no          1    1      0  4500  4500 0x00 0x00
               efuse                   0     0     0    0 no          1    1      0  4500  4500 0x00 0x00
               lock                    0     0     0    0 no          1    1      0  4500  4500 0x00 0x00
               calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00
               signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00

             Programmer Type : Arduino
             Description     : Arduino
             Hardware Version: 7
             Firmware Version: 7.6

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading input file "entest.eep"
avrdude.exe: writing eeprom (512 bytes):

Writing | ################################################## | 100% 2.33s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against entest.eep:
avrdude.exe: load data eeprom data from input file entest.eep:
avrdude.exe: input file entest.eep contains 512 bytes
avrdude.exe: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.99s

avrdude.exe: verifying ...
avrdude.exe: 512 bytes of eeprom verified

avrdude.exe done.  Thank you.

`$` ./avrdude.exe -p m161 -F -c arduino -b 115200 -P COM29 -U eeprom:r:entest_read_m161.eep:i -vv

avrdude.exe: Version 7.0
             Copyright (c) Brian Dean, http://www.bdmicro.com/
             Copyright (c) Joerg Wunsch

             System wide configuration file is "C:/work/avr/binary/avrdude-7.0_bin64/avrdude.conf"

             Using Port                    : COM29
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
             AVR Part                      : ATmega161
             Chip Erase delay              : 28000 us
             PAGEL                         : PD7
             BS2                           : PA0
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             Serial program mode           : yes
             Parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                               Block Poll               Page                       Polled
               Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom                  4     5   128    0 no        512    1      0  3400  3400 0xff 0xff
               flash                  33    16   128    0 yes     16384  128    128 14000 14000 0xff 0xff
               fuse                    0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               lock                    0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00

             Programmer Type : Arduino
             Description     : Arduino
             Hardware Version: 7
             Firmware Version: 7.6

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: Expected signature for ATmega161 is 1E 94 01
avrdude.exe: reading eeprom memory:

Reading | ################################################## | 100% 1.66s

avrdude.exe: writing output file "entest_read_m161.eep"

avrdude.exe done.  Thank you.

$ ./avrdude.exe -qq -p m161 -F -c arduino -b 115200 -P COM29 -U eeprom:r:entest_read_m161.eep:i
avrdude.exe: Expected signature for ATmega161 is 1E 94 01

$ cat entest_read_m161.eep
:200000000000000000000000000000000000000000000000000000000000000000000000E0
:200020000000000000000000000000000000000000000000000000000000000000000000C0
:200040000000000000000000000000000000000000000000000000000000000000000000A0
:20006000000000000000000000000000000000000000000000000000000000000000000080
:20008000000000000000000000000000000000000000000000000000000000000000000060
:2000A000000000000000000000000000000000000000000000000000000000000000000040
:2000C000000000000000000000000000000000000000000000000000000000000000000020
:2000E000000000000000000000000000000000000000000000000000000000000000000000
:200100000000000000000000000000000000000000000000000000000000000000000000DF
:200120000000000000000000000000000000000000000000000000000000000000000000BF
:2001400000000000000000000000000000000000000000000000000000000000000000009F
:2001600000000000000000000000000000000000000000000000000000000000000000007F
:2001800000000000000000000000000000000000000000000000000000000000000000005F
:2001A00000000000000000000000000000000000000000000000000000000000000000003F
:2001C00000000000000000000000000000000000000000000000000000000000000000001F
:2001E0000000000000000000000000000000000000000000000000000000000000000000FF
:00000001FF

$ ./avrdude.exe -qq -p m328p -c arduino -b 115200 -P COM29 -U eeprom:r:entest_read_m328p.eep:i

$ cat entest_read_m328p.eep
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:200040006A756D7073206F76657220746865206C617A7920646F670A5468652071756963FD
:200060006B2062726F776E20666F78206A756D7073206F76657220746865206C617A7920D4
:20008000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F76B5
:2000A000657220746865206C617A7920646F670A54686520717569636B2062726F776E20FE
:2000C000666F78206A756D7073206F76657220746865206C617A7920646F670A54686520C2
:2000E000717569636B2062726F776E20666F78206A756D7073206F76657220746865206C16
:20010000617A7920646F670A54686520717569636B2062726F776E20666F78206A756D7038
:2001200073206F76657220746865206C617A7920646F670A54686520717569636B20627279
:200140006F776E20666F78206A756D7073206F76657220746865206C617A7920646F670A0E
:2001600054686520717569636B2062726F776E20666F78206A756D7073206F7665722074AD
:200180006865206C617A7920646F670A54686520717569636B2062726F776E20666F78201B
:2001A0006A756D7073206F76657220746865206C617A7920646F670A54686520717569639C
:2001C0006B2062726F776E20666F78206A756D7073206F76657220746865206C617A792073
:2001E000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F7654
:20020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
:20022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE
:20024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE
:20026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E
:20028000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7E
:2002A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5E
:2002C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3E
:2002E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1E
:20030000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD
:20032000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDD
:20034000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBD
:20036000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9D
:20038000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D
:2003A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D
:2003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
:2003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
:00000001FF

@stefanrueger
Copy link
Collaborator Author

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

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

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
Just wondering why you say that the bootloaders like optiboot_x and optiboot_dx have already solved the issue for the UPDI parts. Thanks.

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

Unfortunately #1110 has issues with optiboot and it can not be merged even though it may help in solving this issue.

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

@MCUdude

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 a_div =1 mode from PR #1110.

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

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 Just wondering why you say that the bootloaders like optiboot_x and optiboot_dx have already solved the issue for the UPDI parts. Thanks.

@stefanrueger

For example, for optiboot_dx, the latest git main (e14e5d2) will still have the same issue.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM5 -b 115200 -qqp avr128db48 
-U eeprom:w:.\hex\entest.eep:i
 ***failed;
 ***failed;
 ***failed;
..
 ***failed;
 ***failed;
 ***failed;
avr_read_mem(): error reading address 0x0000
    read operation not supported for memory eeprom
avrdude_git.exe: failed to read all of eeprom memory, rc=-2

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

From #1110 (comment).

Basically, git mainline uses mem->page_size > 1 as proxy for paged access, whereas this PR (#1110) uses the memory name being either eeprom, flash, application, apptable or boot as proxy.

For eeprom the former is probably wrong for all UPDI parts and some classic parts (amongst which ATmega161 ATmega163 ATmega8515 ATmega8535).

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

From #1110 (comment)

Other bootloaders may benefit from being called with paged routines; good to know that wiring can manage without this PR (but then it is large, so can afford to implement both byte-wise read/write and paged read/write, most bootloaders only implement paged r/w!); I know that my (soon to be included) urcock bootloader will be able to work with this PR but that's not the point.

It really is about when to call paged r/w routines. I realise that there is mem->paged (set in avrdude.conf) but this is not set for PDI and UPDI parts nor is it ever set for eeprom (except accidentally for ATtiny43U) so this must be used for something else...

@mcuee
Copy link
Collaborator

mcuee commented Oct 12, 2022

@stefanrueger
I will leave this as open first and we can visit this issue later. I do agree to close #1110 as it has issues.

@mcuee mcuee reopened this Oct 12, 2022
@stefanrueger
Copy link
Collaborator Author

Just wondering why you say that the bootloaders like optiboot_x and optiboot_dx have already solved the issue for the UPDI parts. Thanks.

@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 (pgm->prog_modes & PM_SPM) and memory is flash or eeprom. This would fail for bootloaders that actually implement byte-wise read/write access.

@mcuee
Copy link
Collaborator

mcuee commented Oct 13, 2022

Just wondering why you say that the bootloaders like optiboot_x and optiboot_dx have already solved the issue for the UPDI parts. Thanks.

@mcuee I (perhaps mistakenly) thought that optiboot_x and optiboot_dx can access EEPROM. Happy to stand corrected.

@stefanrueger
My test shows otherwise. But @MCUdude may know better in this aspect.

How about I create a PR (sometime) that invokes paged access if programmer is for a bootloader (pgm->prog_modes & PM_SPM) and memory is flash or eeprom. This would fail for bootloaders that actually implement byte-wise read/write access.

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.

@mcuee
Copy link
Collaborator

mcuee commented Oct 14, 2022

@MCUdude has a very nice test results summary here for optiboot_x and optiboot_dx, for git main.
#1121 (comment)

optiboot_x / optiboot_dx ATmega4808 AVR128DA32
Read from EEPROM(-U)
Write to EEPROM(-U) ❗️Writes content but erasesthe EEPROM page first, resulting in data loss
Read from EEPROM(-t) ❗️Reads data somehow, but returns duplicates(See output below)
Write to EEPROM(-t) ❗️ Writes content but duplicatesit at a different address(See output below)

@mcuee
Copy link
Collaborator

mcuee commented Oct 14, 2022

#1121 (comment)
Summary of my test results, using optiboot_dx and AVR128DB48.

optiboot_dx PR #1121 git main PR #1110 mod with a_div=1
Read from EEPROM(-U)
Write to EEPROM(-U)
Read from EEPROM(-t) ❗️returns duplicates
Write to EEPROM(-t)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants