When the Debugger Lies

This write-up examines debugging a subtle interaction between a SoC security subsystem and a debugger while working with Nordic Semiconductor’s nRF54L series. It explains the device’s security building blocks - Cortex‑M33 TrustZone, the CRACEN cryptographic accelerator, and the Key Management Unit (KMU) that stores keys and metadata in Secure Information Configuration Region (SICR) slots. Typical firmware uses PSA drivers rather than direct KMU access; for example, a key generation path eventually invokes a CRACEN PSA driver routine (import_key_for_kmu) to place material into a KMU slot. The specifics matter because KMU operations are secure-only and can be modified by peripherals with direct memory access, so understanding the internal slot/task model is important to diagnose odd behavior.

The core finding is that a J‑Link debugger’s memory cache can report stale values when the CPU is halted, leading to misleading examine results. Disabling the debugger memory cache (monitor exec SetEnableMemCache = 0) produced fresh reads, but that isn’t generally recommended: with caching enabled, stepping the CPU a few instructions clears the cache and returns updated memory. The write-up explains why stale reads occur (halted core, prior cached accesses) and advises understanding bus architecture and using methods that bypass the cache - such as direct access port reads - when inspecting regions that peripherals or DMA may update while the core is stopped.