STM32H7 - How to tell if debugger is attached?

[n2wx]

So I was handed code that breaks when debugging, but to fix the breakage breaks a power control on the board. Rev A only has this problem but Rev A is what I'm stuck with . Nice, right?

So I need a way to tell at run time whether the debugger is attached.

Does anyone have any idea how to accomplish this without changing the hardware?

[berendi]

Read GPIOA->IDR a few times, if bits 13/14 are changing, then there is most probably a debugger doing its stuff. Even EXTI interrupts should work on it while a pin is in AF mode.

[Tesla DeLorean]

DBGMCU_IDC reads zero in Keil

[n2wx]

This sounds kind of contingent. How many reads do you think are needed for 99% (or some extremely reliable) confidence?

[n2wx]

I was wondering why this sounded familiar. Our old friend for checking the chips release level! Unfortunately I'm in TrueStudio and I'm in an enforced timeout due to an overtemperature but when it comes back I'm going to see if I can persuade it to expose its J-Link-attached status. In a more perfect world I wouldn't have to ask you folks for workarounds for stupid problems like the one im facing.

[berendi]

I would be extremely confident if I got 10 EXTI events within 1 ms on the SWCLK pin.

[Pavel A.]

Have your debug start script write a magic value to some memory address at startup.

Then you'll know if the debugger is present.

This is simpler than poking around, though adds dependency on debugger script.

-- pa

[Tesla DeLorean]

This is some special H7 stupidity, likely with how the dual core shares things. I'm not sure it is Keil specific, but it is frustrating at times.

The other way is via a couple of the ITM or DWT register bits. General method here is to printf() a bunch of good suspects and try on/off the debugger, and with ST-LINK, J-LINK, etc.

[Tesla DeLorean]

The request is more of a IsDebuggerAttached() one

[n2wx]

This is exactly what it is. It's not a request I'm happy to make but one that this particular project even though it supposedly has a 60 page requirements doc that was part of the contract was drafted by engineers on their side and accountants on our side without a smidgen of engineering input so we got hosed pretty thoroughly. Between this stupid requirement and my personal fight with GNU's awful tools that should but aren't updating a section with my calculated CRC I'm ready to throw it all through the window (except it's the window in my home lab so it'd me more business expenses that I'd have to cover out of my own pocket) and go back to my other profession, practicing law, but even the worst of days as an engineer is a better day than 99 out of 100 days practicing law.