SDK NCS 2.6.1: TF-M v1.7.x updated to SDK NCS 3.2.4: TF-M v2.2.0
What changed in TF-M 2.x that broke CONFIG_LOG=n
In TF-M 1.x (your old NCS 2.6.1), TF-M fully completed its secure initialization and then handed off to the NS app. The NS app started in a clean, fully-initialized TrustZone
environment.
In TF-M 2.x, TF-M's secure thread runs concurrently with the NS app — the handoff happens earlier. This means the NS app's SYS_INIT sequence now runs while TF-M's secure thread is
also active. To protect NS→S PSA API calls, TF-M 2.x introduced an NS interface mutex, initialized at POST_KERNEL priority 40.
If anything in the NS app calls a PSA API (crypto, entropy, etc.) before that mutex is initialized at P_40, it corrupts TF-M's NS call stack → BusFault → double-fault lockup.
With CONFIG_LOG=y, log_core occupies POST_KERNEL P_0, which appears to delay or serialize whatever was racing to call PSA APIs before P_40.
With CONFIG_LOG=n, log_core is gone from the init sequence, and something at POST_KERNEL P_0 (likely the nRF-WiFi shim work queue or entropy driver) calls into TF-M before the NS
interface mutex exists.
This was a non-issue on NCS 2.6.1 because TF-M 1.x didn't have the concurrent thread model — the NS interface was always ready before the NS app even started.