STM32F3: timer synchronization ARR change

[kpavlata9]

Posted on January 24, 2014 at 17:38

Hi,

I'm using TIM1 and TIM8 of STM32F3 to generate PWM signals. I'm using both of the timers in combined PWM mode so that I can get high frequency/high resolution center aligned 4CH PWM. Moreover I'm synchronizing the timers so TIM1 is a master and slave timer (TIM8) enables(starts counting) exactly with TIM1. This works fine, the CCR registers are filled with the same values so the generated signals are in phase (very small delay between master and slave timers, which is acceptable). The problem rises when I try to update the period (ARR) of the timers on the fly. ARR being preloaded, I disable the update event, change the ARR registers and enable update event in the interrupt form CC1 of one of the timers (so the enable happens far from timer overflow). I'd expect the signals to be in phase after the change of the frequency, but (at least for me) surprisingly the generated signals phase changes (no change to CC regs.). The phase change does not occur all the time and correlates with the change of period - i.e. signals from one timer delays or overtakes the others when the change in period is positive or negative. Any thoughts on solution and how this is happening? The PWM frequency is around 100kHz and the write to ARR comes once a 100ms). thanks, karel

[chen]

Posted on January 24, 2014 at 18:29

Hi

''The problem rises when I try to update the period (ARR) of the timers on the fly. ARR being preloaded, I disable the update event, change the ARR registers and enable update event in the interrupt form CC1 of one of the timers (so the enable happens far from timer overflow). '' You have already worked out that the ARR is buffered. ''I disable the update event'' You are fighting the mechanism that is meant to help you. Leaving the UpdateEvent enabled means that you can write to the ARR and let the hardware underneath work out when to use the new value. I have not tried the Master/Slave timer link but I would hope that when linked - the ARR values are also copied across synchronously. Hope this helps.

[Tesla DeLorean]

Posted on January 24, 2014 at 18:33

If you change the ARR in the Update interrupt, and you don't force an immediate load, then the value should be latched at the NEXT Update. A pair of timers should stay in lock step with each other.

If you do it at other times, you have to know how close CNT is to ARR (and a new lower value), and if you have a sufficient window to write to BOTH timers

[kpavlata9]

Posted on January 29, 2014 at 10:10

Hi, thanks for the answers.

I'm aware of the change being latched with the next update. So it seems the problem really is with the sufficient window as the problem occurs only after quite low values (low period) written to the ARR. Interesting thing is that after the problem manifests itself, it persists even after increasing the ARR value (so the window is definitely sufficient) and the phase changes with every new update to the ARR.Anyway, the solution to the problem which seems to work was:-setting the slave timer into combined reset-trigger mode, setting the ARR to max value (0xffff)-master timer TRGO output set to Enable, run the timer and then set it to Update.in this configuration the period of both timers is controlled by ARR of the master timer, there is slight, but deterministic phase delay between the timers which can be compensated for.my question: is this the Update generation through the slave mode controller feature mentioned in the Reference manual or is there any other way how to force the UEV to the slave timer? (without being reset through TRGO)thank you,karel

[chen]

Posted on January 29, 2014 at 11:38

Hi

'' is there any other way how to force the UEV to the slave timer? (without being reset through TRGO)'' You can force 'events' through the TIMx_EGR register. I do not know if this will cause the slave to update as well. Not sure which standard peripheral library function call that would be. '' I can get high frequency/high resolution center aligned 4CH PWM.'' ''The problem rises when I try to update the period (ARR) of the timers on the fly'' ''I'd expect the signals to be in phase after the change of the frequency'' I am not sure if the phase will always be the same in center aligned mode (but I admit I could be wrong about this).

[kpavlata9]

Posted on January 29, 2014 at 12:24

Hi, by forcing I meant automatically force UEV from master to the slave with no sw overhead.

the center aligned PWM is made artificially in this case, timer is only upcounting and the phase is controlled by CC registers. when the registers have the same value, phase difference means that the timers are not counting synchronously (at least that's what I think)