Watchdog reset during bootloader dfu

RE: Watchdog reset during bootloader dfu

ANewman — Sun, 18 Jul 2021 23:33:41 GMT

Hi Omid and Einar

I wanted to share that I experienced the exact same issue as originally reported by Omid and the fix was as Einar suggested.

When entering DFU mode from the application, using GPREGRET register, DFU mode would successfully enter but the device would reset shortly thereafter.

I was able to determine that the reason for the reset was a watchdog timeout. The application starts the watchdog. Temporarily not starting the watchdog in the application would solve the reset problem after entering DFU. I didn't expect this as the loop_forever() function in the bootloader is supposed to feed the watchdog, and it was clearly not doing so, despite LFCLK running.

By including the suggested line below in the bootloader main.c to trigger the clock task, the bootloader then starts feeding the watchdog, resolving my issue:

        nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);

This applies to SDK 17.0.2 on an nRF52840.

RE: Watchdog reset during bootloader dfu

Einar Thorsrud — Wed, 28 Oct 2020 13:58:57 GMT

Hi,

[quote user="OmidAthari"]Is there a way to package my new bootloader so we can get the correct or expected signature?[/quote]

The bootloader that the nRF52840 dongle ships with requires bootloader updates to be signed. (This is to prevent customers from accidentally bricking it). We do not distribute that key, so f you need to replace the bootloader on the dongle you need to do that via SWD the first time, programming it with a bootloader with your own public key. Please note that there are some pitfalls using SWD and the dongle, described in the last part of the nRF52840 dongle programming tutorial.

RE: Watchdog reset during bootloader dfu

OmidAthari — Tue, 27 Oct 2020 19:30:27 GMT

Hi Einar

Another question related to loading the bootloader.

I have a nrf52840 Dongle and I need to update its bootloader with the one I just built. I generated a boot loader package successfully using nrfutil as following command:

nrfutil pkg generate --debug-mode --hw-version 52 --bootloader ./open_bootloader_usb_mbr_pca10059_debug.hex --sd-id 0xCA bootloader.zip

When I attempt to load this new bootloader I get an error: here is the complete output:

~/gitlabRepo/ble-fw-sd/dongle ᐅ nrfutil dfu usb-serial -p /dev/ttyACM1 -pkg ./bootloader.zip

Traceback (most recent call last):
File "/home/nikola/.local/bin/nrfutil", line 33, in <module>
sys.exit(load_entry_point('nrfutil==6.1.0', 'console_scripts', 'nrfutil')())
File "/usr/lib/python3.8/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3.8/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3.8/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/__main__.py", line 1014, in usb_serial
do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, False,
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/__main__.py", line 970, in do_serial
dfu.dfu_send_images()
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu.py", line 123, in dfu_send_images
self._dfu_send_image(self.manifest.bootloader)
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu.py", line 95, in _dfu_send_image
self.dfu_transport.send_init_packet(data)
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 256, in send_init_packet
self.__execute()
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 421, in __execute
self.__get_response(DfuTransportSerial.OP_CODE['Execute'])
File "/home/nikola/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 502, in __get_response
raise NordicSemiException('Extended Error 0x{:02X}: {}'.format(resp[3], data))
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x08: The init packet does not contain a signature, but this bootloader requires all updates to have one.

Obviously the current bootloader requires that the new bootloader have a signature.

Is there a way to package my new bootloader so we can get the correct or expected signature?

Thanks

RE: Watchdog reset during bootloader dfu

OmidAthari — Tue, 20 Oct 2020 16:38:43 GMT

That was it.

Thanks for all your help'

Omid

RE: Watchdog reset during bootloader dfu

Einar Thorsrud — Tue, 20 Oct 2020 07:44:54 GMT

Hi Omid,

[quote user="OmidAthari"]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.[/quote]

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?

RE: Watchdog reset during bootloader dfu

OmidAthari — Mon, 19 Oct 2020 23:54:43 GMT

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

RE: Watchdog reset during bootloader dfu

Einar Thorsrud — Mon, 19 Oct 2020 12:13:36 GMT

Hi Omid,

[quote user="OmidAthari"]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.). [/quote]

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?

[quote user="OmidAthari"]Can you recommend a setting for the NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS[/quote]

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

RE: Watchdog reset during bootloader dfu

OmidAthari — Fri, 16 Oct 2020 20:59:39 GMT

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

RE: Watchdog reset during bootloader dfu

Einar Thorsrud — Fri, 16 Oct 2020 07:41:51 GMT

Hi Omid,

[quote user=""]1- Is there a way to disable the watchdog in our application before we attempt the DFU?[/quote]

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.

[quote user=""]2- Is there a way to configure the open_bootloader to utilizes the watchdog or do we have to create our own bootloader?[/quote]

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