Protection against HRTIM output locking high

[DavidNaviaux]

I am using an STM32G474 to create an inverting buck-boost converter, but after damaging a few boards, I realized that there is a series design issue that could short 24V to ground through an inductor if the HRTIM output pin ever goes high unexpectedly.  Here is a clip from the schematic:

Note that if the top MOSFET of the half-bridge gets switched on for longer than a few microseconds, there will essentially be a short from 24V to ground through L1.

Is there a way that I can significantly reduce the chances of this happening under the following conditions?

1. When using the debugger.
2. When flashing new code.
3. When cycling power very quickly.
4. If the MCU starts executing from uninitialized memory (i.e., RAM) for any reason.

I know some features that I might be able to use, listed below, but I'm a newbie with this MCU and digitally controlled power supplies in general:

1. Watchdog timer
2. Over current fault detection via the pulse transformer
3. Brownout power detection
4. Loss of power detection interrupt 

Is there a way that I can force an MCU reset that will require a power cycle to recover from if an invalid instruction is executed or if code execution is not happening from within a defined region?

Thank you!

[Pierre_Paris]

Hello @DavidNaviaux,

Here some comments/questions about your possible actions :

• You are driving two transistors with the HRTIM, you need to have complementary signals. A good solution to avoid big conduction is to use the deadtime feature that allows to control programmable delays.
• If you are afraid of "HRTIM output pin ever goes high unexpectedly". You can check the GPIO registers to check configurations. If (by default) there are I/Os with a pull up...
• Also, you cannot start executing from RAM, you boot in flash. You want to use the bootloader ?
• Why from uninitialized memory ? You'll probably get a segmentation error.
• If you want to monitor the VDD, you can use the PVD and compare the power supply to a threshold selected by the PLS[2:0] bits. You can discover more information in the Reference Manual here (paragraph Transition mode power factor correction of chapter HRTIM).

Best Regards,

Pierre

[DavidNaviaux]

Pierre, actually the two FETs are being driven by an external half-bridge gate driver.  The gate driver received one PWM signal from the MCU.  The deadtime is handled by the gate driver.

I never wanted to start executing from RAM.  My problem was that I had the BOOT0 pin floating and with the default option bits, that caused the code to start executing out of uninitialized RAM which eventually caused the PWM output signal from the MCU to go wild (toggling between high and low with no particular timing).  This caused a direct short from the +24V through the top FET and the filter inductor to ground (when the PWM signal was high).  Had I not been using a current limit power supply, I'm sure something would have been damaged.

Once I found out that the BOOT0 pin needed to be low the very first time the MCU was power, I made the correction.  

Thank you, I'll look into the PVD.

[DavidNaviaux]

Pierre, below is the complete schematic of the inverting buck-boost converter.  The single PWM signal from the STM32G474 toggles the input of the half-bridge gate driver between +12V and the negative output voltage.  This is required because the gate driver is referenced to the output voltage not ground (as required by this topology).

I am still working at responding to fault conditions, include using the PVD.  I have to be careful here because if I make a mistake, instead of forcing the PWM outputs low, I could force them high.

[Pierre_Paris]

Hello @DavidNaviaux,

Thanks for sharing your full schematic !

Here some answer :

• "I had the BOOT0 pin floating and with the default option bits, that caused the code to start executing out of uninitialized RAM" -> There are 3 boot modes on the STM32G4. If you want to forces boot from Flash memory regardless the other option bits you need to forces BOOT_LOCK. (See picture below)

• "Had I not been using a current limit power supply, I'm sure something would have been damaged." -> You can check the Absolute maximum ratings paragraph in the Electrical characteristics chapter in the Datasheet.
• "I make a mistake, instead of forcing the PWM outputs low, I could force them high" -> Do you know the Burst mode controller ? "The burst mode controller allows to have the outputs alternatively in IDLE and RUN state, by hardware, so as to skip some switching periods with a programmable periodicity and duty cycle. [...] The burst mode controller is able to take over the control of any of the 10 PWM outputs. The state of each output during a burst mode operation is programmed using IDLESx and IDLEMx bits in the HRTIM_OUTxR register" You can read the full chapter 27.3.15 of RM0440.

Best Regards,

Pierre

[DavidNaviaux]

Thank you Pierre,  I'll have to read about burst mode.

The original problem I had was that with the floating boot0 pin, the very first time the MCU was powered, it executed out of uninitialized RAM and actually generated random output on my PWM pins resulting in an intermittently shorted power supply.  I was able to program the MCU eventually, but each time it reset, this was happening.  I'm not familiar with the BOOT_LOCK bit, but this problem was solved by a PD resistor on the BOOT0 pin.  I later began programming the option bits to ignore the BOOT0 pin and to execute from Flash.  Although the PD resistor solved this issue.  Thanks again.