TIM flags automatically set when TIM enabled

[rachit]

Posted on June 19, 2013 at 16:16

Hello,

I am facing a problem with the timers I am using in STM32f100 MCU. I have configured different timers to operate during the execution of the code, but somehow, all the flags related to Capture/compare or Update in the SR are set as soonas I enable the timer. As I read in the datasheet, they are all set in the hardware, and even if I clear them manually in debug mode, they are set again immidiately. My configuration for TIM3, for example, does not need any CC functionality, though i do use it in other timers. But considering that I need TIM3 only for generating a time base, I still dont understand why should the CC flags in SR be set. Below is the snapshot where I enable the TIM3 and the flags are set. The configuration for TIM3 is as follows, void TIM3_config(void) {     TIM_TimeBaseInitTypeDef  TIM_TimeBaseStructTIM3;     NVIC_InitTypeDef NVIC_Init_TIM3 = {TIM3_IRQn, 2, 1, ENABLE};     RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM3, ENABLE);     TIM_TimeBaseStructTIM3.TIM_Period = 0x75A0;     TIM_TimeBaseStructTIM3.TIM_Prescaler = 1;     TIM_TimeBaseStructTIM3.TIM_ClockDivision = TIM_CKD_DIV4;     TIM_TimeBaseStructTIM3.TIM_CounterMode = TIM_CounterMode_Up;     TIM_TimeBaseInit(TIM3, &TIM_TimeBaseStructTIM3);     /* TIM IT enable */   //    TIM_ClearFlag(TIM3, TIM_FLAG_Update);     NVIC_Init(&NVIC_Init_TIM3);     TIM_ITConfig(TIM3, TIM_IT_Update, ENABLE); } If you have any ideas where I should start looking for the problem, it'll be very helpful to progress in my work. #me-too

[jgpuech]

Posted on January 19, 2014 at 16:16

Hi, 

 I see the same ''strange'' automatic setting of TIM3->SR to 0x1F even after clearing IT flags.I tried many things but I don't find the solution.Is TIM_OCIdleState involved ?Anyway, I always see those flags rising, locking me into the IRQ Handler.Do you managed fixing it ?

[Tesla DeLorean]

Posted on January 19, 2014 at 16:59

I'm not sure them being asserted is quite the same as them generating an interrupt, as that is masked by the enable bits.

If you look at them in a debugger, the machine is not running in real-time. Something interrupting a few 100 times a second is not practical for a human to process. If the CPU is constantly in the interrupt routine one should perhaps look at the prescaler/period values, and if they are impractically frequent. Perhaps showing the code that causes the issue would enable a better analysis?