The board ran fine all morning.
There was no new Git change and the build was the same. Then I connected the debugger, pressed Connect, and the status LED went out.
The tool I brought to find the error had become part of the event.
Before changing the code, I want to know what changed first.
A probe that cannot reach the target and an application that fails after the probe attaches are two different problems.
If the probe cannot connect, I check common ground, target reference voltage, SWD wiring, and the reset line.
If it connects and the application fails afterward, I check how the debugger attaches. Depending on the settings, it may reset or halt the core while external input or some peripherals continue to move.
A Watch window is not always a quiet observer, either.
Reading some status registers clears their flags. If opening a view changes the clue I meant to inspect, I go back to the datasheet and check what a read actually does.
I compare runs with the same binary and the same input, first without the debugger and then with it attached.
Recording reset and one external signal around Connect can reveal where the paths split. I change one setting at a time so I know which change mattered.
This does not mean the debugger is always to blame when a board stops.
It means finding the first difference: the cable, the reset, the halt, or the register read. That is where the investigation starts.
Loading comments.