WDT & Bootloader

[Lucas]

My application uses the WDT. In my application, I use a soft reset to enter the bootloader. Because the soft reset does not reset the WDT the program will reset while in the bootloader because of a watchdog timeout.

What is the best way to handle this issue? I see too options. Instead of performing a soft reset to enter the bootloader I could let the WDT in my application expire in order to perform a reset using a WATCHDOG reset. Alternatively I could add the watchdog service into the bootloader. I don't like that the watchdog is running during the initialization routines at the beginning of my application.Why does the softreset not reset the watchdog? Seems a bit odd.

[John]

I ran into this exact problem in my design. I ended up adding a WD service to the bootloader so that it wouldn't cause a bootloader failure when the WDT expired.

According to section 12.1.8 of the nRF51_Series_Reference_manual v3.0, the WDT is a retained register so it will retain its settings through system off and certain resets.

[Lucas]

This seems like an architectural oversight in my opinion. Curious what part of the bootloader did you modify?

[Hung Bui]

Hi Lucas,

I think the philosophy behind is that WDT should work in the way that when it started it can not be turned off. So the WDT can only be reset by itself or by a complete system reset (brown out, pin reset, systemOFF). When entering system OFF, the WDT register is retained but WDT is stopped.

In this case, softreset is lower level that a Watchdog reset and it shouldn't reset the WDT.

You are correct about the 2 solutions. I would personally choose to trigger system reset using WDT to start bootloader. In case you don't plan to do a reset when switching between application and Bootloader then you would need to handle the WDT in the bootloader.

[John]

I added a service of the WDT in the wait_for_events function. I also added one just prior to the soft reset that triggered the entry into the bootloader. As Hung states in his answer allowing the WDT reset to trigger your entry into the bootloader may be a simpler solution. The reason I went with servicing the WDT in the bootloader is that I could not tell exactly what the behavior of the status of the WDT was through a actual WDT event. So I was more comfortable just servicing it and also retaining WDT "protection" during bootloading.

[Allen Foster]

Nordic, please can you fix your completely inflexible WDT config.

The inability to reconfigure the WDT once started is fine in principle but anyone who has ever done any work in the embedded world will tell you how inflexible such a solution is.

Furthermore the argument that the ability to reconfigure the watchdog once started would negate the protection of a watchdog is also nonsense. I could quite easily write a bit of code which trashed either the ARM or NRF51 register space that the WDT could not offer recovery from.