6 Replies Latest reply on Apr 2, 2012 8:57 AM by userc_44184

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

              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?   
        • 1. Re: AN60630, Guideline #2: Do Not Call Functions from Interrupt Handlers

          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
            JoMe_264151

            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

              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
                        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

                  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
                            Hello, Bob. I tried rising edge, and it worked well! Thank you for your help. And I agree with your coding style.