Firmware Reset failing with MCUboot and WDT

Question

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; 
 
 Device powers down and enters bg_thread_main() in "ncs\v2.2.0\zephyr\kernel\init.c", it doesn't enter our application main() 
 Device enters MCUboot 
 After sometime the watchdog resets, the device enters MCUboot again 
 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 · Accepted Answer

I'm sorry for the delayed response. I've been working on debugging the code to identify what is triggering the SPU event. It turned out to be quite challenging because the security violation is not caused by the CPU but by another bus master. 
 
 I have not been able to pinpoint the source of the flash access error, nor have I found any other reports of this event happening under similar conditions. However, upgrading to SDK v2.4.4 may resolve this issue as it includes several errata workarounds that were not present in SDK v2.2.0. 
 A workaround for now may be to issue a soft reset from the SPU ISR in TF-M to avoid having to wait for the WDT timeout. For example, by adding the following to ncs/v2.2.0/modules/tee/tf-m/trusted-firmware-m: 
 diff --git a/platform/ext/common/faults.c b/platform/ext/common/faults.c
index eb87c971c..9124030c2 100644
--- a/platform/ext/common/faults.c
+++ b/platform/ext/common/faults.c
@@ -107,3 +107,8 @@ __attribute__((naked)) void UsageFault_Handler(void)
 "b . 
"
 );
 }
+
+void SPU_IRQHandler(void)
+{
+ NVIC_SystemReset();
+}
\ No newline at end of file 
 hugzy123 said: It seems like because the reset pin never goes low again it doesn't complete a reset. You can see this using the "Boot Reset" button on the DK; if I hold the button down the device won't reset, It's only when I release the button does it reset. 
 I think you are right. The specification does not guarantee the pin state in reset, only when going out of reset. I know this approach with using a GPIO to trigger pinreset worked with the nRF52840 but there are some differences in the reset mechanism between the nRF52840 and the nRF5340.

Firmware Reset failing with MCUboot and WDT

Top Replies