On August 30, 2016 at 10:51:47 AM, marko kiiskila (ma...@runtime.io<mailto:ma...@runtime.io>) wrote:
Hi Mathew, > On Aug 29, 2016, at 5:02 PM, Mathew Calmer > <mcal...@exploramednc7.com><mailto:mcal...@exploramednc7.com%3E> wrote: > > It’s implied but not made explicit that hal_watchdog_init sets up a > re-occuring watchdog, not a one time use one (who wants a one time use > watchdog….). This should be made explicit though. > right. I can change the wording in the comment. That was indeed what I had in mind. > Also, it would be nice if the watchdog module could tell you if a recent > reset was caused by the watchdog. I could imagine this functionality being in > the startup module instead however. That is absolutely necessary. I initially thought we’d have another API call in hal/hal_system.h which would return reboot reason. And that would include HAL watchdog as one possible cause. If we end up having driver interface for watchdogs, then I’d include a call in there which would tell if that watchdog was the cause of the restart. What I’m hoping to do is to have a way of pre-empting the hardware watchdog by having a dedicated timer interrupt (when available), that would fire just before watchdog resets the system. The benefit of this would be that it would be possible to create a coredump of the system state for later analysis. When system is wedged bad enough, this might not run to completion. But in most cases, it would help in debugging spurious (and not so spurious) watchdog events. Mark all your responses seem well designed and thought out. Thanks.
