Firmware Reset failing with MCUboot and WDT

[hugzy123]

Hi all,

We have an application which uses both MCUboot and a watchdog timer. This combination seems to be causing issues anytime we attempt a soft reset using sys_reboot or NVIC reset directly.

Our system;

• Custom board using nRF5340
• ncs v2.2.0

When we attempt a soft reset the following happens;

1. Device powers down and enters bg_thread_main() in "ncs\v2.2.0\zephyr\kernel\init.c", it doesn't enter our application main()
2. Device enters MCUboot
3. After sometime the watchdog resets, the device enters MCUboot again
4. Finally the device enters bg_thread_main() again, this time our application main() runs successfully

All this is monitored using UART log (shown below).

This issue looks similar to another devzone post, however, we've tried the suggestion of adding CONFIG_BOOT_WATCHDOG_FEED to our mcuboot.conf but we still get the same sequence of events.

From the RESET table, software resets don't reset the WDT which explains why we get 2 resets but it doesn't explain why we don't enter our application main loop in 1. We've tried forcing a WDT timer reset instead of a soft reset and this does fix the issue - we only get one reset and it enters our application main loop successfully. 

One solution is if we tie a gpio directly to the RESET pin and use this gpio for resets from within the application. This isn't ideal as it requires hardware changes and limits ours design.

Does anyone have any other suggestions we can try?

[Vidar Berg]

Hello,

The CONFIG_BOOT_WATCHDOG_FEED symbol should be selected by default when the build target is a nRF device. You can confirm this by if the symbol is set in the generated configuration file (build/mcuboot/zephyr/.conf). Either way, I would suggest that you try to make the WD timeout longer (e.g., 30 seconds), if you have not done so already. Then debug the device to see where it hangs when the program isn't reaching main().

Thanks,

Vidar

[hugzy123]

Hi Vidar,

Thanks for your reply.

You're right that the "CONFIG_BOOT_WATCHDOG_FEED" option is included by default in the mcuboot configuration.

From what I can tell, it seems the application is hanging on the main() function inside bg_thread_main(). All the functions called before main() appear to be exiting without any issues.

[Vidar Berg]

Hi,

hugzy123 said:

From what I can tell, it seems the application is hanging on the main() function inside bg_thread_main(). All the functions called before main() appear to be exiting without any issues.

I would have expected the "boot banner" to be printed before the WD reset if the system initialization in bg_thread_main() completed succesfully. 

https://github.com/nrfconnect/sdk-zephyr/blob/c0689b16ff127d1b71a4cc20310d476e1807e26e/kernel/init.c#L297 

Could you place a breakpoint at the call to z_sys_init_run_level(INIT_LEVEL_POST_KERNEL); and another at the call to z_sys_init_run_level(INIT_LEVEL_APPLICATION); to check if both are reached?

[hugzy123]

Vidar Berg said:

I would have expected the "boot banner" to be printed before the WD reset if the system initialization in bg_thread_main() completed succesfully. 

There is a boot banner being printed, its actually printed three times; once just after the application reset, a second after the first bootloader sequence has finished and a third after the WDT reset and the second bootloader sequence.

Vidar Berg said:

Could you place a breakpoint at the call to z_sys_init_run_level(INIT_LEVEL_POST_KERNEL); and another at the call to z_sys_init_run_level(INIT_LEVEL_APPLICATION); to check if both are reached?

I'm using UART so I can't use breakpoints, however, I have added multiple log messages and observed the application reaches just before main(); in the function bg_thread_main on the first failed reset attempt (before the WDT reset). 

 

[Vidar Berg]

The boot banner is printed during system initialization in bg_thread_main(), so normally it should appear once during the startup of mcuboot and then a second time when the application boots up.

Is it possible to attach a debugger to your custom board? If not, do you think it would be possible to reproduce this on a DK so I can try to debug it here?

[hugzy123]

Hi Vidar,

Apologies for the delayed response; I’ve been tied up with other projects. I’ve now returned to this and managed to reproduce the issue on the nRF53 DK. I’ve attached a .zip file containing the source code, board files, and overlays.

The firmware is designed to initialise and activate LED1 on the DK, stay active for 2 seconds, then reboot. This works as expected for the first ~4 reboots*, but after that, the device fails to reboot correctly. It hangs for around 30 seconds (until the WDT window elapses), at which point the watchdog timer kicks in and the device reboots properly. Strangely, this doesn’t happen when the RTT viewer is connected. The issue occurs regardless of whether I use sys_reboot or NVIC_SystemReset to trigger the reboot. The firmware is built using nRF SDK 2.2.0.

*The issue tends to occur between the 3rd and 5th reboot.

To compile and run the firmware:

1. Set nRF toolchain and SDK to NCS v2.2.0
2. Select "demo_boards_cpuapp_ns" as the board type
3. Include the overlay-rtt.conf Kconfig fragment
4. Add external_flash.overlay and power_enhance.overlay
5. Flash the firmware onto the DK
6. Don't connect to RTT! Instead, connect via serial interface to view logs through UART

Below is a screenshot of my build configuration from the nRF VS Code extension.

When the issue arises (typically after 3-5 reboots), the logs will freeze on the following output for about 30 seconds.

After the WDT has elapsed the device will reset and boot.

demo_wdt_issue.zip

Let me know if you need anything more from me.

[Vidar Berg]

Thank you for this example. I'm able to reproduce the same here now, and it looks like the program hangs in the SPU_IRQHandler when the WD times out.

I will continue to debug this to try find out what is triggering the SPU IRQ. 

hugzy123 said:

I also tried connecting the RESET pin directly to a GPIO to trigger a pin reset instead of a software reset. However, when I attempted this, our custom board freezes after setting the GPIO low, I think its because the RESET pin remains low.

This should work, but it is important that the GPIO is never becomes configured as an output low during boot. Is this GPIO configured in the code your prodived?