cancel
Showing results for 
Search instead for 
Did you mean: 

TIMER7 INTERRUPT FLAG NOT CLEARING

mehmetcanbalci
Associate III
Posted on October 30, 2011 at 19:12

Hello,

I have one problem about clearing timer7 interrupt flag at different timer clock prescaler,

void TIM7_IRQHandler(void)

{

  if (ih == 0)

  ih=1;

  else

  ih=0;

TIM7->SR  = 0x0;

}

I m setting APB1 presclaer value 2 , timer7 prescaler 0x1FF .With this configuration TIM7->SR  = 0x0; command working properly and clearing UIF flag.

But if i choose Apb1 prescaler like 16 ,same command is not clearing UIF flag ,i should write 3 times same code or i should clear and read (TIM7->SR  = 0x0; and x= TIM7->SR ;).Why does it not clear flag in higer APB1 prescaler value? Is there any relation between pulsewidth of interrupt signal and cpu core clk frequency? 
9 REPLIES 9
infoinfo989
Associate III
Posted on October 30, 2011 at 21:58

How do you know the IRQ flag is not clearing? Is it because you see the interrupt occur a second time? Remember this is a pipelined processor - if you're exiting your interrupt service routine immediately after clearing the IRQ bit, the bit clear operation might not have had sufficient time to propagate through. Try putting:

  while (TIM7->SR  != 0x0);

or similar at the end of your interrupt service routine.

infoinfo989
Associate III
Posted on October 30, 2011 at 22:00

Or alternatively, put the line:

  TIM7->SR  = 0x0;

at the beginning of your interrupt service routine instead of at the end.

mehmetcanbalci
Associate III
Posted on October 31, 2011 at 14:04

Im clearing interrupt flag but it is reentering at the end of the interrupt routine again and again,if i write a few commands before exiting from interrupt routine ,it is working. 

Posted on October 31, 2011 at 14:55

Im clearing interrupt flag but it is reentering at the end of the interrupt routine again and again,if i write a few commands before exiting from interrupt routine ,it is working.

Re-entering a second time is the pipeline/write-buffer problem, the system can't clear the interrupt quickly enough before the tail-chaining decision is made. Check the source, clear it early, do your work, leave.

If you don't clear the right source, the Cortex M3 will stay in interrupt state indefinitely.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
infoinfo989
Associate III
Posted on October 31, 2011 at 16:33

Did you try either of those 2 code changes I suggested?

Posted on November 01, 2011 at 01:53

I think he tried the first one, or at least attempted. The second looks to be a potential bear trap, especially if the routine over-runs with more code stacked in front of it.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
mehmetcanbalci
Associate III
Posted on November 01, 2011 at 08:23

void TIM7_IRQHandler(void)

 

{

 

TIM7->SR  = 0x0;

 

   if (ih == 0)

 

   

ih=1;

 

   else

 

   

ih=0;

 

 

}

 

I tried by this way , but it is not working,i think there is less command and because it is not working.

mehmetcanbalci
Associate III
Posted on November 01, 2011 at 08:26

Could you explain , what is bear trap ,i couldnt understand.

Posted on November 01, 2011 at 14:40

Could you explain , what is bear trap ,i couldnt understand.

http://tvtropes.org/pmwiki/pmwiki.php/Main/BearTrap

The following is a very nasty trap for the unwary :

while(something);

If you merely check a condition without providing a clear mechanism to exit your system will lock-up. For instance checking an interrupt status within an interrupt. This may not have been Frank's intention, but the placement of the semi-colon immediately after the while() is problematic.

Anyway, you're going to need to provide far more code for people to replicate what you're attempting. If your interrupt rate is too high, you will simply saturate the processor.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..