WDT & Bootloader

RE: WDT & Bootloader

Hung Bui — Fri, 11 Mar 2016 08:25:40 GMT

Hi Shiva,

One solution is to erase the BANK_VALID_APP flag in p_bootloader_settings->bank_0 in flash (have a look at bootloader_app_is_valid() function). By doing that and then do a WDT reset (or any reset), you will force the Bootloader to enter OTA mode. But the draw back is that there is no way to fallback to the original application.

RE: WDT & Bootloader

Shiva — Thu, 10 Mar 2016 18:18:06 GMT

Thanks for the clarification, Hung. I figured as much after posting the comment. DFU sample code that Nordic provides by default uses GPREGRET to trigger the switch to OTA. If you could additionally clarify that we need to make use of application flash area to trigger the OTA switch if we want enter OTA mode via WDT reset, that would be great.

What makes this complicated is that sf we already have a bootloader out there that uses GPREGRET to switch to OTA and doesn't already feed the WDT, then we can't release an application that starts using WDT now. Do you know if there is a way to achieve this?

RE: WDT & Bootloader

Hung Bui — Thu, 10 Mar 2016 08:36:50 GMT

@Shiva: As shown in the table at section 12.1.19 nRF51 Reference Manual, Watchdog reset will reset the retained register GPREGRET. That's why the bootloader didn't enter bootloader mode after WDT reset.

RE: WDT & Bootloader

Shiva — Wed, 09 Mar 2016 20:47:38 GMT

Hi Hung,

Is there any reason why WDT reset wouldn't start the bootloader? In our setup, doing a soft reset causes the bootloader to start; but a WDT reset doesn't. GPREGRET register which is used to trigger the DFU mode is updated in both these resets. Have you tried entering the bootloader mode via WDT reset? Thanks.

RE: WDT & Bootloader

Hung Bui — Mon, 18 Jan 2016 13:01:39 GMT

@Allen: Please create a new case when you have question/request. Piggybacking your question to other's case is not a good idea.

RE: WDT & Bootloader

Allen Foster — Sat, 09 Jan 2016 21:22:58 GMT

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.

RE: WDT & Bootloader

John — Mon, 09 Mar 2015 15:04:37 GMT

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.

RE: WDT & Bootloader

Hung Bui — Mon, 09 Mar 2015 13:40:45 GMT

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.

RE: WDT & Bootloader

Lucas — Fri, 06 Mar 2015 23:57:02 GMT

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

RE: WDT & Bootloader

John — Fri, 06 Mar 2015 14:56:47 GMT

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.