Disable Interrupt in Tricore

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

cross mob
User16411
Level 1
Level 1
Hi All,
I have a query regarding the disableing interrupts in tricore.

If the interrupts are disabled and if any interrupts occur while the interrupts are disabled, does interrupts are put in pending state.
That means if the interrupts are enabled agian, does the same interrupts trigger again or does the interrupts are disabled itself so that the
system doesn't know the occurance of such an interrupt ?

I know in some controllers that disable interrupts puts the interrupts in pending condition so that they trigger agin when interrupts are triggered
again when interrupts are re-enabled. Is the same situation in Tricore also?

If any one can clarify my query it would be great.

Regards
San
0 Likes
1 Reply
User13290
Level 5
Level 5
First like received First solution authored
Hi San,

san wrote:
Hi All,
I have a query regarding the disableing interrupts in tricore.

If the interrupts are disabled and if any interrupts occur while the interrupts are disabled, does interrupts are put in pending state.
That means if the interrupts are enabled agian, does the same interrupts trigger again or does the interrupts are disabled itself so that the
system doesn't know the occurance of such an interrupt ?

I know in some controllers that disable interrupts puts the interrupts in pending condition so that they trigger agin when interrupts are triggered
again when interrupts are re-enabled. Is the same situation in Tricore also?

If any one can clarify my query it would be great.

Regards
San


I took a peek in the architecture manual as well as the family manual of your derivative (TC23x if I recall). This is what I was able to find.

Each service request node (=SRN) partakes in an arbitration round the moment an interrupt is being triggered. This results in a winning service request priority number (=SRPN) which is then supplied to the CPU. Effectively this SPRN is now pending until it is either acknowledged by the CPU or it becomes replaced with a new winner of a subsequent arbitration round.

For the CPU to acknowledge the SPRN it must either be higher than or equal to the current CPU priority number (=CCPN). This implies that interrupts can interrupt themselves provided its prologue uses either the `bisr` or `enable` assembly instruction. So there should be no problem serving new interrupt events of the same type, for as long as these occur at a relatively slower rate than the duration of your ISR.

The previous is a base-case scenario. The following is a worst-case scenario.

As soon as the CCPN is higher than your SPRN, it will have to wait for the CCPN to drop. If during this pending state another interrupt event occurs on the same SRN as before, then this will trigger the IOV bit, indicating that an interrupt overflow has occurred. This means that specific event will be lost unless you write code to handle such overflows.

The takeaway from the previous is that when interrupt events need to be serviced fast without being accidentally blocked by a pending state, you must make sure to give it the highest available SPRN. The previous is just a careful summary/conclusion of what I have read. Maybe someone else can confirm, refine or refute it.

Best regards,

Principal Technical Specialist
Embedded Software
0 Likes