Timer Configuration for a PWM Scheme

[BoboyeOkeya]

Hi All,

I would really appreciate your input to this problem.

I am presently trying to implement the waveform "(a) PWM-ON" shown in figure below

It is for a 6step control algorithm, the STSW-SPIN32F0251 to be exact.

Here is the snapshot of the code that I have implemented for each step

This is the result that I am getting on the output timers that generates output PWM signals.

-->The yellow and green waveforms are the hall sensor input signals. All the three hall sensors signals have been XORed internally in my MCU into a single channel TI1.

-->The blue waveform is the gate signal to the high side of the first leg.

-->The pink waveform is the gate signal to the low side of the second leg.

A zoom in: Also here is an interesting picture showing the current waveform in pink color. The current decays to 0 between each step due to this delay problem

 

Now the problem that I would love you to help me with is this:

1. There is this delay between the signals on each gate signal waveform (blue and purple). It sort of makes sense since, I use the hall sensor signal edges (rising and falling) to indicate a step (1-6). so at each step, another pulse is produced on the same hall sensor interface timer to use in triggering the configuration changes in the output PWM timer for my gate drivers.
2. Hence it makes sense that there would be an initial delay, but after that there should be no delay as explained here in the manual RM0360

So how can I fix this delay?

I kinda think it could be a setting problem on the PWM timer - advanced timer 1. Maybe there is a setting to ensure the signals repeat and not get cleared until the next step.?

Thank you

[BoboyeOkeya]

Any hint or help would be really appreciated as I am still yet to solve this problem

[Javier1]

Your oscilloscope signals are flooded with noise :sad_but_relieved_face: .

I cant tell appart noise from signal , what about fixing that first.

Maybe that delay is a demagnetization spike?

If your motor stored a lot of energy during the pwm (the motor has high L or youre spinning it really fast), you sometimes get this demagnetization spike which is the time it takes to the magnetic field to colapse (enery stored in the coils).

https://vesc-project.com/node/1576

Or maybe you just badly implemented the steps

[BoboyeOkeya]

Hi Javier,

Please pardon the noises, I presently have a bad measurement system that cannot reject the noises perfectly.

But the Hall sensor signals are digital - HIGH or LOW.

I do not think its the demagnetization delay though.

But maybe I badly implemented the steps. And I think if I did, then the motor should not even spin at all.

Which is why I think it has to do with the timer settings. However I did notice something:

1. When I adjust the ARR and PSC values of the Hall sensor interface timer, the delay changes
2. However, the speed values calculated by the software is not exactly or even close to the one I measure with a photo-tachometer

[Javier1]

Make sure youre doing this step changes correctly, maybe youre switching off the pwm when you dont have to

the motor should spin but also make ugly noises.

Another idea, what if youre overflowing the variable you use to set the pwm cycle?

[BoboyeOkeya]

That is true, I have actually tried to verified that just now. And the steps are correct in correlation with the hall sensor signals status.

And yes true, the points you marked actually shows that both switches are off and its why the current is zero at those points you marked.

Since ive verified the steps, maybe this might be a cause I don't know:

1. when enabling the timer channels for each step, I needed to change the polarity of the two timer channels using a low-level library function:

 LL_TIM_OC_SetPolarity(((TIM_HandleTypeDef *) pMc->phf_timer)->Instance,LL_TIM_CHANNEL_CH1, LL_TIM_OCPOLARITY_LOW); //High Side

   LL_TIM_OC_SetPolarity(((TIM_HandleTypeDef *) pMc->phf_timer)->Instance,LL_TIM_CHANNEL_CH2N, LL_TIM_OCPOLARITY_HIGH); //Low Side

Maybe this could be a cause but it makes no sense to me

[Javier1]

what happens if you try to set the same polarity two times to the tim channel?

[BoboyeOkeya]

Hi Javier,

I have tried playing around with the steps, it still does not remove the delay. Also I dont think its the pwm duty cycle variable overflow goes even at low speed - equivalent to a small uint16_t value - the delay still exisits

[BoboyeOkeya]

you mean something like this right?

 case 1:

  { 

   MC_Core_LL_SetDutyCycleHfPwmU(pMc->phf_timer, PulseValue);

   MC_Core_LL_SetDutyCycleHfPwmV(pMc->phf_timer, 0);

    /* QUASI-SYNCHRONOUS RECTIFICATION BEGIN 1 */

   if (QUASI_SYNC_RECTIFICATION == 1) MC_Core_LL_EnableChannelsHfPwmsStep1(pMc->phf_timer);

   else MC_Core_LL_EnableChannelsHfPwmsStep14(pMc->phf_timer);

    /* QUASI-SYNCHRONOUS RECTIFICATION END 1 */

   LL_TIM_OC_SetPolarity(((TIM_HandleTypeDef *) pMc->phf_timer)->Instance,LL_TIM_CHANNEL_CH1, LL_TIM_OCPOLARITY_LOW); //High Side

   LL_TIM_OC_SetPolarity(((TIM_HandleTypeDef *) pMc->phf_timer)->Instance,LL_TIM_CHANNEL_CH2N, LL_TIM_OCPOLARITY_HIGH); //Low Side

   LL_TIM_OC_SetPolarity(((TIM_HandleTypeDef *) pMc->phf_timer)->Instance,LL_TIM_CHANNEL_CH1, LL_TIM_OCPOLARITY_LOW); //High Side

   LL_TIM_OC_SetPolarity(((TIM_HandleTypeDef *) pMc->phf_timer)->Instance,LL_TIM_CHANNEL_CH2N, LL_TIM_OCPOLARITY_HIGH); //Low Side

  }

  break;

[Javier1]

@BoboyeOkeya​ yes, show me what happens.

Another thing that will help you a lot is output the commutation steps trough the DAC so you can capture the steps signal along with your pwms with the oscilloscope. (the signal should look like a small 6 steps stair)