TIM2 interrupt behaviour

[fshah48]

Posted on March 23, 2017 at 13:47

I am using TIM2.CH2 input compare. No other interrupts are activated except TIM2.CH2. In TIM2_IRQ handler all IC bits except CH2 are set. Why?

Using STM32Discovery on IAR. I expect TIM2_IRQ to fire up on trigger from outside. It does but CH2 interrupt ic leared and all other 3 IC interrupt bits are SET. Why?

[Tesla DeLorean · Accepted solution]

Posted on March 23, 2017 at 14:15

The register is just a latch of occurring events, it is gated with the Interrupt Enable to create physical interrupts, but you don't need to enable them for the latch to function.

[waclawek.jan]

Posted on March 23, 2017 at 14:17

Similar

https://community.st.com/0D50X00009Xkg8cSAB

[fshah48]

Posted on March 24, 2017 at 12:48

Well, I need to get interrupt to react. I also tried following:

TIM_GenerateEvent(TIM2, TIM_EventSource_CC2); from SysTick interrupt

handler to generate TIM2.CH2 IC interrupt. TIM2 interrupt responds but

CC2IF is cleared in TIM2-SR. All other capture bits are set.

Another surprise is that TIM2.PSC is set to 0 when I expressly set it to 3.

/* Time base configuration */

TIM_TimeBaseStructure.TIM_Period = 0xFFFF;

TIM_TimeBaseStructure.TIM_Prescaler = 3; // divide by 4

TIM_TimeBaseStructure.TIM_ClockDivision = 0;

TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up;

TIM_TimeBaseInit(TIM4, &TIM_TimeBaseStructure);

All these code snippets are imported from examples you provide.

Please help.

On Thu, Mar 23, 2017 at 6:17 PM, waclawek.jan <

[Tesla DeLorean]

Posted on March 24, 2017 at 14:22

Code shows you configuring TIM4 not TIM2

TIM_TimeBaseInit(TIM4, &TIM_TimeBaseStructure); // Not TIM2

[fshah48]

Posted on March 24, 2017 at 20:16

Clive

I hurriedly added timebase code init from the example though it was not

needed for IC as per the example. BUT debugger still shows CC2IF clear and

other 3 CCxF's SET.

Now after steeping through the code it passed the CC2F as SET even though

debugger say RESET.

Moral: Do not test the data shown in debugger, look more carefully. It

works. Matter is resolved for now. However, it is an IAR workbench issue.

On Fri, Mar 24, 2017 at 6:23 PM, Clive One <st-microelectronics@jiveon.com>

[S.Ma]

Posted on March 25, 2017 at 17:10

Sometime, when trying to debug around peripheral register behaviour, if we display these registers in the debugger window, we have to remember that the debugger will do a read access to these registers and could clear some of the flags instead of the embedded FW... 

[Tesla DeLorean]

Posted on March 25, 2017 at 22:14

The debugger can be invasive, frequently when you most need it to be right it interferes with register content due to interactions between register bits. It works much better with memory views, so ideally place things you want to monitor in global variables, or structures, that you can examine with the Memory View, and close out the Peripheral View(s)

Outputting data via SWV or USART channels can also be helpful when flow/interactions are of interest, and time/sequence sensitive.

[fshah48]

Posted on March 26, 2017 at 11:10

Hello

Thank you all for timely response. As it turns out it is a debugger issue

and one needs care to use peripheral view while debugging.

My Issue stands resolved.

On Sat, Mar 25, 2017 at 9:11 PM, KIC8462852 EPIC204278916 <