Always use paged access for programmers that serve bootloaders

[stefanrueger]

Supposed to fix Issue #970

I have made another stab at this and implemented Option 1 of #970 (comment). Now writing to EEPROM works, in principle. The chosen example of #970 is not great b/c optiboot only ever uses word addresses. With a page size of 1 (as in the EEPROM of ATmega161) this will out of necessity write to even addresses only yielding a verification error.

$ yes hello, world | head -512c | avrdude -qq -p m161 -F -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:w:-:r
avrdude warning: expected signature for ATmega161 is 1E 94 01
avrdude error: verification mismatch, first encountered at addr 0x0000
        device 0x65 != input 0x68
avrdude error: verification mismatch

Reading purports a doubling of characters b/c the even addresses are all read twice:

$ avrdude -qq -p m161 -F -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:r:-:I
avrdude warning: expected signature for ATmega161 is 1E 94 01
:2000000065656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2CC2 // 00000> eell,,wwrrddhhlloo__ooll..eell,,
:2000200077777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646402 // 00020> wwrrddhhlloo__ooll..eell,,wwrrdd
:2000400068686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6FF6 // 00040> hhlloo__ooll..eell,,wwrrddhhlloo
:2000600020206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C66 // 00060> __ooll..eell,,wwrrddhhlloo__ooll
:200080000A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C86 // 00080> ..eell,,wwrrddhhlloo__ooll..eell
:2000A0002C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272F2 // 000a0> ,,wwrrddhhlloo__ooll..eell,,wwrr
:2000C000646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C8C // 000c0> ddhhlloo__ooll..eell,,wwrrddhhll
:2000E0006F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6FE0 // 000e0> oo__ooll..eell,,wwrrddhhlloo__oo
:200100006C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A656505 // 00100> ll..eell,,wwrrddhhlloo__ooll..ee
:200120006C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777D // 00120> ll,,wwrrddhhlloo__ooll..eell,,ww
:200140007272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C7777727264646868FF // 00140> rrddhhlloo__ooll..eell,,wwrrddhh
:200160006C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F202065 // 00160> lloo__ooll..eell,,wwrrddhhlloo__
:200180006F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A71 // 00180> ooll..eell,,wwrrddhhlloo__ooll..
:2001A00065656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C21 // 001a0> eell,,wwrrddhhlloo__ooll..eell,,
:2001C00077777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646461 // 001c0> wwrrddhhlloo__ooll..eell,,wwrrdd
:2001E00068686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F55 // 001e0> hhlloo__ooll..eell,,wwrrddhhlloo
:00000001FF

Actually, bytes at odd addresses have never been modified:

$ avrdude -qq -p m328p -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:r:-:I
:2000000065FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF61 // 00000> e.l.,.w.r.d.h.l.o._.o.l...e.l.,.
:2000200077FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FFF1 // 00020> w.r.d.h.l.o._.o.l...e.l.,.w.r.d.
:2000400068FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF6FFFDB // 00040> h.l.o._.o.l...e.l.,.w.r.d.h.l.o.
:2000600020FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF03 // 00060> _.o.l...e.l.,.w.r.d.h.l.o._.o.l.
:200080000AFE65FE6CFE2CFE77FE72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF08 // 00080> .~e~l~,~w~r.d.h.l.o._.o.l...e.l.
:2000A0002CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FFA9 // 000a0> ,.w.r.d.h.l.o._.o.l...e.l.,.w.r.
:2000C00064FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF66 // 000c0> d.h.l.o._.o.l...e.l.,.w.r.d.h.l.
:2000E0006FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF80 // 000e0> o._.o.l...e.l.,.w.r.d.h.l.o._.o.
:200100006C630AD365006C4B2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FFFD // 00100> lc.Se.lK,.w.r.d.h.l.o._.o.l...e.
:200120006CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF2E // 00120> l.,.w.r.d.h.l.o._.o.l...e.l.,.w.
:2001400072FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FFDF // 00140> r.d.h.l.o._.o.l...e.l.,.w.r.d.h.
:200160006CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF02 // 00160> l.o._.o.l...e.l.,.w.r.d.h.l.o._.
:200180006FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFFF8 // 00180> o.l...e.l.,.w.r.d.h.l.o._.o.l...
:2001A00065FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFFC0 // 001a0> e.l.,.w.r.d.h.l.o._.o.l...e.l.,.
:2001C00077FF72FF64FF68FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF50 // 001c0> w.r.d.h.l.o._.o.l...e.l.,.w.r.d.
:2001E00068FF6CFF6FFF20FF6FFF6CFF0AFF65FF6CFF2CFF77FF72FF64FF68FF6CFF6FFF3A // 001e0> h.l.o._.o.l...e.l.,.w.r.d.h.l.o.
:20020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE // 00200> ................................
:20022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE // 00220> ................................
:20024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE // 00240> ................................
:20026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E // 00260> ................................
:20028000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7E // 00280> ................................
:2002A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5E // 002a0> ................................
:2002C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3E // 002c0> ................................
:2002E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1E // 002e0> ................................
:20030000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD // 00300> ................................
:20032000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDD // 00320> ................................
:20034000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBD // 00340> ................................
:20036000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9D // 00360> ................................
:20038000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D // 00380> ................................
:2003A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D // 003a0> ................................
:2003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D // 003c0> ................................
:2003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D // 003e0> ................................
:00000001FF

However, this is outside the remit of this PR. Optiboot_x and optiboot_dx that use byte addresses throughout should be OK once PR #1140 is merged.

[mcuee]

As you mentioned and I can reporduce as well, It helps but does not 100% fix the issue EEPROM write issue for the "ATmega161 ATmega163 ATmega8515 ATmega8535".

Can we carry out special treatment just for these four in stk500v1.c for bootloader of these four parts (after merging of PR #1140)? Then it should be able to fix the issue 100%.

avrdude 7.0

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

This PR:

$ yes hello, world | head -512c | ./avrdude -qq -p m161 -F -c arduino -b 115200 -P COM5 -U eeprom:w:-:r
avrdude warning: expected signature for ATmega161 is 1E 94 01
avrdude error: verification mismatch, first encountered at addr 0x0000
        device 0x65 != input 0x68
avrdude error: verification mismatch

$ yes hello, world | head -512c | ./avrdude -qq -p m328p -c arduino -b 115200 -P COM5 -U eeprom:v:-:r
avrdude error: verification mismatch, first encountered at addr 0x0000
        device 0x65 != input 0x68
avrdude error: verification mismatch

[stefanrueger]

Can we carry out special treatment just for these four in stk500v1.c for bootloader of these four parts

No, because optiboot wants word addresses everywhere. It is impossible to solve this for page sizes of 1! Optiboot users could create custom parts ATmega161ob that is like the ATmega161 but claims to have, say 16 bytes page_size for eeprom.

Other bootloaders that want byte addresses (eg, my urboot bootloader in tandem with my urclock programmer) will work. Reminds me to finish all these PRs, put my skates on and get the urclock programmer integrated into AVRDUDE. I plan to merge those PRs that are ready soon and get going on that business.

[mcuee]

Can we carry out special treatment just for these four in stk500v1.c for bootloader of these four parts

No, because optiboot wants word addresses everywhere. It is impossible to solve this for page sizes of 1! Optiboot users could create custom parts ATmega161ob that is like the ATmega161 but claims to have, say 16 bytes page_size for eeprom.

I see. That is a good workaround. Shall we just include this in the avrdude.conf and mention this in the document?

Other bootloaders that want byte addresses (eg, my urboot bootloader in tandem with my urclock programmer) will work. Reminds me to finish all these PRs, put my skates on and get the urclock programmer integrated into AVRDUDE. I plan to merge those PRs that are ready soon and get going on that business.

That will be great. I am thinking we need to release avrdude 8.0 (and not planned 7.1) once that is done.

[mcuee]

No, because optiboot wants word addresses everywhere. It is impossible to solve this for page sizes of 1! Optiboot users could create custom parts ATmega161ob that is like the ATmega161 but claims to have, say 16 bytes page_size for eeprom.

I see. That is a good workaround. And indeed it works fine.

Shall we just include this in the avrdude.conf and mention this in the document?

$ diff -u avrdude.conf avrdude_pr1141.conf
--- avrdude.conf        2022-10-22 13:24:37.368352000 +0800
+++ avrdude_pr1141.conf 2022-10-22 13:33:03.232163400 +0800
@@ -4890,7 +4890,7 @@

     memory "eeprom"
         size               = 512;
-        page_size          = 4;
+        page_size          = 16;
         min_write_delay    = 9000;
         max_write_delay    = 9000;
         readback           = 0xff 0xff;
@@ -5537,6 +5537,7 @@

     memory "eeprom"
         size               = 512;
+               page_size          = 16;
         min_write_delay    = 3400;
         max_write_delay    = 3400;
         readback           = 0xff 0xff;
@@ -5758,6 +5759,7 @@

     memory "eeprom"
         size               = 512;
+               page_size          = 16;
         min_write_delay    = 9000;
         max_write_delay    = 9000;
         readback           = 0xff 0xff;
@@ -5863,6 +5865,7 @@

     memory "eeprom"
         size               = 512;
+               page_size          = 16;
         min_write_delay    = 9000;
         max_write_delay    = 9000;
         readback           = 0xff 0xff;

$ yes hello, world | head -512c | ./avrdude -C ./avrdude_pr1141.conf -qq -p m161 -F -c arduino -b 115200 -P COM5 
-U eeprom:w:-:r && echo OK
avrdude warning: ATmega169's eeprom loadpage_lo misses a necessary address bit a3 
[C:\work\avr\avrdude_test\avrdude_sr\build_mingw64_nt-10.0-22000\src\avrdude_pr1141.conf:4904]
avrdude warning: expected signature for ATmega161 is 1E 94 01
OK

$ yes hello, world | head -512c | ./avrdude -C ./avrdude_pr1141.conf -qq -p m169 -F -c arduino -b 115200 -P COM5 
-U eeprom:w:-:r && echo OK
avrdude warning: ATmega169's eeprom loadpage_lo misses a necessary address bit a3 
[C:\work\avr\avrdude_test\avrdude_sr\build_mingw64_nt-10.0-22000\src\avrdude_pr1141.conf:4905]
avrdude warning: expected signature for ATmega169 is 1E 94 05
OK

$ yes hello, world | head -512c | ./avrdude -C ./avrdude_pr1141.conf -qq -p m8515 -F -c arduino -b 115200 -P COM5 
-U eeprom:w:-:r && echo OK
avrdude warning: ATmega169's eeprom loadpage_lo misses a necessary address bit a3 
[C:\work\avr\avrdude_test\avrdude_sr\build_mingw64_nt-10.0-22000\src\avrdude_pr1141.conf:4905]
avrdude warning: expected signature for ATmega8515 is 1E 93 06
OK

$ yes hello, world | head -512c | ./avrdude -C ./avrdude_pr1141.conf -qq -p m8535 -F -c arduino -b 115200 -P COM5 
-U eeprom:w:-:r && echo OK
avrdude warning: ATmega169's eeprom loadpage_lo misses a necessary address bit a3 
[C:\work\avr\avrdude_test\avrdude_sr\build_mingw64_nt-10.0-22000\src\avrdude_pr1141.conf:4905]
avrdude warning: expected signature for ATmega8535 is 1E 93 08
OK

[MCUdude]

It looks like there's still issues with Atmega8535 at least:

$ yes "hello, world" | head -c512 | ./avrdude -carduino -patmega8535 -Ueeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9308 (probably m8535)
avrdude: reading input file <stdin> for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
avrdude: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 4.27s

avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>

Reading | ################################################## | 100% 3.04s

avrdude error: verification mismatch, first encountered at addr 0x0000
        device 0x65 != input 0x68
avrdude error: verification mismatch

avrdude done.  Thank you.


$ ./avrdude -carduino -patmega8535 -Ueeprom:r:-:I

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9308 (probably m8535)
avrdude: reading eeprom memory ...

Reading | ################################################## | 100% 3.03s

avrdude: writing output file <stdout>
:2000000065656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2CC2 // 00000> eell,,wwrrddhhlloo__ooll..eell,,
:2000200077777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646402 // 00020> wwrrddhhlloo__ooll..eell,,wwrrdd
:2000400068686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6FF6 // 00040> hhlloo__ooll..eell,,wwrrddhhlloo
:2000600020206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C66 // 00060> __ooll..eell,,wwrrddhhlloo__ooll
:200080000A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C86 // 00080> ..eell,,wwrrddhhlloo__ooll..eell
:2000A0002C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272F2 // 000a0> ,,wwrrddhhlloo__ooll..eell,,wwrr
:2000C000646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C8C // 000c0> ddhhlloo__ooll..eell,,wwrrddhhll
:2000E0006F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6FE0 // 000e0> oo__ooll..eell,,wwrrddhhlloo__oo
:200100006C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A656505 // 00100> ll..eell,,wwrrddhhlloo__ooll..ee
:200120006C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777D // 00120> ll,,wwrrddhhlloo__ooll..eell,,ww
:200140007272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C7777727264646868FF // 00140> rrddhhlloo__ooll..eell,,wwrrddhh
:200160006C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F202065 // 00160> lloo__ooll..eell,,wwrrddhhlloo__
:200180006F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A71 // 00180> ooll..eell,,wwrrddhhlloo__ooll..
:2001A00065656C6C2C2C77777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C21 // 001a0> eell,,wwrrddhhlloo__ooll..eell,,
:2001C00077777272646468686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646461 // 001c0> wwrrddhhlloo__ooll..eell,,wwrrdd
:2001E00068686C6C6F6F20206F6F6C6C0A0A65656C6C2C2C77777272646468686C6C6F6F55 // 001e0> hhlloo__ooll..eell,,wwrrddhhlloo
:00000001FF

avrdude done.  Thank you.

[MCUdude]

With this PR I'm getting an error when writing to the Atmega4808. Since the error appears at address 0x40, maybe this is a page write issue?

$ yes "hello, world" | head -c256 | ./avrdude -carduino -patmega4808 -Ueeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9650 (probably m4808)
avrdude: reading input file <stdin> for eeprom
         with 256 bytes in 1 section within [0, 0xff]
         using 4 pages and 0 pad bytes
avrdude: writing 256 bytes eeprom ...

Writing | ################################################## | 100% 0.06s

avrdude: 256 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>

Reading | ################################################## | 100% 0.05s

avrdude error: verification mismatch, first encountered at addr 0x0040
        device 0x20 != input 0x0a
avrdude error: verification mismatch

avrdude done.  Thank you.



$ echo "read eeprom" |./avrdude -carduino -patmega4808 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9650 (probably m4808)
>>> read eeprom 

Reading | ################################################## | 100% 0.05s

0000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0a 68 65 6c  |hello, world hel|
0010  6c 6f 2c 20 77 6f 72 6c  64 0a 68 65 6c 6c 6f 2c  |lo, world hello,|
0020  20 77 6f 72 6c 64 0a 68  65 6c 6c 6f 2c 20 77 6f  | world hello, wo|
0030  72 6c 64 0a 68 65 6c 6c  6f 2c 20 77 6f 72 6c 64  |rld hello, world|
0040  20 77 6f 72 6c 64 0a 68  65 6c 6c 6f 2c 20 77 6f  | world hello, wo|
0050  72 6c 64 0a 68 65 6c 6c  6f 2c 20 77 6f 72 6c 64  |rld hello, world|
0060  64 0a 68 65 6c 6c 6f 2c  20 77 6f 72 6c 64 0a 68  |d hello, world h|
0070  65 6c 6c 6f 2c 20 77 6f  72 6c 64 0a 68 65 6c 6c  |ello, world hell|
0080  64 0a 68 65 6c 6c 6f 2c  20 77 6f 72 6c 64 0a 68  |d hello, world h|
0090  65 6c 6c 6f 2c 20 77 6f  72 6c 64 0a 68 65 6c 6c  |ello, world hell|
00a0  6f 2c 20 77 6f 72 6c 64  0a 68 65 6c 6c 6f 2c 20  |o, world hello, |
00b0  77 6f 72 6c 64 0a 68 65  6c 6c 6f 2c 20 77 6f 72  |world hello, wor|
00c0  6f 2c 20 77 6f 72 6c 64  0a 68 65 6c 6c 6f 2c 20  |o, world hello, |
00d0  77 6f 72 6c 64 0a 68 65  6c 6c 6f 2c 20 77 6f 72  |world hello, wor|
00e0  6c 6f 2c 20 77 6f 72 6c  64 0a 68 65 6c 6c 6f 2c  |lo, world hello,|
00f0  20 77 6f 72 6c 64 0a 68  65 6c 6c 6f 2c 20 77 6f  | world hello, wo|


avrdude done.  Thank you.

[MCUdude]

I created a test hex file using srec_cat so I could test with Avrdude 6.3. I can confirm that it works with Avrdude 6.3:

$ yes "hello, world" | head -c256 | srec_cat - -bin -o hello_world_256B.hex -Intel

$ cat hello_world_256B.hex 
:020000040000FA
:2000000068656C6C6F2C20776F726C640A68656C6C6F2C20776F726C640A68656C6C6F2C7C
:2000200020776F726C640A68656C6C6F2C20776F726C640A68656C6C6F2C20776F726C6454
:200040000A68656C6C6F2C20776F726C640A68656C6C6F2C20776F726C640A68656C6C6F5E
:200060002C20776F726C640A68656C6C6F2C20776F726C640A68656C6C6F2C20776F726C4C
:20008000640A68656C6C6F2C20776F726C640A68656C6C6F2C20776F726C640A68656C6C29
:2000A0006F2C20776F726C640A68656C6C6F2C20776F726C640A68656C6C6F2C20776F7209
:2000C0006C640A68656C6C6F2C20776F726C640A68656C6C6F2C20776F726C640A68656CE9
:2000E0006C6F2C20776F726C640A68656C6C6F2C20776F726C640A68656C6C6F2C20776FCF
:00000001FF

$ /Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf -patmega4808 -carduino -Ueeprom:w:hello_world_256B.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9650 (probably m4808)
avrdude: reading input file "hello_world_256B.hex"
avrdude: writing eeprom (256 bytes):

Writing | ################################################## | 100% 0.06s

avrdude: 256 bytes of eeprom written
avrdude: verifying eeprom memory against hello_world_256B.hex:
avrdude: load data eeprom data from input file hello_world_256B.hex:
avrdude: input file hello_world_256B.hex contains 256 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 256 bytes of eeprom verified

avrdude: safemode: Fuses OK (E:FF, H:FF, L:FF)

avrdude done.  Thank you.

[stefanrueger]

error when writing to the Atmega4808 [edit]

And without the PR?
Hmm, where have the \n gone? The first verification error is at 0x20. That's all strange.

Have you exercised make clean and compiled from start?

[stefanrueger]

It looks like there's still issues with Atmega8535 at least

The problem lies squarely with optiboot. optiboot wants word addresses everywhere. It is impossible to solve this for page sizes of 1! This PR helps other bootloaders that do not use word addresses for size 1 pages (which out of necessity) will lead to a doubling of characters

[MCUdude]

Have you exercised make clean and compiled from start?

Yes, this time I made sure I ran make clean before building this PR.

This is the error. It complains that the device has a different value at addr 0x0040 than the input file:

 avrdude error: verification mismatch, first encountered at addr 0x0040
        device 0x20 != input 0x0a

However, I realize now that this PR is not causing it. I'm getting the same error when building and running git main:

$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

$ make clean
Making clean in .
 rm -f avrdude
test -z "config_gram.c config_gram.h lexer.c" || rm -f config_gram.c config_gram.h lexer.c
test -z "libavrdude.la" || rm -f libavrdude.la
rm -f ./so_locations
rm -rf .libs _libs
test -z "libavrdude.a" || rm -f libavrdude.a
rm -f *.o
rm -f *.lo

$ make
 [...]

$ ./avrdude -carduino -patmega4808 -Ueeprom:w:hello_world_256B.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9650 (probably m4808)
avrdude: reading input file hello_world_256B.hex for eeprom
         with 256 bytes in 1 section within [0, 0xff]
         using 4 pages and 0 pad bytes
avrdude: writing 256 bytes eeprom ...

Writing | ################################################## | 100% 0.06s

avrdude: 256 bytes of eeprom written
avrdude: verifying eeprom memory against hello_world_256B.hex

Reading | ################################################## | 100% 0.05s

avrdude error: verification mismatch, first encountered at addr 0x0040
        device 0x20 != input 0x0a
avrdude error: verification mismatch

avrdude done.  Thank you.

[MCUdude]

The problem lies squarely with optiboot. optiboot wants word addresses everywhere. It is impossible to solve this for page sizes of 1! This PR helps other bootloaders that do not use word addresses for size 1 pages (which out of necessity) will lead to a doubling of characters

But it works with Avrdude 6.3 (and Avrdude 7.0 actually!), even though Optiboot is the one being tricky here.

[stefanrueger]

The problem lies squarely with optiboot.

In fairness, the problem is the protocol that arduino and optiboot use here (and it goes back to a wrong stk500v1 implementation that erroneously sent word addresses upon which optiboot followed suit). There is another trick, though, for ATmega161, ATmega8535 etc: This affects the (-c arduino) programmer for bootloaders, which don't care about the actual chip, they only support the protocol and AVRDUDE relies on the bootloader to do the right thing. So, we could try to secretly change the eeprom page size from 1 to, say, 16 at runtime in arduino first thing just before the signature bytes are read within the read_sig_bytes() routine. Not the finest behaviour (to secretly ignore avrdude.conf, because AVRDUDE really wants to be driven by avrdude.conf), but there you go.

I realize now that this PR is not causing it. I'm getting the same error when building and running git main

That's what I thought b/c the ATmega4808 has an eeprom page size > 1 and, therefore, is unaffected by this PR. @mcuee has this neat way of finding which commit is to blame. Perhaps we get some intell about this that way?

[MCUdude]

In fairness, the problem is the protocol that arduino and optiboot use here (and it goes back to a wrong stk500v1 implementation that erroneously sent word addresses upon which optiboot followed suit). There is another trick, though, for ATmega161, ATmega8535 etc: This affects the (-c arduino) programmer for bootloaders, which don't care about the actual chip, they only support the protocol and AVRDUDE relies on the bootloader to do the right thing. So, we could try to secretly change the eeprom page size from 1 to, say, 16 at runtime in arduino first thing just before the signature bytes are read within the read_sig_bytes() routine. Not the finest behaviour (to secretly ignore avrdude.conf, because AVRDUDE really wants to be driven by avrdude.conf), but there you go.

I do own an ATmega8535, and I've compiled Optiboot with EEPROM support for it. AFAIK EEPROM read/write has never worked for these old chips, so maybe we instead should modify the Optiboot source code? I don't know all the underlying details all that well, I'm just interested in getting Avrdude to support Optiboot as well as possible.

Regarding the Atmega4808 EEPROM issue, I tracked down the issue to our usual suspect: 3d06457.

[MCUdude]

Regarding the EEPROM write for the ATmega4808. I can confirm that PR #1140 resolved this issue!

[stefanrueger]

maybe we instead should modify the Optiboot source code?

That's not sufficient b/c you also need to change the other side (the programmer in AVRDUDE). I have just pushed a commit to PR #1140 to try to solve this problem by pretending the classic parts with EEPROM page size 1 actually has 16 byte pages. This should(!) now work for the classic optiboot (no changes needed there). Note it's PR #1140, not this one. Pls feel free to try with ATmega8535 or ATmega161.

[mcuee]

maybe we instead should modify the Optiboot source code?

That's not sufficient b/c you also need to change the other side (the programmer in AVRDUDE). I have just pushed a commit to PR #1140 to try to solve this problem by pretending the classic parts with EEPROM page size 1 actually has 16 byte pages. This should(!) now work for the classic optiboot (no changes needed there). Note it's PR #1140, not this one. Pls feel free to try with ATmega8535 or ATmega161.

Great. PR #1140 now works with the 4 classic AVR chips which has the issue. But I am not using the real chip for testing but using the ATmega328P with -F to emulate them. Hopefully the results from the real ATmega8535 and ATmega161 will be the same.