Watchdog Timer Issues and Pullup on nReset

[TylerS]

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

[Simonr]

Hi Tyler

Seems strange that this pullup would affect the watchdog, but I guess that could be the case... 

The external pull-up is indeed not recommended, as the nRESET is internally pulled up to the SiP internal VDD rail. During sleep, if the external rail is higher (I.E. 3V), the internal regulator is in a state where it doesn't leak the current fed by the external pull-up, causing the internal supply to rise from 2.2V to the external rail voltage. When the nRF91 wakes up, the internal supply will be too high, and might cause issues with calibrations done at startup and causing excess power consumption (that I know of). The recommendation is therefore to not use external pull resistors, keep any controllers etc. in high-Z except when pulling low to reset nRF9160. Reset switches/buttons can use the internal pullup.

Best regards,

Simon

[TylerS]

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

[Simonr]

Hi again Tyler

No, I don't think I've seen/heard of behavior like this before, and I can't find anything either. You're right that the watchdog shouldn't need any "backup" as it generally just works. It could be related to the pull-up, as it will cause the side effects I described + that it might cause undefined behavior like this since we don't characterize how the SiP works in faulty states. 

Are you able to test your application on an nRF91 DK by the way? If you're not able to reproduce it there, I think it's safe to say there's a HW issue in your custom board. If you'd like we can do a HW review of your board before you do your next PCB revision to make sure everything looks good. You can make a new (private) ticket for that purpose.

Best regards,

Simon