Software Interrupt trigger

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

cross mob
User16411
Level 1
Level 1
Hi,
I would like to know about the Software Interrupt Configuration in TC23X. I would like what to know what are the nodes exclusively reserved for Software Interrupt so that
I don't trigger the wrong interrupt.

Does the General Purpose Service Request can be used for software interrupt? and is this is the only node I can use for software interrupt
Also regarding how trigger, Is it so simple as just set SRR bit to 1.? Any other Steps I need to take?

Any help would be greatly appreciated. ?

Regards
san
0 Likes
8 Replies
lock attach
Attachments are accessible only for community members.
User13290
Level 5
Level 5
First like received First solution authored
Hi San,

san wrote:
Hi,
I would like to know about the Software Interrupt Configuration in TC23X. I would like what to know what are the nodes exclusively reserved for Software Interrupt so that I don't trigger the wrong interrupt.

Does the General Purpose Service Request can be used for software interrupt? and is this is the only node I can use for software interrupt Also regarding how trigger, Is it so simple as just set SRR bit to 1.? Any other Steps I need to take?

Any help would be greatly appreciated.

Regards
san


I have attached an example that might help with what you're after. It was written in the context of migrating TASKING interrupts to HighTec. It makes use of the general purpose services requests that can only be triggered with a software interrupt request. I've added a detailed readme explaining step by step how it works. Let me know if you'd like me to elaborate.

Best regards,

Henk-Piet Glas
Principal Technical Specialist

0 Likes
User16411
Level 1
Level 1
Hi,
Thank you very much reply. It was of great help.
It is now clear to me how to bind Software interrupt and also trigger the Software Interrupt.
(By the SETR as shown in the small function call , right. )

In the ISR I can see the __enable pragma. I think this will enable high priority interrupts providing a nesting of interrupts.
Is this really needed as all the interrupts which have priority greater than current Interrupt priority are enabled by default in ISR execution or do we explicitly
need to do __enable to enable interrupts interrupts which have priority greater than current Interrupt priority.

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

san wrote:
Hi,
Thank you very much reply. It was of great help.
It is now clear to me how to bind Software interrupt and also trigger the Software Interrupt.
(By the SETR as shown in the small function call , right. )

In the ISR I can see the __enable pragma. I think this will enable high priority interrupts providing a nesting of interrupts.
Is this really needed as all the interrupts which have priority greater than current Interrupt priority are enabled by default in ISR execution or do we explicitly
need to do __enable to enable interrupts interrupts which have priority greater than current Interrupt priority.

Regards
san


Happy to read the example is of help. At first glance it may look a bit superfluous to explicitly use the __enable() intrinsic. But note in hightec.h that the vector handler stub saves the lower context by means of the _svlcx() intrinsic. But this instruction also makes the handler uninterruptible. Depending on your use-case this may be exactly what you want. In this case however, just for demo purposes, I want isrX() to be interruptible by isrY() and hence must add __enable().

Note you can alternatively use intrinsic __bisr() in the handler stub. This instruction also saves the lower context but still allows it to be interrupted by handlers of higher priority. So within hightec.h you can substitute _svlcx() with __bisr(sprn). Once you do that you may remove __enable() from isrX() and the example will behave exactly the same as before.

Best regards,

Henk-Piet Glas
Principal Technical Specialist
0 Likes
User16411
Level 1
Level 1
Thank you detailed explanation and your support. In our example we are using __enable() as the first intrinsic in ISR. Does that still mean all interrupts are enabled and
it can interrupt the ISR even if it is the same priority or higher priority. Can a lower priority interrupt can interrupt the ISR because "all interrupts" are enabled.

Only __bisr() instruction checks for priority of interrupts before it interrupts the ISR. Is it so?
0 Likes
User13290
Level 5
Level 5
First like received First solution authored
Hi San,

san wrote:
Thank you detailed explanation and your support. In our example we are using __enable() as the first intrinsic in ISR. Does that still mean all interrupts are enabled and
it can interrupt the ISR even if it is the same priority or higher priority. Can a lower priority interrupt can interrupt the ISR because "all interrupts" are enabled.

Only __bisr() instruction checks for priority of interrupts before it interrupts the ISR. Is it so?


Hi San,

The __enable() intrinsic translates to the enable assembly instruction which sets the IE bit in the Interrupt Control Register. So it globally enables interrupts. However it doesn't effect the prioritisation between interrupts. This is still governed by the SPRN of each individual interrupt.

In the given example isrX() is assigned an SPRN of 10 and isrY() is assigned an SPRN of 20. Hence isrY() can theoretically interrupt isrX() provided the IE bit is set. Had the SPRNs of isrX() and isrY() been the other way around then this would never happen. Instead isrX() would deadlock in the while loop.

If you'd like to know more about the AURIX architecture I recommend downloading its architecture manual. For this you'll have to sign up to MyICP first, if you haven't done so already. Chapter 5 of the architecture manual explains the interrupt system detail.

While reading to the architecture manual myself just now, I noticed that I told you an untruth in my previous posting. I wrote that the svlcx instruction enables interrupts globally. This is not so. Instead the architecture disables interrupts globally while the interrupt is being served. Hence the enable instructions becomes a necessity if you want the interrupt handler to be interruptible itself. My statement about the bisr instruction was consequently also false. You'll remember I wrote it doesn't globally disable interrupts and hence there was no need for the __enable intrinsic. Instead the bisr instruction globally enables interrupts while saving the lower context at the same time, and it is for this reason that the __enable intrinsic then becomes superfluous.

If you want to know more about the svlcx and bisr instruction you may want to download the instruction manual in addition to the architecture manual. Note that the bisr instruction explicitly sets the current CPU priority. Hence I wrote __bisr(sprn) in my previous posting. Effectively this is the same as the pending interrupt priority number (PIPN) that would otherwise be assigned.

Best regards,

Henk-Piet Glas
Principal Technical Specialist
0 Likes
User16444
Level 1
Level 1
iyi günler tc1796 kod yazma nasıl yapabilirim ve hangi program kullanmalıyım
tricore nin içindeki kilitli yazılımı nasıl okunabilir hale getirebilirim çok teşekkürler
0 Likes
User16411
Level 1
Level 1
HIGHTEC.henk-piet.glas wrote:
Hi San,



Hi San,

The __enable() intrinsic translates to the enable assembly instruction which sets the IE bit in the Interrupt Control Register. So it globally enables interrupts. However it doesn't effect the prioritisation between interrupts. This is still governed by the SPRN of each individual interrupt.

In the given example isrX() is assigned an SPRN of 10 and isrY() is assigned an SPRN of 20. Hence isrY() can theoretically interrupt isrX() provided the IE bit is set. Had the SPRNs of isrX() and isrY() been the other way around then this would never happen. Instead isrX() would deadlock in the while loop.

If you'd like to know more about the AURIX architecture I recommend downloading its architecture manual. For this you'll have to sign up to MyICP first, if you haven't done so already. Chapter 5 of the architecture manual explains the interrupt system detail.

While reading to the architecture manual myself just now, I noticed that I told you an untruth in my previous posting. I wrote that the svlcx instruction enables interrupts globally. This is not so. Instead the architecture disables interrupts globally while the interrupt is being served. Hence the enable instructions becomes a necessity if you want the interrupt handler to be interruptible itself. My statement about the bisr instruction was consequently also false. You'll remember I wrote it doesn't globally disable interrupts and hence there was no need for the __enable intrinsic. Instead the bisr instruction globally enables interrupts while saving the lower context at the same time, and it is for this reason that the __enable intrinsic then becomes superfluous.

If you want to know more about the svlcx and bisr instruction you may want to download the instruction manual in addition to the architecture manual. Note that the bisr instruction explicitly sets the current CPU priority. Hence I wrote __bisr(sprn) in my previous posting. Effectively this is the same as the pending interrupt priority number (PIPN) that would otherwise be assigned.

Best regards,

Henk-Piet Glas
Principal Technical Specialist


Hi,
Thank you very much for your detailed reply. It clears my queries and helps with the my SW interrupt problem.
Thanks a lot for your time !!

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

san wrote:
Hi,
Thank you very much for your detailed reply. It clears my queries and helps with the my SW interrupt problem.
Thanks a lot for your time !!

Regards
San


Thanks for saying so. Glad to be of help. Happy developing!

Best regards,

Henk-Piet Glas
Principal Technical Specialist
0 Likes