`-c arduino` issue with Arduino optiboot bootloader which does not support EEPROM

[mcuee]

I was testing PR #1373 and then I see the following issue with -c arduino. Arduino will use old optiboot version which does not support EEPROM on quite some AVR chips, including ATmega328P.

avrdude: AVR device initialized and ready to accept instructions
0 0000-00-00 00.00  application 0 store 0 meta 1 boot 512 o4.4 --s-h-r-- vector 0 (RESET) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c arduino -p m328p -P COM12 -U eeprom:w:entest.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: reading input file entest.hex for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 128 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
Writing | ################################################## | 100% 2.06 s
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against entest.hex
Reading | ################################################## | 100% 0.84 s
avrdude warning: verification mismatch
        device 0x61 != input 0x54 at addr 0x0000 (error)
avrdude error: verification mismatch

avrdude done.  Thank you.

urclock is about correct.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -p m328p -P COM12 -U eeprom:w:entest.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: reading input file entest.hex for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 128 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
Writing | -------------------------------------------------- | 0% 0.00 s
avrdude error: bootloader might not have paged EEPROM write, try -xeepromrw if it has
avrdude error: bootloader does not implement bytewise write to eeprom
 ***failed;
avrdude error: bootloader does not implement bytewise write to eeprom
 ***failed;
avrdude error: bootloader does not implement bytewise write to eeprom
 ***failed;
...
avrdude error: bootloader does not implement bytewise write to eeprom
 ***failed;
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against entest.hex
Reading | -------------------------------------------------- | 0% 0.00 s
avrdude error: bootloader might not have paged EEPROM read; try -xeepromrw if it has
avrdude error: bootloader might not have EEPROM access; try -xeepromrw if it has
avrdude error: unable to read byte at address 0x0000
avrdude error: read operation not supported for memory eeprom
avrdude error: unable to read all of eeprom memory, rc=-2
avrdude warning: programmer is not responding

avrdude done.  Thank you.

[mcuee]

@stefanrueger

The above is probably a legacy issue.

I am thinking that we may want to put a warning against using -c arduino for optiboot bootloader (at least for the very old 4.4 version) which is supported by -c urclock.

[mcuee]

@MCUdude is still using Optiboot with Mini Core and not yet switching to urboot. But at least it behaves better with newer version of optiboot.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -p m328p -P COM12 -xshowall
avrdude: AVR device initialized and ready to accept instructions
0 0000-00-00 00.00  application 0 store 0 meta 1 boot 512 o8.0 --s-h-r-- vector 0 (RESET) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c arduino -p m328p -P COM12 -U eeprom:w:entest.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: reading input file entest.hex for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 128 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
Writing | -------------------------------------------------- | 0% 10.01 s
avrdude error: programmer is not responding
 ***failed;
 ***failed;
 ***failed;
 ***failed;
...

[stefanrueger]

Arduino will use old optiboot version

-c arduino is a programmer with STK500v1 protocol (except EEPROM addresses are word addresses, mostly); it has no way of knowing which bootloader it serves not its capabilities; it does not even know whether it talks to a bootloader or an arduino isp programmer.

This problem lies squarely with optiboot, which has a number of, ahem, features when compiled w/o EEPROM support:

• Returns Flash instead of EEPROM when programmer asks for EEPROM
• Exits when asked to write EEPROM (sane, but that is the cause of the errors you witness) Ignores EEPROM write commands and pretends they worked well (which is the cause of the issue at hand)
• Has no way of telling the programmer whether the bootloader was compiled with EEPROM support or not
• Does not erase flash when asked for a chip erase nor has a way of telling the programmer it behaves that way

My previous advice still stands: Ditch optiboot. Never look back. Use urboot. Be happy ever after.

put a warning against using -c arduino for optiboot bootloader

Great idea, but what should the warning be and where and how should it be displayed?

I believe that -c urclock serves optiboot bootloaders better in virtually all cases as it reads the bootloader code, hashes it and compares against 8000 550 known compiled optiboot variants, and hence has an inkling of what (some) popular bootloaders are up to. If it wasn't for edge cases (where - owing to other, ahem, peculiarities of optiboot - synchronisation is made difficult and can require extra waiting with -xdelay=...) I would suggest removing the -c arduino code and let -c arduino simply execute -c urclock. That would then enable -c arduino to be kept alive in the terminal -t and have other benefits such as erasing flash through sending 0xff-pages etc.

[stefanrueger]

To cut a long short this issue is caused by faulty optiboot, not by a bug in -c arduino. I recommend using -c urclock with optiboot bootloaders.

[mcuee]

To cut a long short this issue is caused by faulty optiboot, not by a bug in -c arduino. I recommend using -c urclock with optiboot bootloaders.

I agree.

Great idea, but what should the warning be and where and how should it be displayed?

For example, we can put an warning message like the following if we detect optiboot bootloader.

You are using `-c arduino` with optiboot bootloader, avrdude project recommends the use of `-c urclock` instead.

And if the user is using the old Optiboot 4.x version, we can even add more warnig messages. We can progressively roll this warning message to other Optiboot version if @MCUdude and @SpenceKonde do not raise strong objections.

You are using an old version of Optiboot, avrdude project recommends the use of urboot bootloader.

[SpenceKonde]

We certainly shouldn't go showing that on a part that doesn't have urboot available. Like, you know, all the modern AVRs......

I can say that if that warning were being shown by a version of avrdude that I wanted to start putting in my cores, it would not pass muster. I can't go putting it into a release showing that warning if I can't supply the binaries it recommends.

[mcuee]

We certainly shouldn't go showing that on a part that doesn't have urboot available. Like, you know, all the modern AVRs......

You are of course right here about the suggested warnings to recommend urboot.

I can say that if that warning were being shown by a version of avrdude that I wanted to start putting in my cores, it would not pass muster. I can't go putting it into a release showing that warning if I can't supply the binaries it recommends.

Take note -c urclock supports Optiboot along with urboot, including Optiboot_x and Optiboot-DX. It can replace -c arduino in most cases.

And the extra warning proposal against very old Optiboot 4.x will not affect you or @MCUdude. It is only used by Arduino for things like Uno or Nano. The bootloader is like 12 years old. https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/optiboot

But I guess you do not want to see warnings to newer version of Optiboot. I get that.

[mcuee]

Yet the other solution without any changes to the code is just to update the documentation and Wiki to give the users some recommendations with regard to -c arduino and old versions of optiboot.

[mcuee]

@stefanrueger

On a second thought, tThere are too many users who are still using the Arduino Uno/Nano or clones and they will tend to use the old 4.x optiboot bootloader by Arduino. If we add a warning they may not be happy.

Since we label this as invalid, I will close this for now.

I will update the Wiki FAQ page later.

[stefanrueger]

@SpenceKonde -c urclock does a few things for optiboot that -c arduino doesn't, for example, it

• Soft erase a chip by asking to fill flash other than the bootloader with 0xff if the bootloader does not have CE
• Keeps the bootloader alive in the terminal, so you can explore flash and EEPROM with avrdude -c urclock -t
• Knows about some of optiboot's other deficiencies, eg, (misleading) EEPROM r/w
• Protects the bootloader from being overwritten (if it can recognise the size of the b/loader)
• Places a metadata frame in top unused flash, so the sketch can use it (if the bootloader exports sth like write page)

So by and large -c urclock is a better uploader/downloader for optiboot and, crucially, urboot for which it was written. Maybe @mcuee is right and above could be part of the documentation/wiki. It's only edge cases where -c arduino is preferable.