Do STK500/arduino/xbee programmers fail EEPROM r/w for some parts?

[stefanrueger]

Reading stk500.c I noticed that for paged load/writes typically word addresses are passed to the external programmer for both flash and EEPROM but under certain circumstances byte addresses (eg, for EEPROM access of parts without EEPROM loadpage SPI programming). Now, I don't have any STK500 programmer at hand, and more crucially neither their firmware source, but does the STK500 communication protocol really switch between word and byte addresses on such a condition without rhyme or reason?

If not, and it's always word addresses, then avrdude -c stk500 should fail to properly read/write EEPROM of the following devices: ATtiny12 ATtiny15 AT90S1200 AT90S4414 AT90S2313 AT90S2333 AT90S2343 AT90S4433 AT90S4434 AT90S8515 AT90S8535 ATmega103 ATmega64 ATmega64A ATmega128 ATmega128A ATmega163 ATmega161 ATmega8 ATmega8A ATmega8515 ATmega8535 ATtiny26

[edit: Actually, only affects ATmega64 ATmega64A ATmega128 ATmega128A ATmega8 ATmega8A, see Issue #970 and below]

Also affects derived programmers, eg, arduino, xbee. I verified that

avrdude -qq -p atmega8 -F -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:r:hi.eep:i

with an EEPROM enabled bootloader reads 512 bytes (as it should) but these are wrongly sourced from every other 4-byte page of the 1024 byte EEPROM on the connected 328p (obvs you'd have to store some suitable pattern in the EEPROM to notice).

If stk500.c is right (and my suspicion wrong) then optiboot would need do something about EEPROM addresses of the parts mentioned...

[stefanrueger]

I wonder how an attached STK500 (v1) programmer would suss out whether to expect from AVRDUDE a byte address (eg, ATmega128) or a word address (eg, ATmega328) for the (STK500-protocol) paged EEPROM access (which I guess will be emulated with EEPROM byte read/writes in the physical programmer). It's possible (in theory the firmware is told a device code), but not really plausible.

I have managed to find a couple of sources for the AVRISP firmware: both clearly always expect word addresses (as does optiboot). So looks like the avrisp programmer is affected, too.

Currently, the tally programmers vs stk500.c stands at 2:0

Anyone with a real STK500v1 programmer and some of the above chips with more intel?

[dl8dtl]

If you're interested, I could get you a genuine STK500v1 firmware image for testing. ;-)

[dl8dtl]

Maybe I even have one STK that's still at v1, I'm not sure. I used to keep one as a reference …

[stefanrueger]

If you're interested, I could get you a genuine STK500v1 firmware image for testing. ;-)

Thanks, but would need chips/boards of some of the 23 affected chips, too... So no, and best to leave that with the hardware experts :-). Actually, only the firmware source is needed (but I guess Atmel's will be closed?)

But for me this is one more reason to write a dedicated SPM programmer for AVRDUDE that does not rely on the current stk500 implementation. In fact, I noticed this issue when looking through stk500.c to implement "backward compatibility" in that SPM programmer.

[dl8dtl]

Actually, only the firmware source is needed (but I guess Atmel's will be closed?)

So it is. All we've got is a binary blurb, to fit into the AT90S8535 on the STK.

Please provide a few commands you'd like me to test, and I'll see whether I can run some tests. At least, ATmega8 and ATmega128, I do have some.

[dl8dtl]

Btw., I'd normally consider the STK500v1 protocol quite obsolete anyway. Atmel did that many years ago. ;-) Let's spend not too much time into such a dead horse.

[stefanrueger]

The stk500.c protocol implementation is used for some programmers and optiboot (with millions and millions of uploads), so we might as well get this right. It's probably more that EEPROM upload/download with the affected parts do not happen that often.

Please provide a few commands

I'd generate a random hex file with as many bytes as the EEPROM holds (512 for the ATmega8, I think)

$ head -512c /dev/urandom | srec_cat - -binary -o - -intel > /tmp/rnd.eep

Upload that to the ATmega8's EEPROM; verification should fail. (Note if you do the same with a file that is half the EEPROM size then verification should pass, but the data would be at the wrong location.)

Or, could prepare two different .hex files:

$ yes The quick brown fox jumps over the lazy dog             | head -512c | srec_cat - -binary -o - -intel >/tmp/en.eep
$ yes Z jagt im komplett verwahrlosten Taxi quer durch Bayern | head -512c | srec_cat - -binary -o - -intel >/tmp/de.eep

Upload /tmp/en.eep to the EEPROM of the ATmega8 (with a reliable programmer) Upload /tmp/de.eep to the EEPROM of the ATmega8 with the STK500v1 programmer

Look at the eeprom with the reliable programmer:

avrdude -qq -c ... -U eeprom:r:-:r

Should be something like (but not literally so)

Z jaquicgt iown m kojumpmpleer ttt vazy erwaThe hrlok brstenfox  Taxs pvi quhe ler ddog
urchquic Bayown ern
jumpZ jaer tgt iazy m koThe mplek brtt vfox erwas pvhrlohe lstendog
 Taxquici quown er djumpurcher t Bayazy ern
The Z jak brgt ifox m kos pvmplehe ltt vdog
erwaquichrloown stenjump Taxer ti quazy er dThe urchk br Bayfox ern
s pvZ jahe lgt idog
m koquicmpleown tt vjumperwaer thrloazy stenThe  Taxk bri qufox er ds pvurchhe l Baydog
ern
quicZ jaown gt ijumpm koer tmpleazy tt vThe erwak brhrlofox stens pv

If the real STK500v1 programmer passes, I predict that AVRISP programmers fails the test. Optiboot does above when AVRDUDE pretends the 328p is an 8 using -F.

[dl8dtl]

The "srec_cat" is not needed: AVRDUDE could always write raw binary files (file type "r"). Reprogramming the STK was easy enough to give it a try. Here's the readout of the "quick brown fox" file with an AVRISPmkII:

% ./build_freebsd/src/avrdude -c avrisp2 -p m8 -t

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9307 (probably m8)
avrdude> d ee
>>> d ee 

Reading | ################################################## | 100% 0.15s

0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0020  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0030  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
0040  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|

avrdude> d ee
>>> d ee 

Reading | ################################################## | 100% 0.15s

0100  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0110  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0120  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0130  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0140  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0150  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
0160  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0170  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0180  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0190  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
01a0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
01b0  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
01c0  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
01d0  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
01e0  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
01f0  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|

avrdude>

I guess that is proof enough that the AVRDUDE stk500v1 protocol implementation matches an STK500v1 firmware …

Device: ATmega8A (after all, they're still in production), STK500 firmware version 1.14 (decimal, as usually in AVRDUDE). I believe that to be the latest V1 firmware. I just keep the firmware in the STK until tonight, in case you'd like me to perform more tests. Afterwards, will reflash it to V2.

[mcuee]

If you're interested, I could get you a genuine STK500v1 firmware image for testing. ;-)

Just wondering how I can check if an STK500 is of V1 or V2 firmware. I have found an unused genuine Atmel STK500 from 2006 (or earlier?) and it does not seem to work with either avrdude (error message: avrdude stk500_recv() programmer is not responding ) or Atmel Studio 4.19 or Atmel Studio 7.0 (firmware upgrade failed). Maybe it is broken. I will try again.

[dl8dtl]

If you call AVRDUDE with -c stk500, it attempts some auto-probing. It's not that easy, and quite a bit of guesswork. Drop me a mail if you'd like to get a firmware file to upgrade (or downgrade) yourself; the bootloader (actually a separate AT90S2313 on the STK500) talks avr910 protocol.

[dl8dtl]

Btw., IMHO AVRDUDE's STK500v1 protocol implementation mostly wraps around the SPI_MULTI command, issuing its own idea of ISP commands. Back two decades ago, when someone contributed us the STK500 implementation, that seemed to be the fastest way to handle STK500s at all: the ISP command stuff was already there (AVRDUDE started out with the "classic" parallel-port bit-bangers of those days), so handling the STK500 protocol took only a bit of wrap-up to initialize the programmer and such. We've been doing that even in STK500v2 for many years, and only switched to real protocol commands a few years ago.

[stefanrueger]

I guess that is proof enough that the AVRDUDE stk500v1 protocol implementation matches an STK500v1 firmware …

Cool! And thanks for going to the trouble of verifying that.

Which makes dealing with the derived AVRDUDE programmers somewhat harder, because the attached programmers (AVRISP, ATmega8 boards with optiboot's vector bootloader, ...) don't for a moment think that any STK500v1 address could be a byte address: -c avrisp should expose the problem mentioned, as does -c arduino which I see after uploading something with

avrdude -qq -p atmega8 -F -c arduino -b 115200 -P /dev/ttyUSB0 -U eeprom:w:fox.eep:i

I know what modification in arduino.c would solve this issue but not so sure about the other derived programmers.

[stefanrueger]

The "srec_cat" is not needed: AVRDUDE could always write raw binary files (file type "r")

... and read from pipeline. Cool. I initially tried constructing a pattern and pipe with the file type "d", which does not allow reads:

$ echo {0..255} {255..0} | tr \  , | avrdude -qq -p m328p -c urclock -P /dev/ttyUSB0 -U eeprom:w:-:d
avrdude: fileio: invalid operation=0
avrdude: read from file '-' failed

[dl8dtl]

It would be interesting to dig out an old version of AVR Studio (4.something), and see what it does when being faced with such a bootloader.

[mcuee]

Does the STK500 v1 communication protocol can explain the question? Or we really have to test on a real STK500 with V1 FW? http://ww1.microchip.com/downloads/en/AppNotes/doc2525.pdf

STK500 v2 is also documented. https://ww1.microchip.com/downloads/en/Appnotes/doc2591.pdf

[dl8dtl]

Or we really have to test on a real STK500 with V1 FW?

That's what I did.

[mcuee]

Which makes dealing with the derived AVRDUDE programmers somewhat harder, because the attached programmers (AVRISP, ATmega8 boards with optiboot's vector bootloader, ...) don't for a moment think that any STK500v1 address could be a byte address.

Now the thing is that probably there is no real need to support real STK500 with V1 protocol any more since it has be obsolete for many years (only V2 support is needed, V2 FW was distributed with AVR Studio 4.11 build 401 or later), that probably means in 2005.

The things to support is the derived programmers which may not exactly follow the STK500 v1 protocol to the letter. Does this make the solution a bit easier?

[mcuee]

It would be interesting to dig out an old version of AVR Studio (4.something), and see what it does when being faced with such a bootloader.

Then you need really old version of Atmel Studio (prior to 4.11 build 401) which is no longer available from Atmel/Microchip (earliest version is 4.13). https://www.microchip.com/en-us/tools-resources/archives/avr-sam-mcus

Google does find a link. Not so sure how good the Russian link mentioned in the forum post is good or not. https://www.avrfreaks.net/forum/downloading-old-version-avr-studio-410

[stefanrueger]

@mcuee Atmel's STK500 v1 docu is non-committal about whether the addresses are byte or word addresses and certainly does not say anything about which memories of which parts will be treated as what. Whoever wrote the lines

https://github.com/avrdudes/avrdude/blob/4601bee4afa76fb4aa8392ffdd4a4dd56ede1bae/src/stk500.c#L819-L822

clearly knew something that cannot be augured from Atmel's 31 page v1 docu. In contrast to this, the STK500 v2 docu on this point is lucid, sane and simple: flash addresses to be sent as word addresses, all other memory addresses as byte addresses.

Given the closed-source nature of Atmel's implementation of its protocol it is quite understandable that others have interpreted the protocol to mean both flash and EEPROM access is always done with word addresses.

AVRDUE only invokes the programmer's _paged_load() and _paged_write() when the memory page size exceeds 1. It so turns out that only EEPROM r/w for ATmega64 ATmega64A ATmega128 ATmega128A ATmega8 ATmega8A are affected by this issue. But see also Issue #970 that affects bootloaders.

Jörg has proven AVRDUDE's stk500 implementation correct in these cases. Well, the ATmega8A, but I take the extrapolation to the others as given.

I see some possible solutions:

1. Deprecate the "pure" STK500 v1 support and change above code to simply a_div = 2 (accept that the STK500 kit with FW version 1.xx is a dead horse)
2. Create a new AVRDUDE programmer stk500v1w that imports the stk500 (v1) programmer and change paged access to be always through word addresses. Modify .conf for these programmers to be based on stk200v1w
3. Change all STK500 derived programmers to swap out their paged memory access functions

Thoughts?

[mcuee]

@stefanrueger IMHO Option 1 should be the preferred way to go. But @dl8dtl will have to agree.

Option 2 is of course okay as well but it is a bit wasted (kind of redundant codes).

[mcuee]

It would be interesting to dig out an old version of AVR Studio (4.something), and see what it does when being faced with such a bootloader.

I have got avrdude 3.56 and 4.10 installed under Windows 11. Just wondering how to test this case.

I have the official Arduino Leonardo board and clone Arduino Uno with CH340. 1) how to trigger the Arduino board in bootloader mode? 2) I see one problem that usually the COM port of my Arduino boards can not be reassigned to COM1/2/3/4.

[stefanrueger]

@mcuee

Doesn't have to be an arduino board to use -c arduino. These days (I guess) the AVRDUDE arduino programmer is used to upload to bootloaders that follow a skelton STK500 v1 protocol. Optiboot is probably the most popular of these. Can be compiled for a lot of parts, even those without bootloader support (switch on virtual bootloader or something).

Triggering the bootloader is its own artform. Most simply need to be reset shortly before talking to them (the main difference between -c arduino and -c stk500v1) is that arduino twitches the DTR/RTS line that some boards couple to the mcu's reset via a cap and pullup to Vcc to send a reset pulse. You can do that by hand, but then need to start arduino shortly after, so the bootloader doesn't time out.

Afraid I cannot help with windows driver etc to connect COMx to the various FTDI/CH340/CH330N/... chips.

[stefanrueger]

I'd be happy to do a PR for 1 or 2 if/when the current PRs are processed one way or another.

The second option isn't too much code duplication, as the code base is vvv modular and requires essentially two functions to be overloaded (paged access). And it's neat because it is backwards compatible to very early and old programmer boards/FW.

[mcuee]

Afraid I cannot help with windows driver etc to connect COMx to the various FTDI/CH340/CH330N/... chips.

No problems. I am kind of cross-platform guy (at least Linux, macOS and Windows, sometimes also BSDs) since I carry out testing for cross-platform projects (eg: libusb, hidapi, libftdi, pyusb, libusbdotnet and OpenOCD).

Interestingly I do not have problems to set the FTDI/CH340/CP2102/etc based USB to Serial Converter to use COM1/2/3/4 under Windows but not the two Arduino boards. Very strange.

This seems to be an interesting question from @dl8dtl.

It would be interesting to dig out an old version of AVR Studio (4.something), and see what it does when being faced with such a bootloader.

[mcuee]

Doesn't have to be an arduino board to use -c arduino. These days (I guess) the AVRDUDE arduino programmer is used to upload to bootloaders that follow a skelton STK500 v1 protocol. Optiboot is probably the most popular of these. Can be compiled for a lot of parts, even those without bootloader support (switch on virtual bootloader or something).

I'd be happy to do a PR for 1 or 2 if/when the current PRs are processed one way or another.

The second option isn't too much code duplication, as the code base is vvv modular and requires essentially two functions to be overloaded (paged access). And it's neat because it is backwards compatible to very early and old programmer boards/FW.

Good to know that. In that case, maybe Option 2 is better as we know that this types of bootloaders are not really the same as stk500v1, but rather a subset only.

Ref: https://github.com/Optiboot/optiboot/wiki/HowOptibootWorks Optiboot implements a small subset of the "STK500 communications protocol" (version 1) defined by Atmel in their Application Note AVR061 In order to conserve code space, many of the protocol commands are ignored and receive "lies" rather than correct response codes, leading to the possibility that the bootloader may not operate correctly with all host-side software. It is known to work with versions of "avrdude" supporting the "-c arduino" programmer type.

[stefanrueger]

OK, seeing that this is the known Issue #421 we might consider doing nothing here.

@dl8dtl has proven the stk500.c implementation correct for the STK500 kit with v1 FW. Folks who have recognised the problem in the current issue a long time ago for their own programmer firmware/bootloader may/will have solved that issue on their side, so any change now will create backward compatibility issues with them.

I still think it is a good idea to provide an alternative programmer to arduino with its own protocol that does not have this, ahem, unusual byte/word protocol interpretation quirk and that solves the shortcomings of AVRDUDE's arduino programmer for compact bootloaders as mentioned in Discussion #940 (eg, that these use atomic page erase and write rather than chip erase or page erase on its own, that these only implement paged access for EEPROM/flash not byte access etc).

[mcuee]

I still think it is a good idea to provide an alternative programmer to arduino with its own protocol that does not have this, ahem, unusual byte/word protocol interpretation quirk and that solves the shortcomings of AVRDUDE's arduino programmer for compact bootloaders as mentioned in Discussion https://github.com/avrdudes/avrdude/discussions/940.

Yes I agree. I beliver what I mentioned below in #970 is in line with what you are saying. Correct me if I am wrong. Thanks.

• https://github.com/avrdudes/avrdude/issues/970#issuecomment-1134054077

  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.

[mcuee]

stk500v2 bootloader for the Arduino Mega2560 seems to have EEPROM read problem as well.

• https://github.com/avrdudes/avrdude/issues/515

Edit to add: this is confirmed to be a problem with the bootloader and not avrdude.

• https://github.com/arduino/ArduinoCore-avr/pull/24

[mcuee]

I tend to believe the default arduino bootloader for the Uno does not even support writing EEPROM. I think Arduino's official workaround seems to provide the EEPROM examples for that purpose.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> echo "write eeprom 0x00 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0x00 1 2 3" | ./avrdude -c arduino -P COM23 -p atmega328p -t

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

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

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude> >>> write eeprom 0x00 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0x00 1 2 3

Writing |                                                    | 0% 0.00savrdude.exe (write): error writing 0x01 at 0x00000, rc=-6
avrdude.exe (write): error writing 0x01 at 0x00000 cell=0x00
avrdude.exe (write): error writing 0x02 at 0x00001, rc=-6
avrdude.exe (write): error writing 0x02 at 0x00001 cell=0x00
Writing | ###                                                | 5% 0.08savrdude.exe (write): error writing 0x03 at 0x00002, rc=-6
avrdude.exe (write): error writing 0x03 at 0x00002 cell=0x00
Writing | #####                                              | 10% 0.11savrdude.exe (write): error writing 0x04 at 0x00003, rc=-6
avrdude.exe (write): error writing 0x04 at 0x00003 cell=0x00
Writing | ########                                           | 15% 0.15savrdude.exe (write): error writing 0x05 at 0x00004, rc=-6
avrdude.exe (write): error writing 0x05 at 0x00004 cell=0x00
Writing | ##########                                         | 20% 0.19savrdude.exe (write): error writing 0x06 at 0x00005, rc=-6
avrdude.exe (write): error writing 0x06 at 0x00005 cell=0x00
Writing | #############                                      | 25% 0.23savrdude.exe (write): error writing 0x07 at 0x00006, rc=-6
avrdude.exe (write): error writing 0x07 at 0x00006 cell=0x00
Writing | ###############                                    | 30% 0.28savrdude.exe (write): error writing 0x08 at 0x00007, rc=-6
avrdude.exe (write): error writing 0x08 at 0x00007 cell=0x00
Writing | ##################                                 | 35% 0.31savrdude.exe (write): error writing 0x09 at 0x00008, rc=-6
avrdude.exe (write): error writing 0x09 at 0x00008 cell=0x00
Writing | ####################                               | 40% 0.35savrdude.exe (write): error writing 0x0a at 0x00009, rc=-6
avrdude.exe (write): error writing 0x0a at 0x00009 cell=0x00
Writing | #######################                            | 45% 0.40savrdude.exe (write): error writing 0x0b at 0x0000a, rc=-6
avrdude.exe (write): error writing 0x0b at 0x0000a cell=0x00
Writing | #########################                          | 50% 0.44savrdude.exe (write): error writing 0x0c at 0x0000b, rc=-6
avrdude.exe (write): error writing 0x0c at 0x0000b cell=0x00
Writing | ############################                       | 55% 0.48savrdude.exe (write): error writing 0x0d at 0x0000c, rc=-6
avrdude.exe (write): error writing 0x0d at 0x0000c cell=0x00
Writing | ##############################                     | 60% 0.52savrdude.exe (write): error writing 0x0e at 0x0000d, rc=-6
avrdude.exe (write): error writing 0x0e at 0x0000d cell=0x00
Writing | #################################                  | 65% 0.56savrdude.exe (write): error writing 0x0f at 0x0000e, rc=-6
avrdude.exe (write): error writing 0x0f at 0x0000e cell=0x00
Writing | ###################################                | 70% 0.60savrdude.exe (write): error writing 0x10 at 0x0000f, rc=-6
avrdude.exe (write): error writing 0x10 at 0x0000f cell=0x00
Writing | ########################################           | 80% 0.65savrdude.exe (write): error writing 0x01 at 0x00011, rc=-6
avrdude.exe (write): error writing 0x01 at 0x00011 cell=0x00
Writing | ###########################################        | 85% 0.69savrdude.exe (write): error writing 0x02 at 0x00012, rc=-6
avrdude.exe (write): error writing 0x02 at 0x00012 cell=0x00
Writing | #############################################      | 90% 0.73savrdude.exe (write): error writing 0x03 at 0x00013, rc=-6
avrdude.exe (write): error writing 0x03 at 0x00013 cell=0x00
Writing | ################################################## | 100% 0.77s

avrdude>
avrdude.exe done.  Thank you.

[mcuee]

@stefanrueger Just wondering what is confirmed to be a working EEPROM capable bootloader.

I tried the hex file here from @MCUdude which is supposed to work with EEPROM and it does not seem to work either. I have tried two Arduino Uno boards (one clone with ATmega16U2 and one clone with CH340).

https://github.com/MCUdude/MiniCore/blob/master/avr/bootloaders/optiboot_flash/bootloaders/atmega328p/16000000L/optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> .\avrdude -p atmega328p -c dragon_isp -P usb -U .\optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex -v

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/avrdude_test/avrdude-v7.0-windows-x64/avrdude.conf"

             Using Port                    : usb
             Using Programmer              : dragon_isp
avrdude.exe: usbdev_open(): Found AVRDRAGON, serno: 00A200001487
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        255
  firmware version:              7.39
  hardware version:              1
S_MCU:
  boot-loader FW version:        255
  firmware version:              7.39
  hardware version:              2
Serial number:                   00:a2:00:00:14:87
Device ID:                       AVRDRAGON
             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 : DRAGON_ISP
             Description     : Atmel AVR Dragon in ISP mode
             Vtarget         : 4.9 V
             SCK period      : 1.00 us

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

Reading | ################################################## | 100% 0.15s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file ".\optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex"
avrdude.exe: input file .\optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex auto detected as Intel Hex
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against .\optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex:
avrdude.exe: input file .\optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex auto detected as Intel Hex

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

avrdude.exe: 32768 bytes of flash verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -p atmega328p -c arduino -b 115200 -P COM9 -t

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

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

avrdude.exe: Device signature = 0x1e950f
avrdude> d ee
>>> d ee
avrdude.exe: stk500_cmd(): programmer is out of sync

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -p atmega328p -c arduino -b 115200 -P COM9 -U eeprom:w:entest.eep:i

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

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

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

Writing |                                                    | 0% 0.00s
avrdude.exe: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x14
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
Writing | #                                                  | 1% 10.44s ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
...
 ***failed;
 ***failed;
 ***failed;
 ***failed;
Writing | ################################################## | 100% 45.61s

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% 1.16s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x54 != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe: safemode: Fuses OK

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -p atmega328p -c arduino -b 115200 -P COM6 -t

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

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

avrdude.exe: Device signature = 0x1e950f
avrdude> d ee
>>> d ee
0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

avrdude> w ee 0 1 2 3 4 5 6 7
>>> w ee 0 1 2 3 4 5 6 7
avrdude.exe: stk500_cmd(): programmer is out of sync

[mcuee]

@stefanrueger Just wondering what is confirmed to be a working EEPROM capable bootloader.

I tried the hex file here from @MCUdude which is supposed to work with EEPROM and it does not seem to work either. I have tried two Arduino Uno boards (one clone with ATmega16U2 and one clone with CH340).

https://github.com/MCUdude/MiniCore/blob/master/avr/bootloaders/optiboot_flash/bootloaders/atmega328p/16000000L/optiboot_flash_atmega328p_UART0_115200_16000000L_B5.hex

@stefanrueger and @MCUdude I found the working optiboot bootloader hex file for my Uno (ATmega328P) from @WestfW which works with my Arduino Uno. https://forum.arduino.cc/t/optiboot-w-eeprom-support-through-avrdude/966939/5

• https://github.com/avrdudes/avrdude/issues/986#issuecomment-1146729055

bigboot_328.hex.zip

[WestfW]

I tend to believe the default arduino bootloader for the Uno does not even support writing EEPROM.

that's correct. It doesn't fit. (the default arduino bootloader is a quite old version of optiboot, and it will actually overwrite flash when given EEPROM commands. ( https://github.com/Optiboot/optiboot/issues/65 )

The larger version of Optiboot (BIGBOOT=1) does support EEPROM, but not on ATmega8 due to this database issue, tagged in optiboot as: https://github.com/Optiboot/optiboot/issues/235

AFAIK, the EEPROM in the chips is essentially identical in m8 vs m328; it's only the avrdude database (and/or the Atmel stk500 code and support?) that thinks the 328 should have a word address for byte-writable memory. :-(

[mcuee]

From the above testing results, real STK500 with v1 FW works fine with avrdude's STK500 v1 implementation. It is just that Arduino's bootloader or optiboot's implementation of the STK500 v1 protocol may not match the real Atmel STK500.

And I can say that the official Arduino's bootloader which uses the older version of optiboot will any way not support EEPROM. Even Arduino Mega2560's stk500v2 bootloader does not support EEPROM read properly due to a long standing bug. https://github.com/arduino/ArduinoCore-avr/pull/24

So the issue is summarized well by @stefanrueger here.

• https://github.com/avrdudes/avrdude/issues/970#issuecomment-1133667225

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

[mcuee]

Valid and interesting comments by @dl8dtl

• https://github.com/avrdudes/avrdude/pull/936#issuecomment-1111394281

  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]

The proper solution for this issue may be here by @stefanrueger

• https://github.com/avrdudes/avrdude/issues/970#issuecomment-1136089430

[stefanrueger]

Valid and interesting comments by @dl8dtl

Just keep in mind, if you call it STK500, it must behave as if it were an STK500. [...]

Correct, and that's why I plan to call the protocol for dedicated bootloader support urprotocol and not STK500vx :). It will be documented (well, better documented than STK500v1 anyway) and should help bootloader writers to stay on the straight and narrow.

[mcuee]

I have managed to find a couple of sources for the AVRISP firmware: both clearly always expect word addresses (as does optiboot). So looks like the avrisp programmer is affected, too.

Not so sure if I can use "Arduino as ISP" to test out avrisp.

I am also trying to get clones of STK500 and AVR ISP MK II since my original Atmel STK500 is dead.

[mcuee]

I have managed to find a couple of sources for the AVRISP firmware: both clearly always expect word addresses (as does optiboot). So looks like the avrisp programmer is affected, too.

Not so sure if I can use "Arduino as ISP" to test out avrisp.

@stefanrueger Yes I can reproduce the reported issue as well with avrisp using "Arduino as ISP". The issue will happen if using ATmega8. I have used usbasp to write the eeprom with the known test pattern and verify that avrisp will read it correctly with ATmega328p but not ATmega8.

This proves that "Arduino as ISP" does not follow the real stk500 v1 either.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m328p -c usbasp -U eeprom:r:-:r
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov
                                   
PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m8 -F -c usbasp -U eeprom:r:-:r
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m328p -c avrisp -P COM3 -b 19200 -U eeprom:r:-:r
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov  

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m8 -F -c avrisp -P COM3 -b 19200 -U eeprom:r:-:r
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07
The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jump  

[mcuee]

BTW, ScratchMonkey sketch (stk500v2) works fine. I like it better than "Arduino as ISP".

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m328p -c stk500v2 -P COM3 -U eeprom:r:-:r
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m8 -F -c stk500v2 -P COM3 -U eeprom:r:-:r
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov

[stefanrueger]

This proves that "Arduino as ISP" does not follow the real stk500 v1 either.

Good to have that intell. Seems that optiboot and Arduino as ISP both implement all paged memory access expecting word addresses. The EEPROM page size is 4, hence, every other page is omitted on the ATmega8 readout (that, for this MCU is sent as byte address).

Given @WestfW 's comment above I get the feeling that the following historic scenario is also possible. Perhaps the lines https://github.com/avrdudes/avrdude/blob/4601bee4afa76fb4aa8392ffdd4a4dd56ede1bae/src/stk500.c#L819-L822 are actually plain wrong for EEPROM memory because that should always be byte addressed. If so then, these lines affect all parts except the ones I mentioned above (so some 100+ "old" parts nowadays including the ATmega328P). People at the time didn't realise. When Arduino as ISP, optiboot, etc came along, these projects chose AVRDUDE + STK500v1 as the upload buddy for the popular ATmega328P and similar parts. These projects will have observed that AVRDUDE + STK500v1 sends word addresses across for EEPROM paged access, and adapted accordingly. They would not have anticipated that for some parts a byte address might be sent, and why would they?

Almost makes me regret not having asked @dl8dtl a few weeks ago to check the ATmega328P in addition to the ATmega8.

Almost, because ultimately @dl8dtl is right in that there is little point in flogging a dead horse: As the firmware of the STK500 kit has moved on, the projects that still use AVRDUDE's STK500v1 implementation (optiboot etc) have become used to it, rightly or wrongly. Any change on the AVRDUDE side might upset projects that have adapted to this quirky protocol and rely on it now.

I will finalise my urclock programmer that is aware of all these issues and implements an urprotocol that is backwards compatible with -c arduino and falls back on what optiboot needs by sending word addresses for paged EEPROM access for all parts (including the ATmega8) and changes slightly tack for my own urboot bootloaders, which is to always send byte addresses for all access of all memories on all parts because SPM/LPM actually requires byte addresses.

[mcuee]

Good to have that intell. Seems that optiboot and Arduino as ISP both implement all paged memory access expecting word addresses. The EEPROM page size is 4, hence, every other page is omitted on the ATmega8 readout (that, for this MCU is sent as byte address).

Given @WestfW 's comment above I get the feeling that the following historic scenario is also possible. Perhaps the lines

https://github.com/avrdudes/avrdude/blob/4601bee4afa76fb4aa8392ffdd4a4dd56ede1bae/src/stk500.c#L819-L822

are actually plain wrong for EEPROM memory because that should always be byte addressed. If so then, these lines affect all parts except the ones I mentioned above (so some 100+ "old" parts nowadays including the ATmega328P).

This does not match my test results using "Arduino as ISP". It works with ATmega328P for EEPROM (write and read) but not ATmega8. The run log is shown here.

• https://github.com/avrdudes/avrdude/issues/990#issuecomment-1153858247

[mcuee]

@stefanrueger Here is the test result using "Arduino as ISP" and ATmega328P (on the Uno). Here I use explicitly stk500v1 and not arvisp and you can see that it works with both writing and reading of EEPROM of the ATmega328P.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> ./avrdude -p atmega328p -c stk500v1 -b 19200 -P COM3 -U eeprom:w:.\entest.eep -v

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/avrdude_test/avrdude-v7.0-windows-x64/avrdude.conf"

             Using Port                    : COM3
             Using Programmer              : stk500v1
             Overriding Baud Rate          : 19200
             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 : STK500
             Description     : Atmel STK500 Version 1.x firmware
             Hardware Version: 2
             Firmware Version: 1.18
             Topcard         : Unknown
             Vtarget         : 0.0 V
             Varef           : 0.0 V
             Oscillator      : Off
             SCK period      : 0.1 us

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

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading input file ".\entest.eep"
avrdude.exe: input file .\entest.eep auto detected as Intel Hex
avrdude.exe: writing eeprom (512 bytes):

Writing | ################################################## | 100% 24.88s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against .\entest.eep:
avrdude.exe: input file .\entest.eep auto detected as Intel Hex

Reading | ################################################## | 100% 1.63s

avrdude.exe: 512 bytes of eeprom verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> echo "read eeprom 0 0x300" | ./avrdude -c usbasp -p atmega328p -t

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

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

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude> >>> read eeprom 0 0x300

Reading | ################################################## | 100% 0.55s

0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0020  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0030  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
0040  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0100  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0110  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0120  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0130  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0140  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0150  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
0160  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0170  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0180  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0190  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
01a0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
01b0  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
01c0  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
01d0  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
01e0  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
01f0  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0210  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0220  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0230  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0240  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0250  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0260  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0270  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0280  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0290  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> echo "read eeprom 0 0x300" | ./avrdude -c stk500v1 -P COM3 -b 19200 -p atmega328p -t

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

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude> >>> read eeprom 0 0x300

Reading | ################################################## | 100% 5.08s

0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0020  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0030  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
0040  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0100  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0110  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0120  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0130  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0140  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0150  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
0160  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0170  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0180  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0190  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
01a0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
01b0  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
01c0  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
01d0  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
01e0  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
01f0  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0210  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0220  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0230  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0240  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0250  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0260  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0270  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0280  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0290  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude.exe done.  Thank you.

[mcuee]

@stefanrueger I also see differences between terminal mode and your command mode if I force the chip to be ATmega8 with -F. Is is true that -F will not be effective in terminal mode? In the terminal mode I can not reproduce the issue. Strange.

BTW, in my testing, -c avrisp and -c stk500v1 seem to be the same for the "Arduino as ISP" sketch.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> echo "read eeprom 0 0x300" | ./avrdude -c stk500v1 -P COM3 -b 19200 -p atmega8 -F -t

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

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: Expected signature for ATmega8 is 1E 93 07
avrdude> >>> read eeprom 0 0x300

Reading | ################################################## | 100% 3.41s

0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0020  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0030  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
0040  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0100  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0110  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0120  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0130  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0140  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0150  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
0160  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0170  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0180  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0190  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
01a0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
01b0  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
01c0  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
01d0  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
01e0  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
01f0  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|

avrdude>
avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> echo "read eeprom 0 0x300" | ./avrdude -c avrisp -P COM3 -b 19200 -p atmega8 -F -t

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

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: Expected signature for ATmega8 is 1E 93 07
avrdude> >>> read eeprom 0 0x300

Reading | ################################################## | 100% 3.41s

0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0020  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0030  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
0040  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0100  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0110  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0120  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0130  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0140  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0150  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
0160  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0170  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0180  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0190  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
01a0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
01b0  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
01c0  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
01d0  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
01e0  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
01f0  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|

avrdude>
avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m8 -F -c avrisp -P COM3 -b 19200 -U eeprom:r:-:r
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07
The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jump                                                                                                                                                                                                                                                                
PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> avrdude -qq -p m8 -F -c stk500v1 -P COM3 -b 19200 -U eeprom:r:-:r
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07
The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jumper tazy The k brfox s ovhe ldog
quicown jump                    

[mcuee]

Another thing, just FYI, stk500v2 bootloader (with EEPROM read fix) for the Arduino Mega2560 works fine with EEPROM. Same for usbtiny and usbasp.

Test case: using the correct -p m2560 to write the test EEPROM pattern and then readback using different programmer.

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> .\avrdude -qq -p m8 -F -c wiring -P COM3 -U eeprom:r:-:r
avrdude.exe: Expected signature for ATmega8 is 1E 93 07
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov

PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> .\avrdude -qq -p m8 -F -c usbasp -D -U eeprom:r:-:r
avrdude.exe: Expected signature for ATmega8 is 1E 93 07
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov
PS C:\work\avr\avrdude_test\avrdude-v7.0-windows-x64> .\avrdude -qq -p m8 -F -c usbtiny -D -U eeprom:r:-:r
avrdude.exe: Expected signature for ATmega8 is 1E 93 07
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps ov

[stefanrueger]

@mcuee

Is is true that -F will not be effective in terminal mode?

No, -F always works, but by switching to terminal mode AVRDUDE uses byte-wise access, so no longer paged access. Remember, there are three different issues that need careful separation

1. This issue is merely about paged EEPROM access for AVRDUDE's STK500v1 implementation
2. Issue 970 is about how AVRDUDE decides to use paged EEPROM access vs byte-wise access (any programmer)
3. Discussion 940 notes the implications of terminal mode's always-byte-wise access

2 and 3 are a problem for bootloaders because they, by and large, do not implement byte-wise access, only paged access.

[...] This does not match my test results using "Arduino as ISP".

I think it might do in the following sense. We are back to 1, the issue at hand. As I understand it, AVRDUDE's STK500v1 implementation was meant to serve Atmel's STK500 kit with v1 FW, which the AVRDUDE project views as the defining gold standard of what STK500 v1 should mean in absence of clear documentation and in absence of open source code of the STK500 kit FW v1. AVRDUDE's implementation uses two different equivalence classes for MCUs:

• ATmega8 et al (6 "old" parts) with EEPROM paged access using byte addresses
• ATmega328P et al (100+ "old" parts) with EEPROM paged access using word addresses

@dl8dtl proved AVRDUDE's STK500v1 implementation correct for ATmega8 et al on the defining, gold standard STK500 v1 kit.

I had always assumed that AVRDUDE's STK500v1 implementation would be correct for the STK500 v1 kit with ATmega328P et al: so popular, so many parts in that family, such a high standard of implementation in AVRDUDE, someone would have noticed over the years, etc. It's just that @WestfW's comment made me think my assumption might have been wrong. So, what's outstanding is an actual EEPROM check for "the defining" STK500 kit v1 on ATmega328P et al. That's all.

But it doesn't matter, because, in reality, AVRDUDE has gained so much traction that these days actually everyone would use the AVRDUDE behaviour as gold standard. And in a sense you have to, as that's the tool that people use for upload/download.

So, rightly or wrongly, several other programmer firmware/bootloader software latched on to how AVRDUDE seems to get things done but never closely read the AVRDUDE source: Arduino as ISP, optiboot etc. They only ever implement paged EEPROM word addresses (a quick scan of the source tells me that), so out of necessity these fail ATmega8 et al, but work for ATmega328P et al. Good to see your verification of these predictions on Arduino as ISP with your experiments.

[mcuee]

@stefanrueger Thanks a lot for the detailed explanation. Now I know a bit more about the inner working of EEPROM access in avrdude (not a programmer so that it will take time for me to understand the codes).

So, what's outstanding is an actual EEPROM check for "the defining" STK500 kit v1 on ATmega328P et al. That's all.

@dl8dtl Just to close on this last one, hope you can check when you have some time.

It is unfortunate my original STK500 is really dead now (traces broken when I removed the ATtiny2313...). It was not working before either but I was hopping re-flashing the ATmega8535 may fix it. I am still trying to get a clone but I doubt it will be compatible with V1 FW (the clones tend to be compatible with V2 FW and may like AVRISP mkII and not STK500).

[mcuee]

I will label this as enhancement for now -- not for the real STK500 with V1 FW, but rather other implementations which claims to be stk500v1 compatible (like optiboot bootloader and Arduino as ISP.

[stefanrueger]

I see some possible actions on this issue

1. Deprecate the "pure" STK500 v1 support and change above code to simply a_div = 2 (accept that the STK500 kit with FW version 1.xx is a dead horse)
2. Create a new AVRDUDE programmer stk500v1w that imports the stk500 (v1) programmer and change paged access to be always through word addresses. Modify .conf for these programmers to be based on stk200v1w
3. Change all STK500 derived programmers to swap out their paged memory access functions
4. Do nothing

Impact analysis:

1. Impacts users with the STK500 kit with vvv old FW, but also bootloader writers using -c arduino who realised what the current implementation does and adapted (the latter group has the skills to adapt again and won't need our help). Automagically helps optiboot users (who have compiled for ATmega8A et al with EEPROM support). Automagically helps Arduino for ISP physical programmers.
2. Proliferation of programmers in AVRDUDE; Users have a choice of -c programmers. needs a modicum of documentation
3. More work. Will impact a few groups of users at the same time
4. Easy for us, but this has come up a number of times in the past

[mcuee]

@dl8dtl and @stefanrueger I vote for Option 1. I think all the users of STK500 probably have moved on to V2 FW. Same for the original AVRISP (aka AVRISP MKi).

[MCUdude]

I don't see a good reason to keep an old STK500 board stuck at stk500v1 when v2 is better in any way. I'm fine with dropping support for legacy STK500 firmware as long as it doesn't affect other programmers based on the stk500v1 protocol, such as Optiboot and Arduino as ISP.