Watchdog Timer Issues and Pullup on nReset

Hello,

We have been having strange issues with the watchdog on some of our development devices. The issue is that it seems the watchdog will sometimes not properly reset the device in the event of a lockup. We have determined that there is a bad issue that is causing a lockup in our system workqueue thread where the hardware watchdog is kicked. We have seen one device that is in this lockup state and the watchdog is not being kicked but the device is not being reset. We have none of the Zephyr watchdog options set. We are using NCS 1.7.0 with SICA B1-A hardware.

One hardware issue we have found is that our current revision has a 10k pullup resistor to 3V on the nReset pin. I have read that this is actually an issue and can potentially even cause damage to the SOC. Would this be a potential source of this watchdog issue? I also wanted to understand what the ramifications are of putting a pullup on this pin. The strange thing is that it is hard to reproduce the issue and almost every time we try to insert a lockup, the watchdog works properly. 

Thank you,

Tyler

Parents
  • Hi Simon,

    Thank you for the information about the effects of the pullup. We will be sure to remove it in our next PCB revision. As far as the watchdog goes, have you ever seen any issues that could lead to this behavior?

    From the logs of the troublesome device, we confirmed the wdt was initialized correctly and was never canceled / paused. We also confirmed that the application got to a state where the wd was not being kicked yet the SOC was not being reset. The timer is not initialized with any of the available options (i.e. WDT_OPT_PAUSE_IN_SLEEP etc.) The watchdog was also configured with WDT_FLAG_RESET_SOC which normally works just fine. We have implemented a check in software that acts as a sort of backup for this situation but to us, the hardware watchdog shouldn't need any sort of software backup and we would like to fix this issue ideally. I have seen some issues with the task_wdt implementation in Zephyr but don't think that applies to us since we are only using the hardware wdt.

    Thank you,

    Tyler

Reply
  • Hi Simon,

    Thank you for the information about the effects of the pullup. We will be sure to remove it in our next PCB revision. As far as the watchdog goes, have you ever seen any issues that could lead to this behavior?

    From the logs of the troublesome device, we confirmed the wdt was initialized correctly and was never canceled / paused. We also confirmed that the application got to a state where the wd was not being kicked yet the SOC was not being reset. The timer is not initialized with any of the available options (i.e. WDT_OPT_PAUSE_IN_SLEEP etc.) The watchdog was also configured with WDT_FLAG_RESET_SOC which normally works just fine. We have implemented a check in software that acts as a sort of backup for this situation but to us, the hardware watchdog shouldn't need any sort of software backup and we would like to fix this issue ideally. I have seen some issues with the task_wdt implementation in Zephyr but don't think that applies to us since we are only using the hardware wdt.

    Thank you,

    Tyler

Children
No Data
Related