-
1. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers
gautam.das.g Mar 26, 2012 1:22 PM (in response to akinori.minakawa)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.
-
2. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers
bob.marlowe Mar 26, 2012 2:14 PM (in response to akinori.minakawa)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
-
3. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers
gautam.das.g Mar 27, 2012 12:59 AM (in response to akinori.minakawa)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.
-
4. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers
akinori.minakawa Mar 31, 2012 10:48 AM (in response to akinori.minakawa)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. -
5. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers
gautam.das.g Mar 31, 2012 11:35 AM (in response to akinori.minakawa)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.
-
6. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers
akinori.minakawa Apr 2, 2012 8:57 AM (in response to akinori.minakawa)Hello, Bob. I tried rising edge, and it worked well! Thank you for your help. And I agree with your coding style.