Firmware Fault Forensics — Debugging Inherited STM32H7 Firmware

Four theories died first. One of them was ours.Kyros Engineering diagnosed a firmware update that froze partway through on a commercial water-treatment controller. After four hardware-tested theories were ruled out, a Kyros-built SWD probe read the fault registers out of the running STM32H7 core without halting it, showing an imprecise BusFault and a corrupted status struct. The cause was two DMA masters writing into the same SRAM region; the fix was twelve lines that quiesce the data logger around an update on every exit path.The symptomFour plausible theories, tested on hardware, all wrongReading the fault out of a running coreThe fix was twelve linesA byte-for-byte reproducible buildFrequently asked questions

Can you debug firmware your team didn't write?

Yes — inherited codebases are the majority of our firmware work. We reproduce the failure on real hardware, instrument it at the register level over SWD, and deliver a written diagnosis before proposing a change.

What is an imprecise BusFault and why is it hard to debug?

On ARM Cortex-M, an imprecise BusFault means the offending write was buffered, so the CPU cannot report the address that caused it and BFAR is empty. The fault is reported after the fact, which is why guessing replaces evidence unless you capture the surrounding state.

How do you debug a board that has already frozen, with no debugger attached?

Attach over SWD in HotPlug mode, which connects without halting or resetting the core. A frozen board is still holding its own evidence — halting it to attach a debugger destroys the state you need.

Do you publish client source code in case studies?

No. We publish our own diagnostic tooling, its output on our bench, and patterns re-authored for publication. Client source, repository paths, customer names and logos are never published.