0
\$\begingroup\$

Is is possible to disable an interruption during its service routine to prevent it from happening again for some time?

For example:

void TIM2_IRQHandler(void)
{

    if(TIM_GetITStatus(TIM2,TIM_IT_CC1) !=RESET)
    {
        //(some code)

       **TIM_ITConfig(TIM2,TIM_IT_CC1,DISABLE);**
       TIM_ClearITPendingBit(TIM2,TIM_IT_CC1);
    }
}
\$\endgroup\$
3
  • 4
    \$\begingroup\$ Yes. Have you tried it? \$\endgroup\$
    – Eugene Sh.
    Jan 13 '16 at 21:04
  • \$\begingroup\$ Yep, and it doesnt work, the code inside this interrupt function doesnt execute. Nevermind, i will try to find out on my own. Thanks for replying. \$\endgroup\$
    – karollo
    Jan 13 '16 at 21:17
  • 1
    \$\begingroup\$ Of course it doesn't execute if you have disabled it - isn't that what you wanted? \$\endgroup\$ Jan 13 '16 at 21:28
2
\$\begingroup\$

Yes, you can disable the interrupt source inside the interrupt you're handling.

This is actually a quite common procedure in things like USARTs, that may have interrupts like "TX buffer empty". The interrupt is fired when the software needs to load a new byte. It may check if a (circular) buffer has any remaining bytes. If not, the software needs to disable this interrupt, otherwise the hardware would keep requesting the interrupt for new bytes. Effectively creating an infinite loop (as the "Pending Bit" is immedetialy SET by hardware again) leaving no CPU time for the application.

However, re-enabling the interrupt "after some time" doesn't happen by itself. You could use another timer for this, to create the delay you want. Or write a state machine of some sort inside the timer if you want to use the same time base/phasing. Another solution is to re-enable the interrupt from the main code. To iterate further on the USART example: the software (e.g. 'main' code) can re-enable the TX-empty interrupt once it has a new buffer loaded that needs to be sent.

\$\endgroup\$
0
\$\begingroup\$

you should always clear the pending interrupt that cause the interrupt service routine to be run, in the interrupt service routine. Ideally start at the peripheral that caused the interrupt and clear toward the cpu if there are multiple places where it is latched.

not always possible, but a good idea to understand the generation and clearing of the interrupt using polling first because that is way easier, then once all understood then do the last enable to allow the cpu to see the interrupt and call a handler, still debugging required for that but fewer things to derail you at that point.

whether or not leaving the interrupt asserted and returning causes another immediate or one instruction later interrupt depends on the system design, but it can and does happen on some designs. Likewise if there is an additional exception that happened while the logic was switching over to the interrupt or you were handing the interrupt, that might not re-interrupt you, before exiting the interrupt handler you need to poll the peripheral and handle any other events, repeat until there are no more events then exit the handler (for events that share an interrupt line into the cpu).

for a timer which is perhaps what you are asking about. clear the interrupt at the timer and other latches toward the cpu. if the timer requires another action to re-start another time period this would be the time to do that as well. if it automatically keeps going into the next time period and you just need to clear the interrupt to get another, then you do that here in the handler.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.