avrdude has EEPROM bug

[WestfW]

Optiboot is about to be tuned enough to include EEPROM support in a 512byte image.
That's swell, but it turns out that AVRDUDE is somewhat inconsistent WRT reading and writing EEPROM - some parts (ATmega328x, for example) use a word-based address in the STK_LOAD_ADDRESS command, and other parts (notably ATmega8) ) used a byte-based address.
This is documented here: https://savannah.nongnu.org/bugs/?48131

There's probably an avrdude.conf based patch, but the short-term issue is that an ATmega8 with optiboot will not interact properly with AVRDUDE. (It doesn't work with ArduinoISP, either!)

Documented here for the sake of completeness.

[MCUdude]

So, about getting EEPROM support in a 512B image; how can this be done? I just compared "my" repo to yours in terms of compiled size. Both are compiled with avr-gcc 5.4.0.

make atmega328 LED=B5 LED_START_FLASHES=2 UART=0 AVR_FREQ=20000000L BAUD_RATE=500000 BIGBOOT=1

"My optiboot_flash repo":

  avr-size atmega328/20000000L/optiboot_flash_atmega328_UART0_500000_20000000L.elf
   text	   data	    bss	    dec	    hex	filename
    560	      0	      0	    560	    230	atmega328/20000000L/optiboot_flash_atmega328_UART0_500000_20000000L.elf

Official Optiboot repo:

avr-size optiboot_atmega328.elf
   text	   data	    bss	    dec	    hex	filename
    570	    156	      0	    726	    2d6	optiboot_atmega328.elf

If i've understood it correctly the text field is the actual size of the image in bytes. How can this be reduced to 512 or less?

[MCUdude]

ON TOPIC:
I'm no avrdude.conf guru, so maybe you know where the EEPROM related bug for ATmega8 (or other devices with byte-based addresses) is located? My Arduino cores includes a separate copy of avrdude.conf, so a patch should be easy to roll out to affected users if we can figure how we can fix the bug.

[WestfW]

The trick to getting EEPROM support is that you don't get DOSPM support at the same time :-(
(tough decision! Sigh.)

 make atmega328 LED_START_FLASHES=0 NO_APP_SPM=1 SUPPORT_EEPROM=1 LED_START_ON=1
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_495) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BAUD RATE CHECK: Desired: 115200, Real: 117647, UBRRL = 16, Difference=2.1%
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=0      -DSUPPORT_EEPROM -DLED_START_ON=1 -DAPP_NOSPM=1         -c -o optiboot.o optiboot.c
optiboot.c:425:2: warning: #warning BAUD_RATE off by greater than 2% [-Wcpp]
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=0      -DSUPPORT_EEPROM -DLED_START_ON=1 -DAPP_NOSPM=1       -Wl,-Tlinkscript.ld -Wl,--relax -nostartfiles -o optiboot_atmega328.elf optiboot.o 
avr-size optiboot_atmega328.elf
   text    data     bss     dec     hex filename
    510       0       0     510     1fe optiboot_atmega328.elf
avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex optiboot_atmega328.elf optiboot_atmega328.hex

[MCUdude]

I favored so_spm because EEPROM upload is not currently supported in Arduino IDE, and you can do cool and useful things with do_spm.

I created a high-ish level Flash library to make the internal flash memory more accessible to the end-user:
https://github.com/MCUdude/MiniCore/tree/master/avr/libraries/Optiboot_flasher

[WestfW]

See the conclusion at avrdudes/avrdude#967 (comment) and related discussion.
TLDR: a bug was introduced in AVRDUDE back in 2006, and since then other code (like optiboot and Arduino as ISP) has compensated, assuming that the buggy code was intentional.)

[mcuee]

For classic AVRs, this has been fixed in avrdude git main by the following PR.

• Deprecate original STK500 v1 protocol in favour of optiboot and Arduino as ISP avrdudes/avrdude#1046.

It does introduce regression for optiboot_x and optoboot_dx. This will be fixed in the following PR.

• Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino avrdudes/avrdude#1140

[mcuee]

There may still be some issues with four chips (ATmega161 ATmega163 ATmega8515 ATmega8535) and there is a potential fix here.

• Always use paged access for programmers that serve bootloaders avrdudes/avrdude#1141

[mcuee]

From avrdude side, this issue has been fixed in avrdude git main, which will lead to avrdude 7.1 release soon.

[mcuee]

From Optiboot side, #357 is a real issue related to EEPROM.

• Optiboot without EEPROM support returns FLASH on EEPROM read request #357

[mcuee]

urboot (which is indeed inspired by Optiboot) does achieve this goal within 512B.
https://github.com/stefanrueger/urboot

Tight code: most bootloaders fit into

• 256 bytes albeit without EEPROM read/write support
• 384 bytes with EEPROM read/write support
• 512 bytes with dual-boot, EEPROM read/write support and Chip Erase capability

[mirh]

Didn't the guy at #227 (most updated version here I think?) already handle EEPROM+SPM?