Bug Bounty: Electron not booting after battery discharges completely


#142

Have the same symptoms, but I had my battery and USB cable plugged in non-stop. Don’t know if this is somehow related, as it’s possible that the USB power supply failed (power strip unplugged/turned off?) while I was gone.

Going to try to use my ST-Link to reflash the bootloader. Hopefully that will unbrick it.


#143

Two more data points. This time I had two 0.7.0 units in the field powered by a 12V 144AHr SLA, going through a Murata OKI-T/3-W32P-C DC/DC converter (4.5V output).

The battery deeply discharged after several days (resting voltage right now is 8.8V), and when I recovered the two Electrons one had a corrupted key[*] and the other shows the same dim D7. The incoming data shows that the device which stopped transmitting first was the one with the corrupted key, whereas the one with the (hopefully just) corrupted bootloader ran an extra 32 minutes.

The corrupted key was solved by using particle CLI’s key doctor. I haven’t gotten out my J-Link yet to see about reflashing the bootloader, so I don’t know for sure that it will come back to life.

So over a set of about 15 Electrons, I have now seen three corrupted keys and two dim D7 instances. I hadn’t linked the lost keys to the low power event till now, but it seems to me likely that the prior two key corruptions were because I ran the LiPo battery low and not because of some mishandling on my part.

Suggestions? I’m loving Particle and the Electron, but 5 failures which require sending the devices back to me for reflashing/re-keying isn’t something we can live with.

[*] I’m calling it corrupted because the device is unable to get back online until I reset the key certificate. Then everything works normally.


#144

Use the Battery Check code in the library below to prevent running the electron on low batteries.


#145

Very nice code package. I would love to see this level of debugging built into Particle’s main firmware. For most applications I imagine this is very worth the code footprint.

Unfortunately, in this case it won’t work with an upstream DC-DC, unless there were a voltage divider on the battery, but now that’s necessitating a more complex circuit in order to keep the Electron from being corrupted/damaged by a brownout. This is something which the hardware should be able to tolerate gracefully.

I’ll try your package for the dev units on my desk. These sometimes get unplugged from USB but are left plugged into battery, which is what led to the undervoltage scenario.


#146

If you connect a battery to your Electron then when your 5v input cuts out the battery will take over and the Battery Check code will work.


#147

That’s a good idea, but in our case that would mean deploying a LiPo to the field, which isn’t really an option (temp specs, increase in complexity, increase in flammability/explosiveness, air shipping issues, etc…)

I think the fix probably needs to be in firmware, or understanding how the Electron’s power-supply issues can cause errant writes so that this can be definitively avoided. Before deploying a bunch of these units to the field in mission critical applications, it’s important to understand our failure modes.

The STM32 is a pretty robust chip, and in years of using it for drones I can’t recall running into this corruption problem. I figure it’s either a Particle firmware problem (perhaps the bootloader?) or the power-supply has uncovered some hitherto unknown errata.


#148

I know fixes have been worked into the latest firmware to prevent this from happening. Not sure if this update is in the firmware your using or not.

I’ve never experienced this before but know preventing the low voltage input seems to prevent this from happening.