TIM3 OC problem

[n.serina]

Posted on April 17, 2018 at 10:00

Hello , 

I am using NUCLEOf446re board and i have some issues with TIM3 OC getting 50Kz waveform on channel 1 . 

when i derive systemclock from PLL . it works fine . 

systemclock = 180Mhz

APB1CLK = 45MHz

TIM3CLK = 90Mz 

prescaler of timer

= 9 

timer cnt clk = 9Mhz  ..

OC pulse value = 9000000/50000

this configuration work fine . 

but when i switch to HSI , the code doesnt work . 

in HSI i use the below config 

systemclock = 16Mhz

APB1CLK  = 16Mhz

TIM3CLK = 16Mhz

timer cnt clk = 16Mhz  ..

prescaler of timer = 0

OC pulse value = 16000000/50000.

this config doesnt work at all .  it just generated wave of ~122Hz . 

can you please help to debug the issue ?

#stm32f4-nucleo

[waclawek.jan]

Posted on April 17, 2018 at 10:09

Read out and check/post the content of TIM3 registers.

JW

[n.serina]

Posted on April 17, 2018 at 14:44

Thanks for the reply . here is a screenshots of register details . 

[waclawek.jan]

Posted on April 17, 2018 at 18:23

There are multiple problems: ARR is 0xFFFF i.e. timer period is maximum possible; pulses lengths is also not what you described, and the output compare mode is Toggle not PWM.

As 16000000Hz/65536=cca 244Hz, with toggle mode it makes sense the output is 122Hz 50% pulse train.

This could not have worked at 50kHz at the PLL setting either.

JW

[n.serina]

Posted on April 18, 2018 at 19:31

 ARR is 0xFFFF i.e. timer period is maximum possible;

yes , ARR 

Is highest value possible , but the timer is configured to toggle the channel when it meets with CCR1 . and CCR1 is updated as below . 

/**

* @brief Output Compare callback in non blocking mode * @param htim : TIM OC handle * @retval None */void HAL_TIM_OC_DelayElapsedCallback(TIM_HandleTypeDef *htim){ /* TIM3_CH1 toggling with frequency = 195 Hz */ if(htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1) { uhCapture = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1); /* Set the Capture Compare Register value */ __HAL_TIM_SET_COMPARE(&TimHandle, TIM_CHANNEL_1, (uhCapture + uhCCR1_Val)); } }

it is indeed working with PLL . you can see the output below pll vs HSI 

[waclawek.jan · Accepted solution]

Posted on April 19, 2018 at 00:29

Ah, that's because with the much slower system clock the time between the output compare and the moment when you change CCR1 is longer than

uhCCR1_Val. In other words,

at the moment when you change CCR1, CNT is already higher than the new CCR1 value, thus the compare happens only when CNT overflows and reaches the value in CCR1 again.

JW

[n.serina]

Posted on April 19, 2018 at 12:25

ohh . got it ! i never thought that way . Thanks for all your replies