Very poor current measurement when not sampling mid-PWM period

[11235813]

STM32F405

MCSDK = V5.4.5

f_pwm = 10kHz

High frequency task = 10kHz

Medium frequency task = 1kHz

Position and speed = Hall (main) & STO+PLL (auxiliary)

Current sensing = 3 x 3mOhm shunts

I am having a problem with very poor Id and Iq measurements when the motor hits a certain critical speed, around 650rpm mechanical with no load. 

Fig1 shows plots of Iq, Id, RPM, Electrical angle (hall and sensorless) and BEMF generated by printf-ing out the values in the Medium frequency task using Segger RTT. Fig2 is the same plot but zoomed in on the "good" region. Fig3 is zoomed in on the "bad" region.

I have traced the transition between "good" and "bad" to when the R3_2_SetADCSampPointSectX() function in r3_2_f4xx_pwm.c stops sampling in the middle of the PWM period and uses one of the alternative schemes. Here are some of the defines that I believe are of interest here:

#define TNOISE_NS        1000

#define TRISE_NS         1000

#define MAX_TNTR_NS TRISE_NS

#define LOW_SIDE_SIGNALS_ENABLING    LS_PWM_TIMER

#define SW_DEADTIME_NS         120

#define PWM_FREQUENCY 10000

#define PWM_FREQ_SCALING 1

I've also run a test with exactly the same motor and setup but with an alternative non-MCSDK based motor controller and this is shown in Fig4. This test does not exhibit the same problem and runs fine at over 700rpm with a much smaller variance in Iq and Id. I think this means we can rule out any issue with the motor or Hall effect sensors. 

Can anyone point me to what might be the problem here? 

Why might the alternative current sampling techniques be so much worse? 

Is it expected that the variation in Iq and Id measurements be so large (+/-2.5A)?

EDIT:

I'm adding a link to this question (not answered yet unfortunately) which seems to describe the same problem:

https://community.st.com/s/question/0D53W00001MzfPjSAJ/can-someone-tell-me-what-tnoise-and-trise-are-in-the-current-sensing-block-of-the-motor-control-workbench

[11235813]

In the generated parameters_conversion_f4xx.h file there are the following defines:

/************************* CPU & ADC PERIPHERAL CLOCK CONFIG ******************/

#define SYSCLK_FREQ   168000000uL

#define TIM_CLOCK_DIVIDER 1

#define TIMAUX_CLOCK_DIVIDER (TIM_CLOCK_DIVIDER)

#define ADV_TIM_CLK_MHz 168/TIM_CLOCK_DIVIDER

#define ADC_CLK_MHz  21

#define HALL_TIM_CLK  84000000uL

These drive the timing of lots of aspects of the code, but it looks wrong to me. The APB1 clk is 42MHz and the APB2 clk is 84MHz, so I think this file should be:

#define SYSCLK_FREQ   168000000uL

#define TIM_CLOCK_DIVIDER 2

#define TIMAUX_CLOCK_DIVIDER (TIM_CLOCK_DIVIDER)

#define ADV_TIM_CLK_MHz (168/TIM_CLOCK_DIVIDER)

#define ADC_CLK_MHz  84

#define HALL_TIM_CLK  84000000uL

Not sure if this fixes the problem yet, but it looks like a bug to me.

[11235813]

The result is a lot better with the clock defines changed. However the current sensing is still very poor when not using mid-PWM period sampling

[GMA]

Could you confirm that you are using SDK V5.4.5?

What are the used "STM32CubeMX version", "Firmware Package version" and the "drive type"?

Which power board are you using?

[11235813]

Yes, I'm using V5.4.5. I inherited the project so I don't know those details, are they available in the code somewhere? The board is our own design.

[11235813]

I have actually traced the problem to the PWMC_SetPhaseVoltage() function in pwm_curr_fdbk.c. It seems that in this function the lowDuty and highDuty signals are reversed, so:

highDuty < midDuty < lowDuty

I swapped them around for each of the sector cases and now the current measurement is a lot better.

[GMA]

Thank you for your feedback.

[11235813]

Can you please comment on whether you agree with what I have said about clock frequency defines and lowDuty v highDuty? There is no real documentation for the code so I'm trying to piece together how it is supposed to work. Clearly it isn't working properly for me so I'm making changes which seem to make things better but may not be the correct way to fix the problem or may introduce other problems. I also have a support request with ST on this issue but I've had no response to that either.

[GMA]

A remark, I made a test on my side, and swapping low and high duty, it implies that the first if of R3_2_SetADCSampPointSectX() will be always true and sampling will be always done in the middle of the PWM period. Do you have such behavior? If yes, it means that Tafter is too high an current is still correct on these timings...

[11235813]

Does lowDuty refer to the lowest duty phase for low side or high side? It seems to hold the value for the high side duty but actually the variable might refer to the low side duty. So the variable might actually be called:

high_side_duty_for_lowest_low_side_duty

Then it would make sense for:

high_side_duty_for_lowest_low_side_duty > high_side_duty_for_mid_low_side_duty > high_side_duty_for_highest_low_side_duty