Closed sapphire-arches closed 2 years ago
it's possible the target's (an STM32L151C8T6) SWD/JTAG core has suffered some unfortunate electronic accidents and thus isn't operating at 100%, but we probably shouldn't be hanging GDB regardless.
Does the STM32L1 use longer sleep versions? BMP does not enable debug in these states by default. If some transaction happens in that state, timeout will probably happen. Somebody needs to implement...
I'm not sure I understand what you mean by "longer sleep versions". To the best of my knowledge the STML1 parts use ST's standard SWD/JTAG implementation but I haven't absorbed that particular part of the reference manual in detail.
Does your code use WFI/WFE? What is the minimal rate at interrupts happening. E.g. in Ethernut we use WFI, but also 1 kHz timer tick. That way, longest sleep is 1 mS.
Oh, I see. My code polls the USB peripheral in a tight loop, with no interrupts at all. So the CPU shouldn't ever be going to sleep.
A simple "blackmagic -t" log will help more. The hosted log does not show the hanging sequence.
Sorry, this didn't repro for awhile but I saw it again today. Unfortunately I don't have a detail capture from exactly after it happened (I'll try to grab that next time...). The non-detailed log just said that the SWD probe failed and BMP automatically fell back to JTAG, which worked for scan. After attempting to attach using JTAG it seems like the debug unit is really stuck in a bad state, and produced these detail logs: https://gist.github.com/bobtwinkles/5b81d4d597dc60ab4681c024b9815de5
oh, another potentially important datapoint is that the attach attempts via GDB do appear to at least halt the CPU, as my heatbeat LED stops flashing.
Random problem in most cases are hardware problems, flacky cables, flaky supply, loose pins. "blackmagic -t" on the L1 Discos works repeated.
@bobtwinkles I also have the feeling that this seems like a "flaky hardware" problem. But I could always be wrong. Should we continue investigating or should we close this issue?
I finished the project that this was attached to and didn't see too many more issues. I also agree that it was likely a hardware problem, sorry for the noise.
If something similar happens in the future I now have much better tools for diagnosing them, so hopefully I'll at least have some SIGROK traces for you =).
Something is causing GDB to hang after sending a qL request packet to the blackmkagic host.
GDB log:
Log from
./blackmagic -v 31
And the GDB script that hangs:
GDB version info: