Significant IqREF jumps while motor running

[DMeie.2]

We're having following issue with our motor control:
The motor is running fine, however one can hear irregular "hickups" in the regulated speed.

We did some tracing and found that the IqREF value has a significant jump up (~20A) and then back down after a few samples.
The motor RPW (not visible on the chart) drops down and then goes back up.

The hall electrical angle looks fine so it should not be related to that.

What could cause a behaviour like that?
This doesn't depend on the motor load nor requested speed.

MCSDK Version is 6.2.1.

[DMeie.2]

Looks like the issue is related to the speed calculation.
When I run the motor in torque mode, the motor runs perfectly fine, however the traced hall speed still shows the drops.HALL_SPEED drop while the motor is running perfectcly fine

[GMA]

Hello @DMeie.2,

Could you please specify the ST platforms used?

[DMeie.2]

The hardware is a custom one running on a G431RBT, loosely based on the STEVAL-ESC001, with a DRV8323RS as the gate driver and for current sense conditioning.

[GMA]

Hello @DMeie.2,

Could you provide your .stwb6? If not, could you please provide the list of used features (MTPA, Feed Forward, Flux Weakening, ...)? If one or several of these features are used, please consider using the MCSDK6.3.0 version, an issue around IqRef computation has been corrected.

Another question, disconnecting Motor Control Pilot tool, do these "hickups" disappear?

[DMeie.2]

@GMA 
We managed to trace the issue back to the Hall speed measurement.

I added some code inside hall_speed_pos_fdbk.c to write the values captured by the timer into a buffer.
Now when I run the motor in torque mode at a constant speed, I stop updating those values when the glitch appears.
It seems that some weird captures are happening (this shows the values of wCaptBuf before they go into the speed FIFO):

Blue line shows where the glitch happens, this value gets filtered out by some code (Commented "Filtering too fast speed... could be a glitch ?", fittingly).
Three captures after that (it is always three captures) theres a value that's slightly off compared to the others, this one causes the visible jump in the speed measurement and regulation.

I did many tests at various speeds, it always looks like that.

I also recorded the values that directly come out of the Timer capture register (this is the same event as above):

Again visible at the blue line the appearance of the glitch (why is the timer capture compare register returning zero?), and three captures after that a value that's off compared to the others.

The hall signals going into the controller look clean, but we will do further tests to confirm this is not a hardware issue.

 

I attached the .stwb6 file. It is a bit outdated as the Motor and Power Supply values have changed, and the Speed Sensing has been set to Hall as main and Observer + Cordic as Auxiliary, but the rest is still correct.
None of the mentioned features are used in this project.
The "hiccups" also occurr with the Motor Pilot (or any debugger) detached.
The device itself is controlled over FDCAN1 in normal CAN-Mode (not FD) on PB8 and PB9.

[GMA]

Hello @DMeie.2,

If your FDCAN1 feature uses interrupts, could you check that these interrupts have a lower priority than HALL Timer Interrupt (on NVIC IP, higher is the "Preemption Priority" value, lower is the priority level).

[DMeie.2]

It has a higher priority than the timer (which it really doesn't need, I agree). I'll see about changing the priorities.

In the meantime, we increased the filters on the hall signals, and it seems like the glitch is actually gone now.
It wasn't possible for me to actually see the glitch on the signal lines as it didn't appear when I probed it with the oscilloscope.

We'll do some further testing and I will report back with the results.