No, unfortunately. My tests we related to the EEPROM emulation in flash, not full flash erase. I do not know the root cause of the particular issue you describe.
Can you share details of the EEPROM emulation flash erasure? My code is using EEPROM emulation. I’ve only seen the full flash erasure issue once, and that was shortly after I added EEPROM emulation to my code.
The old EEPROM code unlocked flash and wrote a status at every boot. In some conditions like dying battery the write would fail. The behavior of the code at next boot was to erase the whole EEPROM. It was challenging to reproduce and I don’t understand the details of the failure. The new EEPROM code doesn’t write every boot and verifies writes.
Does this help?
Is the new eeprom code (that doesn’t write at every startup) all ready released in one of the latest firmwares, if so in what version?
Yes, it was released in firmware 0.4.9 in January 2016 (1 year ago).
Does that mean that this was leading to people having the problems that their Electron did not boot up after a complete discharge? So then it would mean that this “Bug” is fixed, right?
BTW this is not unlikely - we had a few sensors which use 5V but also operate normal (at least once) when using 3,3V. But after a second boot up the sensors firmware is destroyed by the fact that the supply voltage was to low and certain strange things did happen on the device - We have overlooked the wrong power supply because even with 3,3V it’s working as expected - at least once
So, what are the symptoms of this? I have two electrons that I’m fairly sure have completely discharged and now no longer boot. When a known-good battery is plugged in, the D7 LED is dimly lit and no other system activity occurs. Plugging the device into a computer does not produce the expected “USB Device Inserted” sound.
I don’t think anybody knows exactly what is happening to cause the firmware to be overwritten when the battery goes empty but it can be eliminated via code that prevents the Electron from running when the battery SOC drops to a predetermined level.
Sometimes the Electrons are not affected by this and some are so it’s weird.
I’ve never killed an Electron this way luckily but others have.
Just my 2 cents after following this for some time now.
This is happening reliably for me. My devices are solar powered. The solar panel is oversized so that it charges even on cloudy days, and when I give these things to people who install them, they often sit on a desk for several days or over a weekend. And they never come back online.
I dug out my ST-LINK2 and we’ll see if I can fix this.
Are you using any code put the Electron info deep sleep when the SOC hits something like 20%?
Not yet. I’m still resurrecting the device. Trying to, anyway.
That code is the best way to prevent this from happening based on my experience.
Yeah, I know, you’ve mentioned it like 400 times
I know, it would have saved you from buying a new Electron
I already had several. I didn’t buy any to replace this one, thankfully. I had bought one as part of the kickstarter campaign, and the antenna connector fell off the board after a single use, which is clearly not intentional, though some people tried to tell me that I should have expected it.
I bought 4 asset tracker kits this year for a thing at work, and when the first one had these symptoms I chalked it up to hardware failure. then today it happened to a second, and then I knew it was a software fault. So I started looking for a fix, and found it. Though I don’t like that this is a mysterious bug.
I’ve got this board blinking green and cyan now, and there’s a problem that I think is related to my product configuration. I’ll figure it out or I’ll start a new topic about that specific issue.
Hey @naikrovek - would be great of you share the code running on your devices!
Just because I am having quite a few solar powered Electrons in the field and quite often they are running out of battery but do come back every time …
I wasn’t able to reproduce the issue on my side - even with quite a few attempts … so it definitely has something to do with the code running on those devices!
What code are you running that’s working for you?
No, not using EEPROM.
The code is here: https://gist.github.com/naikrovek/330fb772c3c00fb34ef60bea73d120ee
Aaargh, this just happened again. This is a 100% repeatability problem, in my case. It rained here over the weekend, and I guess the solar panel isn’t mounted in an ideal position, so it wasn’t able to charge the battery sufficiently. Battery drains fully = dead Electron.
The code I am running is linked in the previous post.
Fortunately the PoC I’m running is nearly over so I won’t have to fight this much longer. I would be pulling my hair out if I had to deal with this long-term. Actually I’d probably mandate that 100W solar panels were used (rather than 10W) so there would be no possibility of battery discharge, even on the cloudiest of cloudy days.
I do hope for future users of this platform that the problem is resolved. If there’s anything I can do to help Particle work out what’s going on here, please let me know.