Sensorless FOC. Motor suddenly runs in reverse direction on load change

[jovijuan]

Hi everybody,

This is the configuration of my setup:

• MC Motor Control Workbench v6.4.1
• LL library
• 24V, 2 pole pairs, 5A, BLDC motor.
• Observer + PLL (Sensorless)
• Max speed 16000 rpm
• Custom board with STM32G491
• Control mode: speed
• Current measurement topology: 3 shunt

I am testing motor control and tuning PID constants. When I apply some braking torque to the output shaft, sometimes the motor starts rotating in the opposite direction at full speed, and it stays there.

I have experienced the same with v6.3.2

It doesn't seem to be related to control constants.

It looks like it has happened before in this forum (link) and it doesn't look like it was fixed.

The plot with the reference and actual speed is attached.

Has anybody experienced this before?

Edit: 17/10/2025: add the missing attachment, board description, control mode and current measurement topology

[GMA]

Hello @jovijuan,

The attachment is missing.
Which boards and current topology are you using? Are you using torque or speed mode?

[jovijuan]

Thanks for pointing that out. I have edited the original post with the following details

• Custom board with STM32G491
• 3 shunt
• Speed control mode

[jovijuan]

By the way. It's a custom board, but I can run it with STLink V3 connected. I might pause when that happens or monitor variables on the fly via SWO.
I'm still checking what could be the reason. It looks like an overflow or signed/unsigned issue.

[jovijuan]

I can reproduce the direction shift and capture data. Torque reference doesn't seem to flip, maybe it's the rotor position estimation that changes and a positive torque reference turns the motor in the opposite direction.

Al least, as speed is correctly identified, it should be possible to trigger a "Speed Feedback" error similar to when the speed gets too low

[unsigned_char_array]

Log all important variables.
You can log them periodically (maybe 10Hz?) in an array and send them live via UART or send/read them after the experiment.

[GMA]

Hello @jovijuan,

In the first attached picture, the issue occurs immediately after the starting point.
Does the issue only occur at this point? If yes, did you apply the braking torque during the SWITCH_OVER state?

If the RUN state is achieved when a negative speed occurs, the firmware must report a SPEED FDBK error. As this is not the case, the issue might originate from error detection. In this scenario, replace the following lines in the speed_pos_fdbk.h file.

static inline bool SPD_Check(const SpeednPosFdbk_Handle_t *pHandle)
{
  bool SpeedSensorReliability = true;
#ifdef NULL_PTR_CHECK_SPD_POS_FBK
  if ((MC_NULL == pHandle) || (pHandle->bSpeedErrorNumber == pHandle->bMaximumSpeedErrorsNumber))
#else
//  if (pHandle->bSpeedErrorNumber == pHandle->bMaximumSpeedErrorsNumber)
    if (pHandle->bSpeedErrorNumber >= pHandle->bMaximumSpeedErrorsNumber)
#endif
  {
    SpeedSensorReliability = false;
  }

Did you observe the same behavior with MCSDK6.3.2?

What are the PWM frequency and the duration value for the "rev-up to FOC switch-over" in your use case?

[jovijuan]

Hi @GMA,

Thanks for your reply.

The starting is quite quick. It's already under RUN state when it switches direction.

I have not tested the startup against that braking force, I have always replicated the issue by applying braking force after it is in target speed.

The same behavior can be observed in v6.3.2, I just confirmed it.

[jovijuan]

Hi @GMA ,

Sorry for the late reply, but I'm having issues checking that solution. I had some mechanical issues with the motor and, when I fixed them, the mechanical play was removed and it's more complicated to replicate the error.

The issue didn't seem to be related with bSpeedErrorNumber, this is a screen capture I took while the motor was running full speed in the wrong direction a couple weeks ago:

 You can see that bSpeedErrorNumber is 0.

Anyway, in the new mechanical setup I've only been able to reproduce the error at very specific conditions (forcing PWM frequency to 160kHz and lowering a lot control constants), and the code modification didn't detect that either.

I'm afraid that, with a different mechanical configuration or observer constants, the motor starts spinning in the wrong direction.

I also confirmed that, during RUN, if the motor is running backwards, there is not SPEED FDBK error reported. I'll take a look at modifying that, as it should at least be a protection against this failure.

Regards,

[unsigned_char_array]

Like I replied before. Please log all variables and states periodically.  The controller is nothing but mathematical formulas. By looking at the variables around the time the motor reverse you can see exactly where it goes wrong. Maybe some type of overflow (integrator overflow? please saturate integrator in your PID controller, preferably via back calculation). Maybe another bug. Maybe noisy data that isn't filtered properly. Could be a lot of things. But without data all we can do is speculate.