timer problem at low period value

[ionutF]

Posted on March 21, 2016 at 15:46

MCU: STM32F100C6T6 ; clocks: 12MHz external

sysclk=hclk=pclk1=pclk2=12MHzI have configured TIM16 as follow TIM_TimeBaseStructure3.TIM_Period = 5;// TIM_TimeBaseStructure3.TIM_Prescaler = 12-1;// TIM_TimeBaseStructure3.TIM_ClockDivision = 0; TIM_TimeBaseStructure3.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM16, &TIM_TimeBaseStructure3);in TIM16 interrupt a GPIO pin is toggled. It seems i can't get on scope waveforms smaller than ~ 20 microseconds, i was expecting 5 microsecondsBut if i put Period=100 ( ARR register) i get 100 microseconds as expected; the period seems to the right one for period values bigger than the prescaler. valueAre there problems with timers at low period value

[Tesla DeLorean]

Posted on March 21, 2016 at 16:27

Are there problems with timers at low period value

Basically that interrupting at ridiculously high rates saturates the processor, so don't do that. If you want a timer to toggle a pin, let the TIMER do that, using say Toggle or PWM modes.The ceiling on your part at this speed is perhaps a few hundred KHz, depending on how many instructions/clocks your code and the context switch take. Remember that this will still burn instructions doing useless work, and reduce those available for your other code to do meaningful work.

[ionutF]

Posted on March 22, 2016 at 14:29

I forgot to mention that the main loop is just an infinite while(1){}; In interrupt the code is not complex, just toggle the pin. 

The code is more complex that that but I deactivated it when I had observed the timer  odd behaviour, but no change occured ; I still  cant get toggle periods smaller than ~20usecIm using the toggle method for debugging my code, I m not actually trying to make that pin toggle. Is the MCU saturated in this conditions, with (allmost) no code to run?In which conditions can I get the timer output the right count number using toggle?

[Tesla DeLorean]

Posted on March 22, 2016 at 14:53

The timer settings in your example fires every 72 instruction cycles.

Suggest you look at the cycles eaten by the context change, and for the assembler, and bus read/writes of the generated code.You're not running fast enough to need flash wait states, but these will drag down most F1 designs.