AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable
        Hello. I have a question about AN60630, Guideline #2. I made three sample projects to evaluate the optimization. They are almost the same. A Counter block generates an interrupt every 500ms. When the interrupt occurs, an output pin connected to LED is toggled. So the LED is expected to blink at 1Hz. The three projects have some differences like below: (1) Fixed-function counter is used, and Counter_ReadStatusRegister is called in interrupt handler. (2) Fixed-function counter is used, and Counter_ReadStatusRegister is called in main function. It is more efficient way according to the application note. (3) UDB counter is used, and Counter_ReadStatusRegister is called in main function. As a result, (1) and (3) work correctly. But (2) doesn't work.(LED doesn't blink at 1Hz) I wonder why (2) doesn't work correctly. Do you have any ideas?   
0 Likes
6 Replies
Anonymous
Not applicable

Hi AK-37,

   

 

   

This behavior in case (2) is expected because the Fixed function peripherals have level sensitive interrupts.

   

The IRQ source is sticky, which means that the IRQ remains active until firmware clears the source of the request by "clear on read".

   

The reason why you might not observe the toggling in the case (2) is that upon getting interrupt for the first time, the source is never cleared. The execution never goes into the main code which unfortunately has the code necessary to clear the interrupt (Read API).

   

 

   

If you are to probe the interrupt lines on an oscilloscope for all the 3 cases, you'll observe that in case (1) and (3), there is a "pulse" on the interrupt line indicating Terminal count. But in case (2), the line goes high and stays there forever.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

When you have a look into the datasheet under "Status Register" you can see that the Fixed-Function-Implementation has a "Sticky"-bit for TC (Terminal count). Because of that when the bit is not cleared in the interrupt-routine (by reading the StatusRegister()   ) the interrupt will be set again immediately when the interrupt-routine is ended (RETI-Instruction). I didn't try, but defining the interrupt-type as "rising edge" instead of "derived" should help.

   

 

   

I really do not like the style the program looks like when using Isr_Start(). To insert code in the generated c-files (which must be repeated for every Project in the workspace). I prefer to use my very own routines

   

CY_ISR_PROTO(MyIntRoutine);  // Declaration

   

CY_ISR(MyIntRoutine) // Definition

   

{

   

 Flag = 1;

   

Counter_ReadStatusRegister();

   

}

   

and initialization with

   

 Ist_StartEx(MyIntRoutine);

   

 

   

This gives full control to my code and the routines show up in the main-file.

   

 

   

Happy coding

   

Bob

0 Likes
Anonymous
Not applicable

AK-37,

   

 

   

In the Sample2 project, if you connect the ISR component to "tc" terminal of the counter component you'll find that the LED blinks at 1Hz frequency.

   

There is no necessity of reading the status register either.

   

This is because the tc terminal gives a pulse upon every terminal count which will go low after a clock period.

0 Likes
Anonymous
Not applicable
        Hello, dasg. Thank you for advice. I confirmed that the interrupt handler was called again and again before ReadStatusRegister. I'll try to use TC pin instead of interrupt pin.   
0 Likes
Anonymous
Not applicable

Hi AK-37,

   

 

   

I tested the project by connecting the Interrupt component to the "tc" terminal and now the ISR is serviced regularly. The LED blinks at 1Hz. There is no necessity to clear the interrupt by reading the counter's status register.

0 Likes
Anonymous
Not applicable
        Hello, Bob. I tried rising edge, and it worked well! Thank you for your help. And I agree with your coding style.   
0 Likes