DFU and Watchdog timer (WDT) reset

RE: DFU and Watchdog timer (WDT) reset

456789 — Thu, 02 Dec 2021 06:56:22 GMT

Sdk17.0.1 also has this problem, do you have a solution?

Best regards

RE: DFU and Watchdog timer (WDT) reset

rct42 — Wed, 13 Dec 2017 19:56:39 GMT

@Neo, this is another way to do it. We initially thought about this but decided against it as it removes the ability for the WDT to get it out of an error state while in the DFU mode. However, when it comes to the BL+SD update, we don't have a choice - if something goes wrong here it will brick the device. The solution I described minimizes the risks for us and has been working well in production (100 or so high value units).

RE: DFU and Watchdog timer (WDT) reset

Neo — Wed, 13 Dec 2017 16:46:07 GMT

If your APP has such a little timeout why don't you just stop feeding WDT in APP until it resets the board instead of doing soft reset? After WDT timeout happens it disables WDT and you can reconfigure it in bootloader with longer timeout if needed. Or just keep it disabled.

RE: DFU and Watchdog timer (WDT) reset

rct42 — Thu, 26 Oct 2017 22:01:25 GMT

I have also had troubles with the WDT and the DFU process. I’m currently migrating from SDK13 to SDK14, which involves updating the BL+SD then the APP (all via UART without HWFC at 9600 baud).

Although I had already applied WDT reset modification to the wait_for_event() in the SDK13 bootloader programmed on the production units, I found that the WDT would still interfere with the bootloader during the BL+SD DFU. After the BL+SD image was transferred, the bootloader performs a soft reset and then runs nrf_dfu_mbr_copy_sd() (which ultimately runs sd_mbr_command()). This function appears to take between 600ms – 800ms (and possibly longer sometimes…). During this time, no app timer callbacks will be invoked as the app timer is actually polled / not interrupt driven. Thus the WDT reset will not be called in the wait_for_event().

The solution to my problem involved increasing the WDT period to 4 seconds. I also do a further step of updating to a temporary SDK13 app which has the WDT disabled before doing the SDK14 update (BL+SD and then SDK14 app). Let me repeat:

Upload a temporary app which does not enable the WDT
Increase WDT in production app to 4 seconds.

Note 1: I highly recommend that you do something similar when upgrading. If the WDT resets the bootloader during the nrf_dfu_mbr_copy_sd() function this will brick your device. The bootloader becomes corrupt and the only way to recover from this is to reflash the bootloader via a programmer. I’ve had to throw away some production units as they were sealed and could only be updated via the DFU.

Note 2: I also initially added an app timer which calls a function to reset the WDT in the bootloader. However, it should stop resetting the WDT after 10 minutes or so (or 2x how long you expecting to stay in the bootloader). Otherwise, you’ll get into the situation where your WDT is not able to bring your bootloader out of an actual program corruption. When I found out that the app timer callbacks were actually being polled, I then changed the WDT callback to be invoked via an interrupt generated by TIMER1 with an interrupt priority of APP_IRQ_PRIORITY_HIGH. This still did not fix the problem and the WDT was still bricking the units during the BL+SD DFU! I suspect that sd_mbr_command() is an “atomic function” where global interrupts are disabled while it is in there for 600ms – 800ms. Although I’ve left this in my bootloader, I have not had any further issues after implementing my aforementioned solution.

RE: DFU and Watchdog timer (WDT) reset

bjorn-spockeli — Wed, 25 Oct 2017 11:49:04 GMT

Hi Farhang,

the use of the WDT is application specific and it is difficult to create a generic solution that fits all, e.g. the number of RR registers enabled and the WDT configuration ( Sleep or Halt). Hence, we have left it to the application developer to feed WDT in the bootloader.

That said, I agree that we should at a minimum state in the bootloader documentation that if the WDT is enabled by the application, then it must be feed by the bootloader during the DFU process to avoid the device to reset prematurely. I think also we should point out where in the bootloader code it must be feed, e.g. add the following comment in wait_for_event():

/* 
   WDT: If the Watchdog Timer has been enabled by the application, 
        then the it must be feed here 
*/

Your solution looks good and I think that we can suggest it to other users that experience this issue.

Best regards

Bjørn