General purpose timer - time base implementation

[isaac]

Posted on July 01, 2014 at 06:29

STM32F101R8 is running at 36MHz off its internal clock. One of its three general purpose timers, TIM4, aims to generate four different time based interrupts.

These should be proper internal time base design, without any hardware signals are involved - neither as inputs or outputs.

The design is to use the 36MHz as the driving clock, divide it by the TIM4_PSC = 0x00FF and get a 7.11 uSec timer clock.

Then, by using TIM4's four CCRx registers - getting the 4 required delays from the time that TIM4 started its run.

I must be missing something, either within the TIM4 understanding or within its programming, as the fired interrupts' delay is completely different than expected.

Also, CCxIF bits within SR register never indicated which of the 4 events had occurred, actually SR=00 so it's not really clear what triggers TIM4's interrupt.

TIM4 registers are configuration after reset:

    TIM4->PSC = 0x00FF;

    TIM4->CCR1 = 0xBBBB;

    TIM4->CCR2 = 0xCCCC;

    TIM4->CCR3 = 0xDDDD;

    TIM4->CCR4 = 0xEEEE;

    TIM4->EGR  = 0x001E;

    TIM4->CCMR1|= 0x0B0B;

    TIM4->CCMR2|= 0x0B0B;   

    TIM4->DIER = 0x001F;  

   TIM4->CCER = 0x0000;

    TIM4->CR1   = 0x0288;   

    TIM4->CR1  |= 0x0001;

Any support here?

#timer-stm32f101r8-timebase

[Tesla DeLorean]

Posted on July 01, 2014 at 22:31

I have minimal interest is working through the register level minutia here, perhaps you can do it using the standard library?

I would check if TIM4->ARR is actually 0xFFFF, and the clock source is really 36 MHz With CCR1 at 0xBBBB, I think you should be at 341.75 ms for the first interrupt, and the next 466 ms (2.145 Hz) after that if you don't advance CCR1. Remember also to clear the interrupts with a single mask write to TIM4->SR not an RMW form, ie TIM4->SR = ~CC1IF and not TIM4->SR &= ~CC1IF If you don't advance CCR enough you'll end up with a 466 ms delay as the timer wraps. Figure you need to advance it a hundred cycles or so to avoid the interrupt handling latency and processing.