When the Debugger Lies
While debugging Nordic's nRF54L microcontroller, an engineer discovered that the J-Link debugger's memory cache caused it to return stale values after a hardware KMU push.
read it Read this if you work with embedded systems; it provides a clear walkthrough of diagnosing J-Link cache behavior during direct memory access operations.
summary
The author was testing the Key Management Unit on Nordic Semiconductor's nRF54L series using GDB and noticed that memory addresses did not update after subsequent hardware push operations. By investigating the ARM CoreSight architecture and J-Link GDB server commands, they tracked the issue to JLinkArm.dll's internal memory caching. The cache assumes memory remains unchanged while the CPU is halted, requiring either CPU stepping, cache disablement, or direct Access Port reads to see fresh data.
key points
- Nordic's nRF54L series includes a Key Management Unit that can push stored keys directly to specified memory addresses via hardware tasks.
- GDB showed stale memory values after subsequent push operations because the J-Link debugger's memory cache assumed memory hadn't changed while the CPU was halted.
- Bypassing the cache via a direct ReadMemAP command or disabling it with SetEnableMemCache = 0 revealed the updated memory contents.
who should read it
Embedded systems engineers and low-level developers working with ARM microcontrollers and J-Link debuggers.
discussion positive
consensus
Commenters share similar war stories about misleading debuggers and note that similar stale-cache traps exist in other environments like WinDbg.
Nice writeup. WinDbg has the same stale-cache trap on live Windows targets.
It points out that this stale-cache trap is not unique to J-Link, affecting live Windows targets in WinDbg as well.
Generated by an LLM from the article and thread. Check the sources before relying on it.