# A Practical Guide to Watchdogs for Embedded Systems | Interrupt **URL:** \ **Category:** Blog\ **Created:** [February 19, 2020, 5:36am UTC](https://community.memfault.com/t/a-practical-guide-to-watchdogs-for-embedded-systems-interrupt/146 "2020-02-19T05:36:12Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![neilh20](https://avatars.discourse-cdn.com/v4/letter/n/c0e974/32.png) [@neilh20](https://community.memfault.com/u/neilh20)\ **Post date:** [March 2, 2021, 6:14pm UTC](https://community.memfault.com/t/a-practical-guide-to-watchdogs-for-embedded-systems-interrupt/146/5 "2021-03-02T18:14:24Z")
Great to get some discussion - I should say that I read this because [https://platformio.org/](https://platformio.org/) featured it in their opening page. I was thinking since the processor is going to be reset - to log the details to the uSD before reset… Depending on the system, logging something after reset is also a good idea but possibly much more limited. Another way could be to have some private ram that isn’t initialized, and it that has a valid string (checksumed off course) then to log that on startup. The question is what details are available. In the past with larger systrem have written some for of stack dump, but it can be a fair amount of work to decode the stack. Another way might be to have each call to the watchdog given a unique number, and then log that number. --- _[View the full topic](https://community.memfault.com/t/a-practical-guide-to-watchdogs-for-embedded-systems-interrupt/146)._