EEPROM Data corrupt after reboot (no power loss)

Troubleshooting
#1

I’m having an unusual issue recalling data from EEPROM after rebooting the device. I am "put"ing data , and even verifying it with a “get” immediately after. It only (seem to) happen in this specific memory address location of 72.

long SomeVar = 55662;
long SomeVar2;
EEPROM.put(72, someVar);
EEPROM.get(72, someVar2);
Serial.println("Before: " + String(SomeVar ) + ", After: " + String(someVar2));

The variable is correctly written to the EEPROM… and while I am performing
other EEPROM.PUT’s in my code after this in other memory locations, evertime I am, I have debugged it to Serial output and verified the stored value is still correct (“55662” in this example).

However, if I call System.reset(); to reboot the device, press the Reset button, or if I send a firmware update to the device, or if I power cycle it, in all scenarios, when I call EEPROM.get(72, someVar2); again, the value always comes back with a whacky value, such as maybe something like 11223. Its always comes back something different, only after a reboot.

Things I know:

  1. It always does it (System.reset(), firmware update, reset, or a power cycle)
  2. I’m using Device OS 1.0.1
  3. I don’t seem to have any issues with the fetching of data from the EEROM in other memory address locations before/after this location of 72. For example I am storing long data type variables in address 68 and 76 and they seem to be recalled without any issues.

I found in a old forum post that I can data dump the eeprom to a file using the following command line:
dfu-util -d 2b04:d006 -a 0 -s 0x800C000:0x18000 -D eeprom.bin

However this forum post was from 2015, and when I try it now, I get an error:
DfuSe interface name: "Internal Flash "
Downloading to address = 0x0800c000, size = 0
Last page at 0x0800bfff is not writeable

I presume the error is because the EEPROM flash address location has changed since DeviceOS 1.0.1? Does anyone know a updated command line to data dump the EEPROM?

In any case… I’m not sure what else to try here to debug this issue.

Any ideas?

#2

Does this also happen with a test code that only uses this memory location and does nothing else?

A link to the respective forum post would be good.

1 Like
#3

That is my next step in debugging this issue, is to get rid of all of the other EEPROM.Put()'s and start working backwards. I may go as far as starting a new project that does nothing but read/write to the EEPROM to try to reproduce the issue in a separate project.

Here is the link to the article that had info on how to dump the EEPROM to a file: https://community.particle.io/t/eeprom-values-wiped/16568/4

#4

I think I figured out the issue. Their was a variable I was putting in memory address location 68 that used to be 4 bytes (long), but I have since changed the variable two a struct that contains two long values, so the new length is 8 bytes.

Also, in my debugging, I was “verifying” the stored value in the memory address location 72 in a loop that was storing values in the address location 68 but was out of order.

I was able to figure this issue out by debugging to the size of each of the variables I am storing to the EERPROM by outputting to Serial output using the sizeof() function. That’s when I discovered the size of the variable in in address location 68 was in fact 8 bytes long.

I’m still curious if someone tell me the proper dfu-util command for DeviceOS 1.0.1 to output the EEPROM to a binary file

2 Likes
#5

Try -U instead of -D
For me the naming of the switches also seems twisted but this is how dfu-util -? describes the switches

dfu-util 0.8
 -U --upload <file>            Read firmware from device into <file>
 -D --download <file>          Write firmware from <file> into device

I’d think you want to “download” from the devices and upload to the device, but dfu-util (at least 0.8) seems to see this differently :wink:

#6

Thank you. I will give that a try.