About losing interrupts

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

I previously asked this thread about PSoC interrupts.

Please tell me more about the last answer.

Generally, there is a case to miss an interrupt by some of reason.

For example, user doesn’t clear interrupt correctly. The interrupt with same priority happen at same time. If an interrupt is pending so long time, multiple same interrupt will be missed. and so on.

So user should implement the system with consideration of interrupt processing (occurrence, priority, etc).

⇒1.How long does it mean to be pending for a long time?(A few milliseconds? A few hours?)

    2.It says multiple same interrupt will be missed, but how many?

       (Does that mean that all interrupts on hold at that time are discarded?)

    3.These interrupts may or may not be lost, and if so, please let us know if you have a specific reason.

As a premise, are these interrupts not lost, just missed?

Best Regards

Hayato

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Hayato,

1.How long does it mean to be pending for a long time?(A few milliseconds? A few hours?)

As you only mentioned, there is no fixed timing like that. Once the interrupt is pended (by hardware or software reasons), it will be in a queue until it gets executed and the pending status is cleared and the source of interrupt is cleared (in case of sticky interrupt sources like GPIO, Timer etc).

2.It says multiple same interrupt will be missed, but how many?

(Does that mean that all interrupts on hold at that time are discarded?)

Yes. The number of interrupts that come before you clear the pending state of first interrupt will be counted as single interrupt. In simple way the interrupt pending register is binary. Multiple pending requests are treated as single pending request.

3.These interrupts may or may not be lost, and if so, please let us know if you have a specific reason.

Interrupts will not be lost unless the cases like 1 or 2 may exist. If you are facing any issue please let us know.

The best practice to deal with the interrupts is:

1. Clear the pending register as well as interrupt source register as the first step when you enter the ISR.

2. Keep the code as small as possible inside the ISR.

3. Divide the ISR into Top half and Bottom half and execute the code for Top Half inside the ISR.

4. Pend the PendSV interrupt and execute the Bottom half inside the PendSV Handler. Please find the attached document.

Hope this information helps !

Thanks

Ganesh

View solution in original post

0 Likes
4 Replies
lock attach
Attachments are accessible only for community members.
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Hayato,

1.How long does it mean to be pending for a long time?(A few milliseconds? A few hours?)

As you only mentioned, there is no fixed timing like that. Once the interrupt is pended (by hardware or software reasons), it will be in a queue until it gets executed and the pending status is cleared and the source of interrupt is cleared (in case of sticky interrupt sources like GPIO, Timer etc).

2.It says multiple same interrupt will be missed, but how many?

(Does that mean that all interrupts on hold at that time are discarded?)

Yes. The number of interrupts that come before you clear the pending state of first interrupt will be counted as single interrupt. In simple way the interrupt pending register is binary. Multiple pending requests are treated as single pending request.

3.These interrupts may or may not be lost, and if so, please let us know if you have a specific reason.

Interrupts will not be lost unless the cases like 1 or 2 may exist. If you are facing any issue please let us know.

The best practice to deal with the interrupts is:

1. Clear the pending register as well as interrupt source register as the first step when you enter the ISR.

2. Keep the code as small as possible inside the ISR.

3. Divide the ISR into Top half and Bottom half and execute the code for Top Half inside the ISR.

4. Pend the PendSV interrupt and execute the Bottom half inside the PendSV Handler. Please find the attached document.

Hope this information helps !

Thanks

Ganesh

0 Likes

Hello Genesh-san

Thank you for presenting the solution.

Let me ask you one question about the expression that "interrupts are lost".

Does this mean that the queued interrupt hold itself disappears?

Or does it just mean that you are missing an interrupt hold?

Hayato

0 Likes

Hi hata_3396041​,

It means that the interrupts are missed and is not serviced.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hayato-san,

I don't have a copy of your project so the following points are only guesses and generalizations.

One of the biggest issues designers have with interrupts is that the code in the ISR is doing too much and/or taking too long before returning from the ISR.

Examples of this type of issue is:

  • executing blocking functions such as UART port writes like UART_PutString() or UART_PutArray() or UART port reads like UART_GetChar().
  • Other blocking functions like CyDelay().

When you enter an ISR, ALL further interrupts are automatically disabled until the ISR code completes.   Therefore if in the ISR, a CyDelay(100) is executed, then any new interrupts occurring will be blocked from detection for at least 100msec.  These interrupts will at best be delayed and at worst lost.

I provided another user with a recommended set of "rules" to use when creating ISR code.  Re: About interrupt disabled section

https://community.cypress.com/message/252273?sr=search&searchId=03e1a5d0-4909-44ef-83b2-9c3cb7fe5719...

This list came from another expert and through my personal experience.

Len

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