AVRDUDE and direct r/w to EEPROM issues

Greetings!
Probably an old issue that has come up prior, but my research hasn't yet yielded a resolution. Here's is a description of what I wish to do, what I have tried, and what I have encountered along the way.

OBJECTIVE: I have a measurement device I've designed using a NANO clone that contains a calibration record. Currently, this record is hard coded in progmem as a const array. What I want to do is move this record out of progmem and into EEPROM. To work with this, I then will have a stand alone application that I can distribute to users in the field so that they may simply plug a USB cable into the device and update their calibration records as desired (update record in EEROM only). I'd see the app likely calling AVRDUDE to port over the user updated record, if possible.

PROBLEMS: Though the r/w to EEPROM seems to work fine from WITHIN a sketch (includes EEPROM.H lib), my attempts at writing directly through AVRDUDE have failed. Using the "-U" parameter, I have tried "-U eeprom:w:blank.hex:i" (where blank.hex is a 1Kbyte "FF" record in Intel hex) and "-U eeprom:r:readback.hex:i" (readback the results of the dump). I get gibberish back when I examine the readback.hex file. Also, a verification error when writing to eeprom. In addition, when I read the eeprom from within a sketch, it looks like the data I wrote WITHIN the sketch is retained, even after subsequently writing al FF's to EEPROM through AVRDUDE. This suggests to me that if anything is getting written through this AVRDUDE command, it is PROGMEM space! I have reloaded a "new" bootloader through the Arduino IDE written via spi. Optiboot? Don't know, though I've read rumblings in the forum about OPTIBOOT's questioned compatibility with eeprom writes. I don't know if this indictment is confirmed. AVRDUDE clearly claims the ability to write EEPROM, but also supports may programmer platforms, so bootloader could be involved.
Does this ring any bells with anyone? Anything else I could try to clarify my problem? Cheers!
..Mark

Optiboot (which is the bootloader in "new" Nanos) does not support "uploading" to EEPROM.

This suggests to me that if anything is getting written through this AVRDUDE command, it is PROGMEM space!

Yep. Exactly. See Attempting to write EEPROM trashes flash · Issue #65 · Optiboot/optiboot · GitHub
In the latest Optiboot (from the github site above), this has been "fixed" by treating attempts to write to EEPROM as an error, but it's unable to fit actual EEPROM writing in the 256 instructions available (at least, not without removing other things.)

Since the Nano doesn't really correctly set the fusebytes for a 256word bootloader anyway, you could load in a "BIGBOOT" version of optiboot (512words), and that should work OK for ATmega328. (see also: avrdude has EEPROM bug · Issue #235 · Optiboot/optiboot · GitHub )

1 Like

Thanks for the speedy and very useful reply!
Since my object code still leaves several KBytes of free room in FLASH space, I have no problem putting on a BIGBOOT! If the shoe fits, wear it!
The next hurdles for me then are getting the bigger bootloader, and successfully loading on to my NANO's.
When I put the bootloader ("new") on my board last (with my UNO based ISP hardware lashup), I did so in the Arduino IDE environment, and it didn't ask me to point to a specific bootloader file. There is only a "Burn Bootloader" tab there, and I just got what they gave me (small OPTIBOOT that didn't play well with EEPROM!). Can I direct this? Is there an alternative?
My skillset is not real high on this stuff as it's still new to me, but if you could make some recommendations or send me in the right direction to pursue resolving these questions on my own, it would be a big help. Your help so far has been great, and I thank you.
Mark

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.