Watchdog reset during bootloader dfu

[OmidAthari]

Hello,

I am working on using the open_bootloader with our application and running into a problem.

We are using the GP_REG to jump from our application back to the bootloader to perform DFU, Our application uses the watchdog timer upon for monitoring  It appears that if we attempt to jump back to the bootloader for DFU the watchdog continues to run and hard resets the board as soon as the bootloader starts.  I know that is what is causing the reset in the bootloader because if we don't start the watchdog in our application there is no issue performing DFU.

I saw this post https://devzone.nordicsemi.com/f/nordic-q-a/3143/how-to-disable-the-wdt-watchdog-timer and attempted to do the same with no success.

I guess my question are:

1- Is there a way to disable the watchdog in our application before we attempt the DFU?

2- Is there a way to configure the open_bootloader to utilizes the watchdog or do we have to create our own bootloader?

Thanks

Omid

[Einar Thorsrud]

Hi Omid,

1- Is there a way to disable the watchdog in our application before we attempt the DFU?

No. The only way to disable the WDT is by watchdog reset, pin reset or BOR/POR, as you can see from the Reset behavior table. None of those are typically alternatives when entering DFU mode (at least not in the field). Other then that, the WDT cannot be stopped or configuration changed once it has been started.

2- Is there a way to configure the open_bootloader to utilizes the watchdog or do we have to create our own bootloader?

Yes, you can and should modify the bootloader to feed the watchdog regularly if you use an old SDK. If you have a fairly recent SDK ( version >= 15.0.0), the bootloader supports this out of the box. It will automatically feed the WDT in that case. However, you must make sure not to have a too short WDT timeout (reload value), as particularly flash operations take a bit of time. You may also need to adjust NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS in the bootloader's sdk_config.h.

Einar

[OmidAthari]

Hi Einar,

Thanks for the help.  I am using sdk version 16.0.0 and I do see that it has the watchdog hooks and I see the "nrf_bootloader_wdt_feed()" function called.

I ran the bootloader in the SES debugger and I see that when the application jumps over to the bootloader for DFU it actually hits the following code in "nrf_bootloader.c line 483" where I placed a breakpoint

   if (dfu_enter)
    {
        nrf_bootloader_wdt_init(); // break point here
        scheduler_init();
        dfu_enter_flags_clear();

and then continues to the dfu correctly and continues to feed the watchdog and all seems fine.  

HOWEVER if I don't put a breakpoint there, then the bootloader just hangs for the watchdog period (same as running without debugger) and then the board resets.  (This might have nothing to do with anything but putting a breakpoint does make the difference in this case.).  

I tried setting the WD timeout to 5000ms in the application and the I see that the "NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS" is set to 10000ms in the bootloader.  

Can you recommend a setting for the NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS

Thanks for your help

Omid

[Einar Thorsrud]

Hi Omid,

OmidAthari said:

HOWEVER if I don't put a breakpoint there, then the bootloader just hangs for the watchdog period (same as running without debugger) and then the board resets.  (This might have nothing to do with anything but putting a breakpoint does make the difference in this case.).  

Does this mean that if you put a breakpoint (and continue shortly before the WDT times out I assume, unless WDT is configured to pause while debugging), then the WDT does not reset the board? But if not debugging or not setting the breakpoint you get a WDT reset? I am not able to find an explanation for that.

I am also wondering about the "bootloader just hangs for the watchdog period". What state is the bootloader in at this time? What is it doing, where is it "hanging"?

Have you verified that the reset reason is WDT reset, by looking at the RESETREAS register?

OmidAthari said:

Can you recommend a setting for the NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS

This is not relevant as you are using SDK 16 where it is no longer in use (though unfortunately it is still present in sdk_config.h and documentation).

Einar

[OmidAthari]

Hi Einar,

Yes you understood correctly.  I know it seems inexplicable but when I set a breakpoint before the point where the bootloader enters the "loop_forever();" function, and then continue execution in the debugger, then the bootloader works fine and enters the DFU mode and continually feeds the watchdog and all is good.  I put some debug code in the loop_forever() function and I can see the debug message streaming on the terminal without 

In contrast if I don't put a breakpoint at all or if I put a breakpoint inside or after the "loop_forever();" function, then the processor hangs for the WD period and then resets the board.  When I say the bootloader hangs I mean it seems to remain stuck in the "loop_forever()" function. Nothing else even the led_soft_blink is not happening at that point. I can see that the debug message in the loop_forever() gets printed several times before the processor gets stuck and no longer prints the message either.   

I know that the reset reason is the WD because the board remains in that stuck state for exactly the WD period.  I verified this by changing the WD period several times to different values.  Also if I do not start the WD in the application then there is no issue at all and the bootloader behaves perfectly.

I can demonstrate this for you if you have a way to do screen sharing etc. 

I am in Phoenix Arizona (Mountain Standard Time).  If we can setup a web meet of sorts, it would be very helpful.  

Please let me know if that is a possibility.

Omid  

[Einar Thorsrud]

Hi Omid,

OmidAthari said:

When I say the bootloader hangs I mean it seems to remain stuck in the "loop_forever()" function. Nothing else even the led_soft_blink is not happening at that point.

I suspect (though I am not sure) that the issue you are seeing is related to a bug in the bootloader, which does not handle a special case with the WDT and LFCLK. If the WDT is active and a soft reset occurs, the WDT will ensure that the LFCLK is kept active. However, the clock is only distributed to the WDT in this case, and not to other "users" of the LFCLK. So this would also explain why you do not see LED blinking etc. In this case the LFCLKSTAT will indicate that the clock is running (which is correct), and that will cause the bootloader to not start it in this code snippet from timer_init() in <SDK 16>\components\libraries\bootloader\nrf_bootloader_dfu_timers.c:

        if (!nrf_clock_lf_is_running())
        {
            nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);
        }

Triggering the start task would fix this issue, so this should be rewritten as just:

        nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);

Do you still see the same issue after doing this?