Strange behavior of PWM

[JWilk.1]

Hello,

​

I​ am observing a strange behaviour of the first few PWM pulses after a change in duty cycle. I use HAL_TIM_PWM_Stop, HAL_TIM_ConfigChannel (with the changed Pulse) and then HAL_TIM_PWM_Start. What happens is that for around 1 millisecond the pulses are with a strange form (see attached file). If I directly change the CCRx register there is no problem. I try to understand what is happening.

​

MCU used - STM32F429.

​

Best regards,

John​

[waclawek.jan]

> If I directly change the CCRx register there is no problem

Then why don't you do just this?

Cube/HAL is open source, if you desire to use its functions, you can check their functionality yourself.

JW

[JWilk.1]

I want to understand why does issue happens. If I do CR1.CE=0, change the CCR register and then CR1.CE=1 I notice that behavior. Similarly, if I unset the CCxE bit before changing the CCR and the set it again the same happens again. I am interested to know what causes that but could not find anything in the reference manual. OCxPE is set to 1 which means that the CCR will be updated on the next update event but that behavior is observed for more than an update event (PWM freq is 32 kHz).

​

Regards,

John​

[waclawek.jan]

John,

I don't quite understand what are we seeing on that picture.

What re the settings per division? How is the expected waveform different from this? Don't we see some aretefacts of the oscilloscope, e.g. missing trigger source? Do you measure directly on the mcu's output pin? Is grounding consistent? Which timer are we talking about, which mcu, on what hardware?

Please note, that both clearing CR1.CE and clearing the respective CCER.CCxE effectively threestates the respective pin, and then it may pick up noise from neigbouring pins/tracks.

You may also want to read out and post the TIM registers' content.

JW

[JWilk.1]

Hello Jan,

​

I​ am uploading a picture when the change of the pulse (from 0% to 99% duty cycle) is done by writing the CCR register without unsetting CEN and CCxE bits. As you can see the pulses are consistent from the beginning. The timer that I am using is TIM3 CH4 on pin C9 (99). I am measuring it directly on the MCU pin. As for the registers, there is nothing special - PWM mode 1, OCxPE set to 1 and the respective values for prescale, ARR and CCR. I measured the pin when CCxE and CEN are cleared and there was no noice on the PC9 pin. Strangely, if I add a 1 ms delay before setting CEN and CCxE, the issue does not happen. I have also tried to add isb before starting the PWM but without any effect.

​

​Regards,

John

[waclawek.jan]

Does the problem happen with other CCR values as well (eg. switching between values both around 50% duty)? Is there anything connected to PC9? Is this the only code there? If no, write a minimal program which exhibits the problem. If this is your hardware, try to run it on a "known good" board such as Nucleo or Disco.

JW

[JWilk.1]

Hello Jan,

​

The problem happens with 50% duty cycle as well. I have run it on a STM32F429ZI Nucleo-144 board. What I did is to modify the project provided by ST (Projects/STM32F429ZI-Nucleo/Examples/TIM/TIM_PWMOutput) and modified the code by adding the duty change insinde the while (1) loop in the main(). The PWM signal is measured on the PB1 test point. I am attaching 2 pictures​ - one by directly changing the CCR and one with stopping the PWM before changing the CCR.

​

B​est regards,

John​

[JWilk.1]

Sorry, only one picture got uploaded. Here is the picture when ​the PWM is stopped before changing the duty.

[waclawek.jan]

> The PWM signal is measured on the PB1 test point.

What is "PB1 test point"?

Above you said, " The timer that I am using is TIM3 CH4 on pin C9 ", how does that relate to PB1?

The waveform you've posted looks like a collision with some other signal source, possibly external to the STM32.

JW

[JWilk.1]

Hello,

​

I used pin C9 on a different hardware. Today I tested on a Nucleo board as you suggested and there the pin that was multiplexed for TIM3 CH4 is B1 (I wanted to keep the demo application without many changes). As for the "test point", I meant the ST morpho connector. Excuse me for not using the correct terminology.

​

Regards,

John​

[waclawek.jan]

Can you please post a minimal but complete compilable code exhibiting the problem, to be possibly reproduced elsewhere?

Ideally, if you can get rid of Cube/HAL, using registers directly.

JW