GPIO inputs pushed LOW upon HSE failure

[Eliasvan]

I'm using an STM32H733 running from HSE clock with CSS disabled.

In a normal situation, the used GPIO inputs correctly read as HIGH as they are pulled HIGH by an external pull-up / LVTTL (push-pull) drive, verified with the oscilloscope.

After exposure to a brief (max. 1 second) EMI event, the HSE clock fails and those GPIO inputs are pushed LOW (as if they became GPIO outputs), verified with the oscilloscope. Furthermore, the UART communication is frozen (verified with oscilloscope, TX voltage is LOW), although a high-priority task is still able to toggle the SWO pin (verified with oscilloscope) albeit at a much lower frequency. Moreover, the MCU seems to have switched to run from the HSI clock, which would explain the lower frequency.
After that, when merely plugging in an STLink-v3 debugger (without even connecting to it), the MCU resumes normal operation: those GPIO pins resume working as intended and no longer push the voltage LOW, and UART communication resumes, at normal speed.

What could be the cause of the GPIO inputs being pushed LOW when the HSE clock fails?

[TDK]

Ground bounce or latch up issue? Lots of components here, board, debugger, oscilloscope, EMI source. How are grounds connected and how are ground loops avoided?

Plugging in the debugger likely resets whatever grounding issue is occurring.

[Eliasvan]

Thanks for your post, TDK.

Before laying out the exact details of the board's ground connections, there's another bit of information that might be useful: when adding some extra capacitance to SWCLK (the one that could be used to connect a debugger to), the HSE failure and GPIOs being pushed LOW doesn't seem to occur! So it seems like EMI-introduced noise on SWCLK causes HSE clock failure.
Knowing this, could it be that STM32's SWCLK - when, e.g., glitched through the EMI event - causes those GPIO inputs being pushed LOW, and if yes, is there any command/sequence in this debugging interface that could cause such a thing, and how exactly (this might require internal ST knowledge)?
Or could the HSE clock failure be causing the GPIOs being pushed LOW, and if yes, how exactly?

[TDK]

The issue is likely specific to your setup. How would a failing HSE control other non-connected GPIOs? Things on the chip are isolated and work independently. No reason to assume a bizarre internal connection. HSE stimulus is small.

[Kristof]

Maybe it some kind of "default" reset behavior after a CSS event if it's not handled?