Debugging and programming causing catastrophic hardware failures

[DavidNaviaux]

I am working on a custom board design that uses an STM32G474RBT3 to drive the PWM signals to a buck converter and another PWM signal to an inverting buck-boost converter via the HRTIM.  If the PWM signals lock high for more than a few microseconds there will likely be damage to the board.

I am using the STLINK-VSET3 to debug and program the MCU.  Most of the time I don't seem to have a problem when reprogramming the MCU to test updated firmware, but every once in a while, I hear a "click".  Most of the time after the click, all seems to be working okay but the MCU begins running at an elevated temperature (40°C to 70°C) and most of the time will eventually fail (a day or two later).

Currently, I am not controlling the voltages of the power supplies; I'm just generating a fixed PWM signal open loop to verify that the converters function.  Also, I have not explored setting the PWM signals low in the event of a fault condition (i.e., core lockup, RAM parity error, execution of an invalid instruction, etc.).  Partly because I can't find a good reference that discussed the various faults.  

I have gotten some great advice from this forum which, as a newbie, is greatly appreciated. 

Does anyone know of good reference to the faults that will allow me to set the HRTIM PWM signals to inactive states or have any other advice?

[gbm]

Make sure that the hardware design is safe. Keeping the MCU in reset state should not bring any harm to the device. Then, maybe you should enable "connect under reset" or "reset after connect" option in ST-Link settings.

[DavidNaviaux]

The board has been used without any failures for a couple of weeks by others.  The failures only happen when programming it.  I didn't know about that option.  I'll try that.  Thank you.

[Imen.D]

Hello @DavidNaviaux,

Please review the described aspects in this FAQ: Why my STM32 doesn't start? - STMicroelectronics Community

This article will help you with some caution and knowledge, which are required to make sure the STM32 starts properly in your custom board design.

Imen

 

[DavidNaviaux]

Thank you, I'll read that.  However, the design is currently in use and we don't have any startup issues.  But, although I have designed embedded controller for many years, this is my first ARM design and have been having difficulty locating information, for example the OPTION bits don't seem to be completely explained anywhere that I could find.

[gbm]

From your report I assume the problem is that during debug probe connection the MCU stops, holding activbe state at timer input. So the solution is to guarantee inactive state of timer input. This may be achieved either in software - say, when the button is pressed the device shuts off the outputs. or by hardware resetting the MCU before programing - this is achieved by "connect under reset" with NRST pin connected to debug interface.

I don't know what your hardware setup is, but I believe the safest solution would be to physically disconnect the high-voltage power during programming and power the MCU from the debug interface. That's what I usually do.

[DavidNaviaux]

Thank you!  Leaving the option bits for NRST_MODE to 3 (bidirectional NRST pin), setting the STM32CubeIDE STLINK configuration to "connect under reset", and by adding two pull-down resistors (explained below), I no longer am having the problem.

I found the reason for the large voltage spike that was damaging the MCU current sense input pin.  I was depending on an internal pull-down resistor on the PWM input to my gate driver to quickly shut off the PWM if the MCU was reset and the PWM pin floated.  However, it turns out that that resistor is typically 4Mohm and with just 10pF of capacitance, it would take 56us to pull the PWM pin low if it were high.  56us will result in 134A of current and a 13V voltage pulse to the MCU current sense input pin which was damaging that pin (low resistance short to 3.3V).  The heating was the result of the pin sourcing current when it should only be an input.  The problem was resolved by adding 10kOhm pull-downs on the PWM output pins which will guarantee that the PWM floating pins at reset will be pulled low within 150ns.

Thanks again for you help!