Does the example code work with Photons now or do we have to wait for a future Firmware release to take advantage of the Hardware watchdog?
@gusgonnet, sleeping is an issue with watchdogs and there are no simple answers. It all depends on the application.
@RWB, the PR is an unmerged feature so the example will not work.
2 Likes
The article talks about potential shortcomings of internal HW WDGs in general - they may or may not apply to specific silicons.
While itās quite possible that there are silicon bugs in any ĀµC the STM32F2 IWDG is quite deeply hard wired and not actually susceptible to some/many of the risks mentioned.
On the other hand, some of the potential issues risen in that article are not limited to internal WDGs. If you have a pin tickle your external WDG and the controller happens to get into a state where it just keeps on flipping that pin you are just as vulnerable to that with an external WDG.
Also the point about resetting external components in case of a WDG reset isnāt limited to internal ones. If you design a PCB you need to make sure to also reset these in case of a extWDG reset.
But being aware of the risk while designing firmware & PCB is key to being able to consciously make practical decisions to minimise risks - no matter which kind of WDG you are going to use.
2 Likes
Agree. No matter if external or internal watchdog is chosen, reset of peripherals needs to be considered when designing the system. Not a weakness of either choice.
Internal watchdogs that directly HW reset the uC like the reset line was pulled are extremely reliable. Have AVR based products in numbers out in the field for years, none ever needed a reset.
3 Likes
Thank you for the link. It sounds like a major challenge to do. On the other hand, without a built in watchdog, it can be a bit of a āhand grenadeā for new business, that do not have the experience to stay away, or add an external watchdog to start with.
A [15] minute external watchdog to allow for remote sw update to finish etc., work with a limited scope of use cases ex. utility type of use cases where it is ok to miss a hourly reading from time to time.
An end user pushing buttons is not going to sit around and wait for even 5 minutes. It can take less time to return the product.
These modules have so much more potential. Perhaps the separate release scheme for the Boron, Argon and Xenon family is an opportunity to finally try out the watchdog code?
1 Like
@chipmc you state "But, if a āsoft resetā does not solve the issue. My carrier board includes a circuit that I can use to power-cycle the Particle. By pulling one pin HIGH, it turns off both the LiPo and Vin to the Electron causing a āhard resetā
With the length of the threads and the various iterations of your board I am not 100% clear which pin in your circuit you set HIGH and how this cycles the power for both LiPo and Vin.
Could you point me to the ādefinitiveā circuit and description?
Many thanks, Patrick
Sure, Please see the schematic for the power circuit. The intent of this circuit is to all for push-on / push-off control of power for the board and to allow the Particel to do a āhard resetā by bringing the D4 pin high. This will shut off power for about 100mSec until the D4 pin falls and power is restored.
Hope this helps,
Chip
1 Like
Thank you very much, very helpful, Patrick
(Note on schematic refers to D5 not D4?)