1 Reply Latest reply on Oct 2, 2020 6:37 PM by LePo_1062026

    About interrupt disabled section




      Thank you for your constant support.


      ・Interrupts generated in the interrupt-disabled section are pending and resumed after exiting the interrupt-disabled section.

      ・Due to the specifications of Coretex, only one of the interrupts generated in the interrupt disabled section has the highest priority is pending.



      Is my perception correct?


      As far as the driver source code is concerned, interrupts

      Registers representing pending are for each interrupt number

      It seems that bits are assigned, so I feel that all types of interrupts can be pending at the same time.


      Specifically, even if I experiment with the following code, it seems that the UART n transmission buffer Empty interrupt is being executed.


      UART_XXX_PutChar (a); // Write here to the transmit register of UART n

      State = CyEnterCriticalSection ()

      UART_XXX_SetPending (); // Set a UART m (priority is higher than n) interrupt, separate from UART n

      Wait processing of about 100 milliseconds // The first UART n transmission buffer Empty interrupt should have occurred so far.

      CyExitCriticalSection (State);



      Why are low-priority interrupts entered within the interrupt-disabled section also pending?



      Does it exist if the generated interrupt is discarded?


      Since the customer is in trouble, it would be helpful if you could reply as soon as possible.


      Best Regards


        • 1. Re: About interrupt disabled section




          Is my perception correct?

          Yes you are correct.



          Why are low-priority interrupts entered within the interrupt-disabled section also pending?

          By design, every CPU doesn't know the designer's intention.  Therefore when interrupts from multiple sources occur, the interrupt active flags are preserved.   The is true even with lower priority interrupts.   The CPU design assumes ALL interrupts are important to the application.  It's up to the application SW design to "throw away" any unneeded interrupts.


          The normal ISR servicing is to process the first incoming interrupt unless there are more than one pending.  This can happen if interrupts are temporarily disabled.  If this is the case, there is an assigned priority by the user or in the CPU design.

          Once the first ISR is processed and RTI, the next ISR is processed and so on.



          Does it exist if the generated interrupt is discarded?

          Jumping into an ISR is due to a pending interrupt.  The interrupt active flag in the register may or may not be automatically cleared when the ISR begins processing.   I recommend you consult the CPU tech documents for this information.  If the interrupt is not automatically cleared, you will have to perform it in the ISR.


          Note:  Be careful not disable interrupts too long.   As noted, each interrupt source has an interrupt active flag.    If interrupts are disabled too long, you might actually get more than one attempt to set the SAME interrupt active flag.  However, since there is only one active flag for this interrupt source, you might lose the relevant data that caused the earlier interrupt(s).


          An example of this condition is a Real-Time Clock (RTC) interrupt.   If four 1 seconds RTC interrupts attempt to be serviced but interrupts were disabled for 4 secs, the ISR will be serviced ONLY once and the latest RTC data will be available.


          A slight exception are communication interrupts.   A UART has a 4-byte Rx FIFO.   Therefore if the ISR is not serviced for 4 UART Rx interrupt attempts, you can use just one ISR call to pull all 4 bytes from the Rx FIFO.


          Lessons Learned


          Back when I was a young engineer (many, many years ago). a experienced SW engineer told me the following wisdom about using interrupts.

          • Only disable interrupts to properly service time-critical SW atomic operations.
          • Only disable interrupts for a the shortest amount of time needed.
          • When servicing an ISR, execute the least amount code to get the relevant data and store it for queued use in the main Task or Task scheduler.  This is to prevent other pending ISRs from getting delayed.  Remember: When executing an ISR, interrupts are normally disabled until the ISR is completed.
          • If you need to execute an action in the ISR, make sure it can execute quickly to exit the ISR ASAP.  If it can't be executed quickly queue it in the main Task or Task scheduler.  An example of what NOT to execute in the ISR is dumping multiple bytes to a serial port.  Also avoid Delay() commands.
          • Avoid nested interrupts.  Use sparingly.  Nesting can cause stack overflows if not carefully designed.



          2 of 2 people found this helpful