SVPWM signal seems wrong for some Sectors on MCWSDK 5.4.8

[Mateus P. Lourenco]

Hi guys, I'm new on this forum

I'm using the MCWSDK v5.4.8 to drive a custom control and power board on a big Hub motor (17" from YM) using hall sensors.
The simptom I'm facing is that every time I try to start the motor with a command as MC_ProgramTorqueRampMotor1 or MC_ProgramSpeedRampMotor1 the motor tries to start. It starts, turn for close to 1° and then abruptly stop right after.

I get a MC_SPEED_FDBK right after, because this event pulls lots of current from the power source. The power source protects it by cutting of the supply thus powering off the hall sensors.

While investigating the problem, we disconnected the phases wires and just connected the Hall connections to check the SVPWM signals for each sectors, by turning the motor by hand. We noticed that in some of the sectors, there is only one phase with a PWM signal while the other ones are either fully open (0% duty cycle) or fully closed (100% duty cycle) in a fashion that while one phase is open, the other is closed. I don't know if this behaviour is expected but I imagine that this is the cause to the overcurrent events.

The following contents are measures between phase output conection and GND
These consecutive sectors seems fine

But these following consecutive states, doesn't

The results is the following. Note that on these photos, the motor phase connections where connecte to the board and each phase was evaluated.

These are the SVPWMs beeing generated while the power sourcer is shutting down due the overcurrent. Thats why it has this downward shape.

We know that on the OFFSET_CALIB state, all three phases are on 50% duty for calibration. But as soon as they get different values from each other, the power supply stops powering the circuit thus lowering the SVPWM signal voltage (as shown on the last image).

We already checked the deadtimes for shorts, and the 500ns value we setted up is ok.

My question are:

Why are these 3 sectors signals looks like this? Is this normal?
Is there a API  handdler to control the BUS current? We have ICS on phases A and B.

[SRedd.5]

In your for loop i/10 will always be 0 as i is integer and when divided by 10 will always be 0. Please check that and you also not required to give in for loop you have to check if previous torque command is successful.

[Mateus P. Lourenco]

What is the best way to control the DC current using the ST MCSDK API? Is there a way that I can force a null vector state every time the DC current surpass a defined limit?

Also, why doesn't the SDK flags overcurrent? I mean, the only error that is returned is the "Speed feedback" due to the HALL shuting off due to the undervoltage. Why doesn't the Overcurrent triggers first?

[SRedd.5]

What is the best way to control the DC current using the ST MCSDK API? Is there a way that I can force a null vector state every time the DC current surpass a defined limit?

There is no DC current sensing in MCSDK according to me it is only the controller output current RMS you can sense, you have to derive the DC current from phase currents. Forcing NULL vector is nothing but make all your PWMs OFF.

Also, why doesn't the SDK flags overcurrent? I mean, the only error that is returned is the "Speed feedback" due to the HALL shuting off due to the undervoltage. Why doesn't the Overcurrent triggers first?

If you enable DAC then it will trigger the overcurrent ensure the DAC is enabled and correct value is set.