Watchdog Timer does not reset the device

[roshangeoroy]

Dear Support team,

Project information :  

Hardware : nRF5340 Custom Board

SDK : nRF Connect SDK v2.2.0

I have integrated watchdog timer to my project. I've used these functions to initialize and setup the watchdog timer : 

wdt_install_timeout(wdt, &wdt_config);
wdt_setup(wdt, WDT_OPT_PAUSE_HALTED_BY_DBG);

And I use

wdt_feed(wdt, wdt_channel_id);

 for feeding the watchdog every 30 seconds from one thread. If I do not feed, ideally the watchdog timer should elapse and reset the device, but the device hangs instead of rebooting. The device needs a PoR to be booted up again. 

I observe this issue only when multiple threads are running. The other threads that are running handle BLE initialization and Advertisement. 

Please with your expertise help me solve this issue asap. 

Also, do note that I had applied a workaround for nRF5340 Anomaly 161 in nrf_reset.h 

Thanks,

Rosh

[roshangeoroy]

Dear team,

I just found out the issue behind the system hang during reset. For reducing power consumption we use RAM power down library to power down unused RAM and also we power down our external flash - it has an ultra deep power down mode. During reset if these are  in the powered down state the device won't boot up. This issue occurs only during software reset and not hardware reset.

The external flash being powered down affects the bootloader since bootloader(MCUBoot) checks for images in the external flash. I discovered this when I tried to disable the RAM power down and observed these logs : 

00> *** Booting Zephyr OS build v3.2.99-ncs1 ***
00> I: Starting bootloader
00> W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
00> W: Cannot upgrade: slots are not compatible
00> W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
00> W: Cannot upgrade: slots are not compatible
00> I: Bootloader chainload address offset: 0xc000
00> I: Jumping to the first image slot

This causes a boot-loop.

I'm not sure why the RAM has to be powered up before reset. 

I tried to include the respective power up functions for both of these in the Watchdog Callback but it does not solve the issue. 

Please suggest a workaround for this issue. Since our project is battery operated, power consumption is of top priority. 

Thanks,

Rosh

[Einar Thorsrud]

Hi Rosh,

What you describe seems likely. Have you attempted to enable power management in MCUboot to wake the QSPI flash if it happens to be in deep powr down mode after reset? In principle it should be similar to how you can handle it in your application.

Einar

[roshangeoroy]

Dear Einar,

You were right. Enabling power management in MCUBoot fixed the issue! I've added these configurations to mcuboot.conf. 

#Power management
CONFIG_PM=y
CONFIG_MULTITHREADING=y

CONFIG_PM_DEVICE=y

I've observed that enabling only CONFIG_PM_DEVICE does the trick as well. Do you know the reason behind this?

Anyways, thanks for the fix!

Rosh