However my values don’t appear to be sticking. I used an intermediate variable in these methods as target is exposed via the Spark.variable interface and I wanted to make sure the compiler wasn’t doing something odd to support that.
For what it is worth I see the same behavior if I write a single byte with the target.
Call setTarget remotely
Confirm the target is set in ram by reading it back via REST API
Power off device by killing it’s power supply
Power back on.
Read target via REST API again. Bad data. In the case of a byte read it was always 255.
Can I read from EEPROM in setup?
Has anyone else had this issue?
If that is actually it I’ll laugh at myself. This is why peer programming exists! I think you are probably right. I would have done the byte conversion test in place of that line and probably copied the error. Will update.
I’m not too sure about the actual reason of your problem so far
This very simple sketch works on my Photons (0.4.5 and 0.4.6)
int updateEEPROM(String val)
int i = val.toInt() % 256;
uint8_t b = i;
And now I’m giving @BulldogLowell’s code a go and see if I can get your results too.
Nope, all fine there too!
After power-cycling I get the correct value back (despite a wrong first feedback from EEPROM.get(0, value); due to double (targetTemp) / float (value) mixture), so I guess it’s something with your test environment.
Now I’ve even tested your own code (but removed all the Dallas and OneWire references) and it works just the same - you see me puzzled where your problem lies?
Maybe add this as your final line in your setTargetTemp(String command)
int setTargetTemp(String command)
return targetWrite; // to see what you wrote
Firstly thanks to everyone for spending time on this!
I’ll try returning the value that is written for a sanity check but as I’ve tested reading it back from the EEPROM without removing power first and found the values correctly stored I’m not expecting to see any difference there.
I’m powering the board with a Sony USB charger it can thump out 1.5 amps pretty happily. I watched the board while turning off the power to the charger (as I have been doing thus far) and the board continues to run for approximately 500ms and then loses power (LEDs go off) for maybe 100ms then appears to get power again for about 100ms before settling to off. I wonder if this is causing my issue. I previously discounted this expecting if this were the case it would cause a loss of the application code as well (Application and ‘EEPROM’ are both stored in the same Flash right?). Maybe not?
My next test will be dismantling the housing and trying the previous test but remove the power from the board on the USB side not the AC side.
Just for support I’m jumping in to say that I have seen similar behavior but only intermittently so I have been blaming myself as i work on more important issues in my development. I am saving a few temperature reading <91 degrees so I have been just saving the integer byte. Most of the time it survives a reset /flash etc, but sometimes it comes back as 255. enough so that I wrote code to fail safe if the number is too large. I’m pretty sure I haven’t seen it lose the value through a reset or flash but sometimes a power removal will come back with a 255. i never had consistent data to follow the problem so i didn’t pursue it.
yes this seems to be when my Photon loses its EEPROM value. My colleague did tell me that he always just unplugs the USB, not turning OFF the power source (either laptop or USB power supply). So it seems in our case that its when its unplugged. Ours has been plugged in on a clients site now for some time and so far (fingers crossed its still OK. Then again it probably hasn’t lost power yet.
Hope this feedback is helpful. I have ONLY seen it on the one device (out of 5 units available).
I’ve seen a similar issue.
I have some settings stored here, and when a bad read is detected the settings restore to a default. I’ve had some units that reverted back to default settings which must have been after a bad read.
On a side note. I took a look at memory dumps from this region and the individual bytes are stored on 4 byte boundaries?!
Is this some premium feature that particle plans to charge users for in the future? Quadruple your NVM for a small fee
If anyone sees their data revert of 0xFF then please perform a memory dump and get that to me!
dfu-util -d 2b04:d006 -a 0 -s 0x800C000:0x18000 -U eeprom.bin
The EEPROM memory on the Core/Photon isn’t true eeprom - it’s flash memory. This means that bytes can only be changed from 0 to 1 by erasing the entire 16Kbyte sector. That’s why the data is encoded so that we can make incremental changes without having to erase the sector.
Same here, this issue is new to me, it didn’t seem to happen under 0.4.5, but since updating to 0.4.6, it has happened a few times. Haven’t been able to make a dump as my program overwrites eeprom with 0x00’s on an unexpected read.
I’m running mostly on batteries, and it happens on low power. I think it has also happens on bad wifi connection, but not 100% sure.
I’m also getting SOS#5 errors now, which did not happen before.
I have tried fw 0.4.7, 0.4.6 and 0.4.5, but it doesn’t seem to change anything. @mdma, is it even possible to roll back firmware, or does .6 or .7 trigger updates of the bootloader or other parts that don’t roll back properly?