STM32GO controller PWM Generation issue

[Denial1]

Hello All

Current Device setup:-

NUCLEO-G071RB Eval board

STM32CubeMX settings please find the attached screenshots.

• I'm trying to generate PWM signal using [ TIM3 channel 3] in NUCLEO-G071RB Eval board.

• Time period is 28 microseconds and width are 3 microseconds.

• As you can see in the below [image 1 ]only the first pulse is different or corrupted, which gives 32 microseconds time period and width are 7 microseconds .

• From the second pulse , we are able to get the expected pulse as shown below [image 2] Time period is 28 microseconds and width are 3 microseconds.

• Same behaviour is observed in STM32Cube_FW_G0_V1.6.0 package code, given by STM32 Timer PWM output example code.

Please provide the solution to resolve this issue.

 

Image 1:-

 

Image 2:-

 

[Sarra.S]

Hello @Denial1, 

Are you overwriting the CCR register directly? Have you seen this behavior after changing the pulse width from 7us to 3us?

[Denial1]

Hi @Sarra.S 

I'm using HAL library function to start the PWM

HAL_TIM_PWM_Start_IT(&htim3);  and

HAL_TIM_PWM_Stop_IT(&htim3) to stop the PWM.

[Sarra.S]

Hello again @Denial1, 

I am afraid I couldn't reproduce the issue using the example of the STM32Cube_FW_G0_V1.6.0 package. 

So, could you please specify the sequence to reproduce it; have you changed the PSC register value? I am thinking that during the first timer period timer works with another PSC from previous configuration

[TDK]

Probably the first pulse starts before the timer is started.

A solution would be to set the CNT of the timer to a value which produces a low state on the pin, rather than a high state. Perhaps set to ARR-1 instead of 0 during initialization. Or otherwise ensure the output state is low during initialization.

[Denial1]

Hi @TDK 

I have attached screenshots of STM32cubemx settings. Please look into this.

[waclawek.jan]

@Sarra.S,

From the waveform capture it's not clear whether the leftmost pulse was the first one after reset (and I am afraid it wasn't).

@Denial1,

CubeMX with Cube/HAL provides a quick clicking solution to generate PWM but perhaps does not pay much attention to details like this. If you want anything outside of what the Cube/HAL authors deem usual usage, Cube gets into way more than helps. TDK gave you above the explanation for your problem and also a suggested remedy, just follow his recommendation.

JW

[Sarra.S]

@Denial1 I apologize for the previous mistake. You're right @waclawek.jan!

I am tracking this issue with an internal ticket (Ticket 164283), I will keep you informed! 

Sorry for the inconvenience.

[Sarra.S]

Hello @waclawek.jan, @Denial1, @TDK, 

This behavior is now noted in Readme files of all HAL TIM examples calling HAL_TIM_PWM_ConfigChannel() with the output channel configured in PWM1 mode:

TIM_6Steps, 

TIM_Asymetric, 

TIM_CascadeSynchro,

TIM_Combined,

TIM_ComplementarySignals,

TIM_Dithering,

TIM_DMA,

TIM_DMABurst,

TIM_ParallelSynchro,

TIM_PrescalerSelection,

TIM_PWMOutput.

The note is the following: 

In this examples, the output channel is configured in PWM1 mode meaning that in up-counting mode, channel 1 is active as long as TIMx_CNT < TIMx_CCR1. As, in the function HAL_TIM_PWM_Start* function, the output channel is enabled prior enabling the timer's counter a timing difference might be observed on the first generated PWM. This difference corresponds to the delay - in term of number of CPU cycles - between the channel enable and the counter enable in the HAL_TIM_PWM_Start* function.

Thank you!