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?