Hi,
I have a photon which was running just fine, using EEPROM locations 0,1,2.
It was unplugged (from power) for a few hours, then when it came back on again, the values reported back (I use Publish/Subscribe) showed that these values were 255 (ie EEPROM entries wiped back to 0xFF).
Could you please suggest WHAT can cause this ???. I would only expect it to happen if the device was sent a FULL firmware update ???.
If so - how can I prevent this from happening automatically please ???.
Update on this issue…
The SAME photon was unplugged, taken to site, plugged in again and is again reporting 255’s. I can (seemingly) write the data, and it gets read (once per minute) back from EEPROM and is now correct).
Using exactly the same code in another photon (here with me) I can correctly SET my data, unplug my photon, count to 10, plug it in again and it correctly reports the saved values (ie NOT wiped :-O).
I was using the eeprom to work out which photon I was posting data to my server .
After a couple of days my program stopped working and found that one of my photons had reset my eeprom data setting it to 255 and crash my program .
After I stopped using the eeprom because you just can’t trust it.
Peter,
Thanks for the feedback
Thats why I posted this - hoping that the dev team will explain what or when the FLASH gets erased ;-)).
I suspect its some form of automatic update, as this particular photon may be running old code - there seems to be no way to find this out remotely - which really is a major limitation in my view…
It must be usable as it works - until something (unknown to me) wipes it again.
I currently have an auto factory default for safety but this is NOT satisfactory for a live product
There’s nothing to our knowledge that would intentionally erase EEPROM, this is some kind of bug, either in the application code or in the eeprom code itself. (We are emulating eeprom in flash memory so it’s a lot more involved than simply writing data to memory.)
When this happens again, please connect the photon to a computer with dfu-util installed and run
dfu-util -d 2b04:d006 -a 0 -s 0x800C000:0x18000 -D eeprom.bin
Hmmm,
Thanks for that - but this is the one which is already on-site some 300 miles away :-((.
I will keep an eye on it and if it continues to play up - we will swap it out.
I might even be able to swap it out before it fails again, but will ‘play’ with the same code in another couple of units to see if I can make another fail.
When you say there is nothing to erase EEPROM - surely reloading the system firmware would have this effect. Then again if this happened, I ‘assume’ that you would also wipe the user app.
When my guy gets back to base I will ask him exactly what he did between the unit working on his desk and it arriving on site :-O.
If/when I can get my hands on it - I will try to do what you ask :-O.
Its currently most likely behind a firewall (as its on a users premises).
NB We are trying to swap it out as we have another one ready, but can’t get it running - the ol’ ‘Breathing Cyan’ issue - I really wish that I understood that, as it seems to happen whenever we start to use a new device. We play with trying to fix it and eventually it starts working - could it be trying to uldate system firmware for a few hours ???. On my local units I use the CLI to flash the 0.4.6 bins (although I JUST foud a post which says add --usb to force LOCAL update ;-O - I ‘thought’ that was what I was doing but apparently not.
Sorry to go ‘off topic’ but its all related - honest ;-))
As for dumping the EEPROM - if its just an app to read content and send it - then my device is effectively doing that already - as its reading my 3 values and publishing them (along with other non-EEPROM data) every minute - its how I can see when it goes bad ;-)).
The 3 values are temperature settings (0-90 degC) so if it suddenly goes to 255 its pretty obvious ;-). My code actually now automatically tests for this when reading and if ANY of the 3 bytes are > 90 (ie like 255!!) it resets them back to 5,5,50. So again I can see these values a minute later.
BTW: These photons are GREAT devices - a little unstable as yet and limited docs but thats what you get for working at the ‘bleeding edge of technology’ ;-)). Keep up the good work
I'm talking about reading the underlying memory that the EEPROM emulation is written to. This is not the same as the values you are reading via the EEPROM library.
- which really is a major limitation in my view…