Problem with Timing

[durgesh777]

Posted on January 04, 2012 at 14:56

PROBLEM: Timer interrupt is entered immediately in the beginning and not in the desired timing period.

The objective is to enter a service routing of TIM4 with a timing of every 10 sec, clock is 72Mhz:   TIM_TimeBaseStructure.TIM_Period = 65535;   TIM_TimeBaseStructure.TIM_Prescaler = 39999;   TIM_TimeBaseStructure.TIM_ClockDivision = 1;   TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up;   TIM_TimeBaseInit(TIM4, &TIM_TimeBaseStructure);   // OCMode Active configuration: Channel1   TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_Active;   TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable;   TIM_OCInitStructure.TIM_Pulse = 18000;   TIM_OCInitStructure.TIM_OCPolarity = TIM_OCPolarity_Low;   TIM_OC1Init(TIM4, &TIM_OCInitStructure);     // interrupt on update   TIM_ITConfig(TIM4, TIM_IT_Update, ENABLE);   TIM_OC1PreloadConfig(TIM4, TIM_OCPreload_Enable);   TIM_ARRPreloadConfig(TIM4, ENABLE);     // TIM4 enable counter    TIM_Cmd(TIM4, ENABLE); The interrupt service routine is entered immediately after the beginning and not after 5 seconds. I would be happy if someone could help me on this. #dividers-and-prescaler-division #tim-problem #know-thy-tools

[Tesla DeLorean]

Posted on December 27, 2013 at 14:47

So, I have finalized my 7-8 hours of digging code with the following summary:

''do not trust the results in DEBUG mode if you are working with timers 🙂 ''

Yes, and I think that extends beyond timers, the debuggers are far more invasive than most assume, especially when using peripheral viewer which alter internal states. Definitely with timers, or other things occurring more rapidly than a human can react, grinding to a halt in a debug window waiting for manual interaction is about the last thing you want to do to understand the behaviour of a dynamic, real-time system.