Showing results for 
Search instead for 
Did you mean: 

STSPIN32G4 running very hot

Associate III

I designed my own PCB largely based on the EVALSTSPIN32G4, mine being a four layer board with components on both sides for compactness.

I generated code using MC Workbench 5.Y.4 with hall sensors. I implemented my own absolute encoder via SPI, and added CAN Bus communication.

Everything seems to be working fine, except that the MCU seems to be running at 60 to 70 degrees Celsius, and the board will eventually stop working.

I am powering it with a 22.2V 6 cell LiPo battery, but I have also powered it wit ha proper power source.

Running firmware for motor control only, with motor idle, the board pulls 0.15A at 24V. With the motor running it pulls 0.3A. Adding the encoder or CAN Bus does not add any significant current draw.

The only caveat is that I am bypassing Boot0 on pin B8 by clearing nSWBOOT0 on flash, since I use that pin for one of the hall effect sensors.

Below is the current NVIC table. I am using an interrupt for the encoder over SPI, but I might change that to DMA if it helps.

So the hypothesis right now is that overheating is causing my troubles. But it could be anything really, with all sub-systems running together. Running a separate code with encoder over SPI and CAN Bus is very robust. If I uncomment this line out MX_MotorControl_Init(); things get very hot 😉

Do you have any suggestions where to start looking for the source of this issue? It will be highly appreciated.


ST Employee

The strong heat generation should be due to SMPS and the gated drivers, depending on the load of VDD (3.3V) also to the LDO. Please have another look at the dimensioning of the buck regulator coil, as well as the free-wheeling diode used there.

What are the parameters of the power stage transistors and how are they controlled (e.g. gate resistors, etc)?

What current do you draw from the LDO?



In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Peter, thank you so much for your quick reply. It seems that you are hitting right on the head of the problem.

0693W00000LxvWVQAZ.jpgIn the buck regulator:

  • power inductor L1: 18uH, Ir = 0.98A, Isat = 0.7A
  • diode D1: STPS05060Z 60V, I_forward_RMS = 2A, I_forward_av = 0.5A


  • Vgs(th) = 1 to 3V, Id = 250uA

Power Sensing (3 Shunt):

0693W00000LxvWpQAJ.jpgPower consumption/Current Draw:

  • Vcc // Imax = 200mA
    • encoder type A = 65mA
    • encoder typeB = 150mA (I noticed that with encoder type B, the board fails sooner, so exceeding some allowed current threshold seems at play here as you suggested)
    • hall sensors = 12mA

  • Vdd/Vdda (LDO)
    • Line drivers = 31mA
    • CanBus transceiver = 60mA

Hopefully the information above is clear. If not please, let me know.

Best regards


For the maximum currents specified in the data sheet, only the footnote is given there: Actual operational range can be limited by thermal shutdown.

I assume that you have connected VCC to REGIN so that the current through the LDO is also added to the load on VCC. If you then maybe programmed VCC to 12V or even 15V, the LDO has to burn even higher differential voltage (multiplied with the LDO output current).

So you have a lot of load on VCC and VDD, which of course produce a lot of power dissipation. Depending on the thermal resistance of your layout, there will then of course be a corresponding temperature difference.

I would strongly recommend that you completely revise the power scheme and think about how the required supply voltages can be generated externally. In doing so, you can distribute the power dissipation over a larger area and/or generate the 3.3V with an external switching regulator, for example.



In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


That makes perfect sense and it's a great advice.

I naively connected VCC to REGIN without considering that the current through LDO would be going through VCC too, pushing it over its limit.

I will re-design my power scheme. I have VCC at its 8V default now, but since I already have a voltage regulator on the board to supply 5V to peripherals, I will change that part and connect VM (48V)-> regulator -> 5V REGIN, & Peripherals, bypassing VCC, alleviating the Buck regulator load the heat dissipation of the LDO with a smaller differential voltage. I hope that makes sense, but I am open for other suggestions.


Thank you so much!


@Peter BENSCH​ after spending more time on the solution, I am planning to change the power topology as follows:

  • I will power all peripherals to be power by a 5V 300mA external buck converter, e.g. L7983PU50R. I was able to source all peripherals Vin 5V.
  • I will keep the embedded buck converter power tied-in SW to VCC to power the gate driver
  • I will also keep the VCC tied-in to REGIN to the LDO, and power the MCU and gate driver logic that way.

With all peripherals running straight from VM through the external buck converter, the internal buck converter and LDO should run very light.

Thank you again,


Associate II

Hi @PCama.1,

Were you able to solve your problem? I am also facing a heating problem with the controller. 

I have a problem with my custom stspin32g4 board ( see photos attached).

I have tested with my MOSFETS and buck converter inductor.

The STSpin32g4 controller gets hot once I connect my MOSFETs, especially the GLS3 MOSFET.

The motor pilot goes to the STOP state whenever I click on start on the motor pilot, and the controller gets hots ( see video attached)

Project-Motor_controller_PCBA (1).jpgProject-Motor_controller_PCBA (2).jpg


However, whenever I remove the MOSFETs, it goes to the START state on the motor pilot, and the controller doesn’t get hot.



I have checked for partial contacts and cannot find any within the PCB circuit.



My circuit was made exactly from the EVSPIN32G4 schematic.



I would be very happy if you could link me to the technical team of STSPIN32.


Thank you very much,


Aminu Bugaje