When the Debugger Lies: A Stale Cache Mystery on Nordic's nRF54L
While exploring the nRF54L's Key Management Unit via GDB, Daniel Mangum found that pushed key values never updated at the destination address. The debugger's memory reads returned stale data, but a direct AHB-AP read showed the correct value. The culprit: GDB's default read path goes through the CPU's data cache, while J-Link's ReadMemAP bypasses it. The post unpacks the SoC's debug architecture and explains when to distrust your debugger.
Sure enough, reading directly from the AHB-AP showed the expected value. Furthermore, after issuing the read, subsequent examine (x) commands from GDB continued to return stale values.
- zavec
Very cool! I love reading about details like this.
- Loren_SL
Nice writeup. WinDbg has the same stale-cache trap on live Windows targets.
- LoganDark
Once upon a time I had to figure out an issue where I forgot a `return` statement at the end of a non-`void` function, so the C++ compiler happily omitted both RETs for some reason and let the program go straight into illegal instructions. That was fun to debug (not fun, I practically had to single-step through the entire program) because every time this happened the debugger was incredibly confused about what the fuck was going on and nothing made any sense.