MCUboot Watchdog and Multithreading Dependency in NCS 3.0.1

[Tcunha]

Hi, I've encountered a change in behavior when upgrading from NCS 2.9.1 to NCS 3.0.1 regarding MCUboot and watchdog integration.
In NCS 2.9.1, I was able to enable the watchdog in MCUboot without having to enable multithreading (CONFIG_MULTITHREADING). However, after updating to NCS 3.0.1, enabling the watchdog in MCUboot results in build errors related to multithreading symbols, such as:

undefined reference to `z_impl_k_sem_give`

It appears that there's now an implicit or explicit dependency on multithreading in MCUboot when CONFIG_WATCHDOG is enabled. Could you please clarify:

1. Whether this change was intentional or expected?

2. Why does MCUboot now require multithreading when watchdog support is enabled?

3. Is there a recommended way to use the watchdog in MCUboot without full multithreading enabled ?

[Susheel Nuguru]

Hi, 

It looks like in NCS3.0.x there is a bit of a rework in the nrfx watchdog driver which is now using k_sem_take in wdt_nrfx.c. This introduces the dependency that these WDT driver now either needs multithreading to be enabled (CONFIG_MULTITHREADING=y in your mcuboot.conf) or you can disable the driver’s IRQ synch (CONFIG_WDT_NRFX_NO_IRQ=y), feed the watchdog with the raw nrfx calls (CONFIG_BOOT_WATCHDOG_FEED_NRFX_WDT=y), and/or force minimal logging (CONFIG_LOG_MODE_MINIMAL=y)

The problem with enabling multithreading is that it adds the whole scheduler logic into MCUBoot which is a couple of hundreds or a thousand bytes of extra memory. If you do not mind that then enabling this config is the simplest to do. Else you need to use the WDT with the NO_IRQ config. 

If you do not want to do none of the above, then there is a hackish workaround (not tested in regression testing and might introduce corner case bugs) is to remove the two instances of k_sem_xxx in ncs\v3.x.x\zephyr\drivers\watchdog\wdt_nrfx.c and everything compiles (again, not tested in long running regression tests, use with your own riskwdt.patch)

It will atleast compile fine without the k_sem_take, you can choose which ever solution now fits your use case. The third one at yoyour own risk.