Go Down

Topic: bootloader doesn't erase EEPROM (Read 936 times) previous topic - next topic

bkerin


I'm guess this is a won't change on both ends, but it's inconsistent that avrdude doesn't end up clearing the EEPROM like other programmers do.  avrdude blames this on the arduino bootloader, and avrdude does indeed appear to request a chip erase type operation.  Of course the bootloader shouldn't nuke itself but to be like the chip erase that you get from other programmers it should check EESAVE and clear the EEPROM unless it's programmed.

Some details here:

https://savannah.nongnu.org/bugs/?52963

DrAzzy

This was a design decision - the code required to support interacting with the EEPROM pushed optiboot past the 512b mark (next size up is 1024b). You can build optiboot with EEPROM support, at the expense of needing to set the bootloader section to 1024b.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

westfw

(Even with EEPROM support turned on, the bootloader won't erase it when it gets an "erase chip" command.  Pages in memory are erased immediately before they are programmed, and the "erase chip" command is ignored.)

hammy

#3
Dec 09, 2019, 03:40 pm Last Edit: Dec 09, 2019, 03:44 pm by hammy
If you wanted there are fuses that can be set to erase eeprom on start up, or just clear it out in a sketch .


DrAzzy

#4
Dec 09, 2019, 06:34 pm Last Edit: Dec 09, 2019, 06:36 pm by DrAzzy
If you wanted there are fuses that can be set to erase eeprom on start up, or just clear it out in a sketch .


The fuses only apply when a chip erase command is used within the context of ISP programming, as the OP noted. He is using the bootloader to program it, which as myself and westfw have noted can't do this for not one, but two reasons:
* The stock uno bootloader sacrificed EEPROM write capability in order to fit in 512b. Though it can be built with that support at the cost of needing 1024b boot sector.
* Even if that is done, however, chip erase on bootloader doesn't do anything - flash/eeprom is only erased when new data is received to write to that location.

This is in large part a natural consequence of how erasing the flash is done on the AVRs. As always for this sort of technology, the flash or eeprom must be erased prior to writing new data to it (freshly erased, every bit is a one, and it can only be "written" to a 0, or the page erased to turn all bits within that page back into 1's). During ISP programming, the only way that any flash can be erased is by executing a chip erase cycle, which erases the flash, the EEPROM unless EESAVE fuse is set, as well as clearing the lockbits (the fact that this is the only erase option available is part of their code protection system - if lockbits are set to prevent read, you can't read out the flash contents... except by executing a chip erase to clear the lockbits, thus erasing the code you're trying to steal). During programming with a bootloader, however, erases can be done only on a page-by-page basis.

Indeed, a "chip erase" cycle doesn't make sense in the context of a bootloader, as it is impossible for a bootloader to mimic the behavior of a chip erase command in total - "chip erase" erases ALL the flash (a bootloader cannot erase itself) and clears the lockbits (a bootloader cannot change fuses or lockbits).  It wouldn't exist as a command except that the bootloader implements the stk500 protocol which was designed for controlling an ISP programmer.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

bkerin

Indeed, a "chip erase" cycle doesn't make sense in the context of a bootloader, as it is impossible for a bootloader to mimic the behavior of a chip erase command in total - "chip erase" erases ALL the flash (a bootloader cannot erase itself) and clears the lockbits (a bootloader cannot change fuses or lockbits).  It wouldn't exist as a command except that the bootloader implements the stk500 protocol which was designed for controlling an ISP programmer.
Well interestingly I just found that for the arduino mega 2560 one has to use -c "wiring" instead of -c "arduino", and programming then fails with an error that chip erase hasn't worked.  If you give the -D option to avrdude then it works.  I like this way, because it makes it clear that these programmers don't chip erase

westfw

Quote
for the arduino mega 2560 one has to use -c "wiring" instead of -c "arduino"
Yes; the mega and uno normally have different bootloaders (the Mega bootloader implements version 2 of the "stk500 protocol", while Optiboot implements "version 1"
(I believe that the mega bootloader also supports EEPROM reads and writes.  (it certainly should, being about 8x bigger!))

Go Up