About the EN pin and RESET
While using the EN pin on the Feather will completely power down the MCU,
you must be careful of one special case:
If you have externally powered circuits that apply power to GPIOs when EN is LOW,
this flow of current back into the MCU from the GPIO can prevent the nRF52 MCU
from resetting!
To eliminate this problem the AB1805 is configured to also bring nRESET low
when in sleep (EN power down) mode. This assures that the MCU will always reset,
even if there is leakage current.
I remember seeing other topics where people completely make sure a RESET is done on the Particle device by power cycling the board, that is, removing the power completely with a relay or mostfet.
Here’s my question:
Does connecting EN and RESET with the AB1805 as mentioned above protect the board from these extreme cases where people needed to power cycle the board?
Or do we still need to add a means for the watchdog to power cycle a Particle device with a relay/mosfet?
The method used by the AB1805 app note is a good solution that should solve the original problem.
If you only bring EN low, it will remove power to the nRF52, which should cause it to reset. However, if there is external power flowing into the nRF52 from GPIO or pull-ups, then it’s possible that the nRF52 will not reset.
One workaround (not recommended) is to connect EN and reset together. This solves the leakage current non-reset problem, however if you briefly tap the reset button it will briefly remove power because you’ve tied EN and reset together. This could cause the modem to malfunction, as the modem is not normally power cycled when you use the reset button.
The solution used by the AB1805 app note is to bring both EN and reset (nRESET) low at the same time, but not by physically connecting them together. This solves the leakage current problem, but tapping the reset button will not remove power to the modem.
I have implemented the AB1805 watchdog / clock on my carrier boards (v1.5) and have been testing over the past 3 weeks. I have not seen any issues with the device not coming back from “Enable” sleep as was the case occasionally when I was using two separate devices (a watchdog for resets and an RTC for “Enable” sleep) in the previous design (v1.4). This is the schematic for the AB1805:
Note that the AB1805 has access to both the Enable and Reset (!RST) pins via separate connections.
However, I have decided that the benefits of “Enable” sleep are not enough to outweigh the costs - especially with the new Sleep 2.0 API. So, I use “ULTRA_LOW_POWER” sleep and save the toggling of the “Enable” pin as a last resort fix for connectivity issues using the deepPowerDown() command.
This has made the Boron code much simpler and more like the good old days when the Particle device had a real time clock like the Electron.
The good news is that, with a 2000mAH battery, these devices can work for up to a month without charging. I think that the combination of deviceOS LTS, Sleep 2.0, the new power management API and this watchdog timer reference design has finally brought us to a place where we can deploy devices with high reliability and low power consumption - knock on wood!
Hope this is helpful. I will keep you up to date as the number of deployed devices with this new design grows in the coming months.
I could not fully grasp what you meant by the below, would you mind elaborating a little bit more, please?
Does it mean that you use ULTRA_LOW_POWER as opposed to using HIBERNATE for the extra flexibility in waking up the device?
The promise of “Enable” sleep is that it should be the lowest power consumption. However I see a few significant issues:
When in “Enable” sleep, an operator can only bring it back by physically disconnecting all power inputs. This is the most important drawback as it yields a device that us almost indistinguishable from being “dead”.
“Enable” sleep as well as “HIBERNATE” sleep cause the Boron to loose track of Time and there is a requirement to synchronize / standardize calls to time from either the Particle System or the RTC’s API.
“Enable” and “HIBERNATE” cause the device to restart program execution and run Setup() before getting back into the program Loop()
While using more power, ULTRA_LOW_POWER delivers low power consumption and simplifies program flow and makes the device more “wakeable”. For my use case, these benefits make this the best choice.
Same here. Very happy with AB1805 and using ULTRA_LOW_POWER. Per the docs: The difference between HIBERNATE and ULTRA_LOW_POWER is 106 uA vs. 127 uA on the Boron LTE. If I ever want to try and squeeze out every last possible day in the field, I may play with HIBERNATE and use the AB1805 since I have the hardware anyhow but for now, I'm using the ULTRA_LOW_POWER for the same reasons @chipmc mentioned. Waking on HIBERNATE is on the backburner for now.
On a related note, I just bought myself one of these: Current Ranger | LowPowerLab to be able to properly measure low level currents to understand all of this better but so far I'm excited to see what type of battery life I can get from a 6600 mAH battery.
I've tested the deep power down 30 second sequence several times as well as the watchdog functionality. I am really glad the application note, the hardware design and library was created and open sourced by Particle. I have a lot more confidence in my devices in the field now and cleaned up my code and PCB quite a bit! Thank you @rickkas7
