Excessive MCU heat after debugging

[DavidNaviaux]

I have a design that uses two HRTIM outputs from an STM32G474 MCU to provide a PWM signal to two external half-bridge gate drivers to drive two DSMPS, a buck converter and an inverting buck-boost converter.  

After several debugging sessions, the MCU continues to function but starts to heat for no apparent reason, exceeding 70°C and beyond, one time to destruction.   The heating continues even if I erase the MCU with the STM32CubeProgrammer.  After replacing the MCU, things are back to normal so it seems that I damaged the MCU while debugging.  I'm still in the process of developing the control for the converters and am currently operating them open loop a fixed HRTIM PWM duty cycle to generate about +3V and -3V.

I've searched for, but could not find any reference to issues with debugging DSMPS.  The biggest concern is the inverting buck-boost topology because if the HRTIM output is stuck high, +24V will get shorted through the pulse transformer, the top MOSFET, and the filter inductor to ground.  Is it possible that during the process of updating the firmware via the debugger there can be a time that the HRTIM output is latched high?  A clip from the schematic is below: 

[DavidNaviaux]

If it is possible that the PWM signals stay on for more than a few microseconds (e.g., if they freeze high while debugging or when reprogramming) my design will exceed the maximum input voltage on at least 1 MCU pin and maybe one other.  My assumption at this point is that the MCU is getting damaged by this.  The PCBs are already fabricated and being assembled right now, so I can't add clamp diodes which might be the best solution.  However, if I can prevent the PWM pins from ever latching high in firmware, that would solve the problem.  I'll review the HRTIM fault protection.  If anyone has some other suggestions, please help!

[DavidNaviaux · Accepted solution]

The issue turned out to be a design issue that required some PD resistors on the PWM pins.  The full solution was identified in another thread:

https://community.st.com/t5/stm32-mcus-products/debugging-and-programming-causing-catastrophic-hardware-failures/td-p/612669