About interrupt disabled section

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

cross mob
hata_3396041
Level 4
Level 4
First solution authored First like received 50 questions asked

Hello

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.

Question1

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

Question2

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

Question3

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

Hayato

0 Likes
1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hayato-san,

Question1

Is my perception correct?

Yes you are correct.

Question2

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.

Question3

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.

Len

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

1 Reply
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hayato-san,

Question1

Is my perception correct?

Yes you are correct.

Question2

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.

Question3

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.

Len

Len
"Engineering is an Art. The Art of Compromise."