To the Particle Community,
We are experiencing an issue when it comes to battery power and the hibernate function using a digital i.o to trigger our board to turn on and run the code. When in hibernation mode (sleep) it will check in periodically per our programming but when the battery is low and you give the unit power, the one shot will wake the board up, but it won't run our code. When giving the board power with a low battery plugged in, the boron board will initially turn on (white light) for about a second (one shot working) and then it goes off. If we unplug the battery and supply the board with power, it functions like it should and runs the code. I am not 100% but it feels like there is something with the hibernate function and power level that is affecting the Boron "startup".
If the low battery is charged fully through the device, the one shot will still trigger the board but it won't run our code, even with a fully charged battery. The white light just turns on for a second and then goes off. You have to unplug the battery from the device, give the unit power, and then plug the battery back in and then everything works like normal until the battery gets below a certain voltage again.
Here are some reference videos. You will hear me say multiple times that the one-shot is not working when in fact it is. When power is supplied, it's waking the board up, the board just isn't "starting up" like normal.
https://1drv.ms/v/s!AkNSiZSS7_Ejh55DqbNDaENPhq9fNA?e=8AFJAg
https://1drv.ms/v/s!AkNSiZSS7_Ejh55EQrC2wThAWmxGdw?e=5kibC0
https://1drv.ms/v/s!AkNSiZSS7_Ejh55ApBUpjYfiuZjRoA?e=OrR1Gl
Any ideas on how we can have a successful "wake up" every time, regardless of the battery level? Thank you or your time.
What system mode are you using, and if semi-automatic, when you do attempt connection to the cloud?
My guess is that when the battery is very low, when the device attempts to turn on the modem there is insufficient power, and the device browns out and turns off.
The solution to this would be to make sure there is sufficient battery SoC before attempting to connect to cellular, since it will likely fail if there isn't sufficient power, anyway. The MCU itself uses very little power, so you should be able to go back into hibernate sleep successfully with your normal sleep settings.
1 Like
We are using the hibernate function and we are attempting cloud connection right away.
When the device "browns out," we charge the battery through the device (supplying it with power for many hours). During this charing cycle, the device will not turn on when the battery reaches a good state.
After the battery is fully charged, we then turn the power off for a couple minutes and then supply it with power again to try and trigger the device to "run" but the device will just turn on but "brown out" as if it has no battery power, when in fact it does. We have tried hitting the "reset" button on the board in this state and that still doesn't work. After hitting the reset button on the board with a full battery, you can't get the board to "run" unless you unplug the battery and plug it back in.
With no battery, the device works like it should.
In that case, the most common scenario is that you have leakage current into a GPIO when the MCU is not powered. On nRF52 devices, which are very low power, leakage current into a GPIO when the 3V3 rail is unpowered can cause the MCU to remain partially powered. In this state it's impossible to reset the device without completely removing power to the MCU, including the leaking GPIO.
On the Tracker One, we had to add an analog switch on the exposed GPIO on the M8 connector to prevent this from occurring, as the device is sealed so you can't unplug the battery.
2 Likes
Thank you for your quick response. We will look for any leakage possibly getting into a GPIO.
Our device is a sealed unit as well.
Hi @Chris-RadicalENG,
Per @rickkas7 suggestion this leakage current on any of the GPIO when unpowered is most likely the cause. This can be caused by any component on your base board powered by VIN or Li+ that could leak into a GPIO. Can you provide a schematic that we can review?