First motor start fails with SPEED_FEEDBACK fault, second start works

[ElGuerrero91]

Hi,

I’m experiencing a consistent issue with the STM32 Motor Control SDK:

• The first motor start attempt always fails with a MC_SPEED_FDBK fault
• After acknowledging the fault, the second (or further) start attempts work perfectly

Observations:

• During the first start, there is no audible motor movement
• Current signals (I_q_ref / I_q_meas) look misaligned or not properly regulated
• After the first failed attempt, signals stabilize and the motor starts normally
• The MC state is initially IDLE
• Fault reported: 0x0020 (MC_SPEED_FDBK)

Observations:

• During the first start, there is no audible motor movement
• Current signals (I_q_ref / I_q_meas) look misaligned or not properly regulated
• After the first failed attempt, signals stabilize and the motor starts normally
• The MC state is initially IDLE
• Fault reported: 0x0020 (MC_SPEED_FDBK)

It seems like something is not fully initialized/calibrated on the first start, possibly:

• Current sensing / ADC offset calibration

My Setup:

SW in Release Mode

Target: Custom Board based on EVSPIN32G4 Schematic (EVSPIN32G4)

Chip: STM32G431VBx3. 

MCSDK 6.4.1

FOC / Sensorless

[GMA]

Hello @ElGuerrero91,

Did you enable the driver protection on the MCU side to check the nFAULT signal (see STSPIN32G4 document, PE15 input)?

VDS monitoring can trigger the nFAULT signal and prevent PWM generation. You can disable VDS monitoring by connecting the SCREF input to VDD.

[ElGuerrero91]

Hi @GMA,

I have enabled both Driver Protection and Overcurrent Protection in MC Workbench:

• DP: TIM1_BKIN1

• OVP: TIM1_BKIN2

After enabling both protections, I no longer get the speed‑feedback issue described earlier. Instead, I now consistently receive a DriverProtection fault during startup.

While debugging the firmware, I found the following behavior:

Right after powering the system by connecting the battery (power‑on reset), the DP Fault is set because the reset indication flag is set in the Status Register:

In my opinion, RESET Flag should not be included in the DriverProtection fault check. This flag simply indicates that the driver registers have been restored to their default state, and it does not represent an actual Driver Protection error.

I resolved the issue by clearing all driver faults during startup phase as descrined in stspin32g4.h

typedef struct
{
  uint8_t vccUvlo:1;    /**< If 1 the device is in VCC UVLO condition. While in VCC UVLO condition the device cannot drive MOSFETs*/
  uint8_t thsd:1;       /**< If 1 one voltage regulator is in Thermal Shutdown. While in Thermal Shutdown the device cannot drive MOSFETs*/
  uint8_t vdsp:1;       /**< If 1 the VDS protection triggered. Use STSPIN32G4_clearFaults() to make the device operative again. */
  uint8_t reset:1;      /**< If 1 the device performed a reset or power up. Use STSPIN32G4_clearFaults() to make the device operative. */
  uint8_t r1:1;         /**< Reserved. */
  uint8_t r2:1;         /**< Reserved. */
  uint8_t r3:1;         /**< Reserved. */
  uint8_t lock:1;       /**< If 1 the protected registers are locked and cannot be modified. */
} STSPIN32G4_statusRegTypeDef;