cancel
Showing results for 
Search instead for 
Did you mean: 

STSPIN32G4 random gatedriver or timer1 output shutdown

DWiec.1
Associate

Hello I am using a custom design with the STSPIN32G4.

Running open loop space vektor commutation works, but after a random amount of time the motor simply stops.Surprising is that if SPI is active the error seems to occure sooner than normal.

Everything else seems to work fine (Control loop interrupt, main loop, i2c communication, SPI communication even the timer1 interrupt).

No protection fault is being generated by the Driver. A reset and clear of the driver does not help.

A software MCU reset seems to solve the Problem for a moment.

Without a load it seems the problem does not ocure.

So my thought is that it is an EMC problem. But why does it only effect the driver or the timer?

Is there a recommended layout or a layout guide for the STSPIN32G4?

I think since a MCU software reset solves the problem temporaly and I would assume that the reset does not affect the Driver. The problem is within the Timer1.

Does anyone know how I could investigate it further? Should I reduce the FET driver current?

1 ACCEPTED SOLUTION

Accepted Solutions
DWiec.1
Associate

Hello @Cristiana SCARAMEL​  thank you for your answere.

I developed a new hardware revision. The problem has not yet occurred with this new hardware, although the same code is used. So I think there was a hardware problem in the earlier revision.

View solution in original post

2 REPLIES 2
Cristiana SCARAMEL
ST Employee

Hello @DWiec.1​ and welcome to the ST Community.

If I understand well you are using a custom board and a custom firmware.

As a first step you could try to load the firmware with the STM32 Motor Control SDK and check if the application works properly. In this way we try to exclude hardware problems.

If you feel a post has answered your question, please click "Accept as Solution"
DWiec.1
Associate

Hello @Cristiana SCARAMEL​  thank you for your answere.

I developed a new hardware revision. The problem has not yet occurred with this new hardware, although the same code is used. So I think there was a hardware problem in the earlier revision.