Hey Adam, all my own devices are running 0.7.0…I’m not sure if the firmware version really fixed anything,
I don’t know about E-Series either as I don’t use them. But from what I understand though this issue seems to be prevalent across all Particle hardware.
Rick (Particle Tech Support) gave me the following reply:
I don’t have a suggestion for LiSOCI2 batteries, but preventing complete discharge is the necessary step to prevent the Dim D7 failure.
I use an inexpensive ST-LINK/V2 Mini SWD USB stick, about US$15 from Amazon but available elsewhere as well. That combined with the JTAG programming instructions will allow you to reprogram the device and usually get it working again, but you do not have to do this; we can simply send a replacement device instead.
Thank you I was wondering if 7.0 was a better match.
Thanks for the quick reply
Our devices don’t use a the battery and instead use a large capacitor.
I’m worried if the E-Series doesn’t have this improved, getting it replaced will cost more as its soldered to the board. (Can’t just replace the Electron). Lets see if anyone has thoughts on how this works on the E-Series.
Does anyone from Particle have more specifics on this issue so that it can be designed around? I don’t object to having an ST-LINK on hand (have one) but I would prefer to redesign my board(s) so that the issue is prevented.
Is this induced by the micro trying to start without adequate current supply and that is somehow corrupting the boot loader? Do we have a definition of “low voltage”? One thing I notice about the bq24195 PMIC is that it does not seem to have enough hysteresis and will try to restart once the discharged battery naturally recovers a bit of voltage.
This is my understanding of the problem and not an official Particle response–I do not work for them.
There has been a great deal of effort to try to recreate the conditions under which these failures occur, but as far as I know, there is no known recipe to reproduce these failures. Various “brown-out” conditions have been tried while doing firmware updates etc. without reproducing the failure.
Failure analysis of returned parts indicates that DCT sectors are overwritten, so effort has been made to review every possible time those sectors are unlocked for writing and shield against problems in software when writing them.
I think if there was an easy way to diagnose this or work around it, the Particle team would have found it by now.
Inability to reproduce the problem is what I gather, but it would be nice to have more definition to the voltages / conditions to maintain than “no less than 20%” or other nebulous specifications. I’m also curious if anyone know if this is something unique to the RTOS or if other ARM micros in this family have similar issues that perhaps we could learn from.
Suspicions are that this issue is rooted in some - not yet fully understood - misbehaviour of the STM32F2 chip used on the Particle devices.
According to the datasheet these situations should not occure yet they do.
Some tests indicate that this fault only hits specific devices (hardware) but not others undergoing the same treatment so it might well be a production variance issue.
Hence Particle once asked for devices to be returned to them that are known to exhert the issue in a somewhat reproducable manner.
My personal feeling (based on a lot of years in the industry but no real data) is that this is hardware bug in the STMicro processor. Changing software can change the frequency that the bug occurs but not eliminate it. But this is all just speculation and conjecture.