cancel
Showing results for 
Search instead for 
Did you mean: 

Overcurrent Protection triggered immediately after flashing (no motor runnning)

ElGuerrero91
Associate II

Hi ST Community,

I am new to ST and hope to find a fast solution on this way.

 

Background:

I am working on a hobby project and want to drive a BLDC Motor. 

Once I flash the SW on the target, Overcurrent Protection is hit immediately (can see on debugger and Motor Pilot (in MCSDK).

 

Target: Custom Board based on EVSPIN32G4 Schematic (EVSPIN32G4)

Chip: STM32G431VBx3. 

Workflow

1.) Board Designer done over Motor Control Workbench

2.) New Project created and .ioc file generated

3.) Generating the Code over MX Cube (without touching any config)

4.) Start Motor Pilot or Debugger -> results in overcurrent protection (PWMC_OCP_Handler() is triggered immediately and OverCurrentFlag is set to true.)

 

My Assumption:

1. It is not an HW issue because I removed the Motor from the Board so there can no big current flowing.

2. I can see in MX Cube that not all of the Pins are configured from MC SDK, is that normal? Do I need to configure the missing pins (only related to motor control things which I have configured in MC SDK?)

3. There are also warnings in MX Cube, just ignore or need to be fixed?

4. I have increased the digital filter duration (and also set to "No Filter") -> both did not helped

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @ElGuerrero91,

On the EVSPIN32G4 board, by default, Motor Control Workbench directs the overcurrent limiter and driver protection signals to the same timer input, TIM1_BKIN. This configuration prevents the digital filter duration from being taken into account. On the EVSPIN32G4 board, the TIM1_BKIN2 input can be used for the overcurrent protection.
For the current sampling, did you align the sampling timings described in the Current sampling chapter of the User manual with your custom board components?

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA

View solution in original post

7 REPLIES 7
GMA
ST Employee

Hello @ElGuerrero91,

Could you check the current sensing parameters provided in your .json custom board file:
"shuntResistor", "offsetNetworkAttenuation", "opAmpGain", "polarizationOffset", "amplifyingNetworkImax", "amplifyingNetworkVm".
OCP comparators input/output are available on EVSPIN32G4 board, refer schematic.

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA

Hi @GMA ,

thanks for fast reply.

I checked the above parameters it should be okay.

I could also run the motor when switching off the overcurrent and driver protection features. Of course this is a workaround and not a solution.

---

I initially assumed that my overcurrent issue was caused by the Digital Filter Duration parameter and therefore attempted to modify it. However, changing this setting in the Motor Control Workbench configuration did not result in any changes in the generated software.

A folder comparison (before/after) showed no differences in the generated files. Additionally, triggering a rebuild resulted in a message indicating that no changes were detected, confirming that the parameter modification had no impact on the code generation.

 

is there a known bug in the Motor Workbench regarding this? (if not, I will setup my workspace again)  I am using the following tool versions:

Screenshot 2026-02-21 193307.png

 

 

GMA
ST Employee

Hello @ElGuerrero91,

Thank you for the digital filtering setting issue report. This point will be reported to the dedicated team for correction in future deliveries. In the meantime, copy the generated value of MotorControl.M1_OCP_BKIN_FILTER, defined in the .ioc file, into the TIM1 initialization code in main.c:

static void MX_TIM1_Init(void)
...
  sBreakDeadTimeConfig.BreakPolarity = TIM_BREAKPOLARITY_HIGH;
  sBreakDeadTimeConfig.BreakFilter = 4; /* Value to be updated */
  sBreakDeadTimeConfig.BreakAFMode = TIM_BREAK_AFMODE_INPUT;
...
  if (HAL_TIMEx_ConfigBreakDeadTime(&htim1, &sBreakDeadTimeConfig) != HAL_OK)
  {
    Error_Handler();
  }

For overcurrent, reduce the current target.
image.png

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA
ElGuerrero91
Associate II

 

Thank you for forwarding this issue for further investigation.

In the meantime, I checked whether my current‑measurement setup might be contributing to the behavior. Could you please take a quick look at the attached screenshot of Iq_Meas and let me know if this level of noise is considered normal? Even when Iq_Ref is stable, I see approximately 2 A peak‑to‑peak noise on Iq_Meas. Is this expected?

If not please can you let me know what should I check further?

Thanks a lot.

 

 

Screenshot 2026-02-24 001246.png

Hello @ElGuerrero91,

On the EVSPIN32G4 board, by default, Motor Control Workbench directs the overcurrent limiter and driver protection signals to the same timer input, TIM1_BKIN. This configuration prevents the digital filter duration from being taken into account. On the EVSPIN32G4 board, the TIM1_BKIN2 input can be used for the overcurrent protection.
For the current sampling, did you align the sampling timings described in the Current sampling chapter of the User manual with your custom board components?

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA

Thank you, Now the Digital Filter Duration changes takes affect.

I could solve the overcurrent issue it was the T-Rise Time which I have not set correctly. Now it is working reliable.

 

But now I am getting Driver Protection (Toggling between FAULT_OVER / FAULT_NOW). 

 

PS:

- I have a low inductance motor 0,03mH if this helps

- 25khz PWM

Hello @ElGuerrero91,

You can try to disable the STSPIN32G4 VDS monitoring (Jumper J2 on EVSPIN32G4 board).

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA