infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 9 of 9

Thread: Software Interrupt trigger

  1. #1
    Beginner Beginner san is on a distinguished road
    Join Date
    Jan 2019
    Posts
    4
    Points
    65

    Software Interrupt trigger

    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

  2. #2
    Advanced Advanced HIGHTEC.henk-piet.glas is on a distinguished road
    Join Date
    May 2017
    Posts
    66
    Points
    1227.5
    Hi San,

    Quote Originally Posted by san View Post
    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

    SanAensISR.zip

  3. #3
    Beginner Beginner san is on a distinguished road
    Join Date
    Jan 2019
    Posts
    4
    Points
    65
    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

  4. #4
    Advanced Advanced HIGHTEC.henk-piet.glas is on a distinguished road
    Join Date
    May 2017
    Posts
    66
    Points
    1227.5
    Hi San,

    Quote Originally Posted by san View Post
    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

  5. #5
    Beginner Beginner san is on a distinguished road
    Join Date
    Jan 2019
    Posts
    4
    Points
    65
    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?

  6. #6
    Advanced Advanced HIGHTEC.henk-piet.glas is on a distinguished road
    Join Date
    May 2017
    Posts
    66
    Points
    1227.5
    Hi San,

    Quote Originally Posted by san View Post
    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

  7. #7
    Beginner Beginner mustafa is on a distinguished road
    Join Date
    Jan 2019
    Posts
    2
    Points
    60
    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

  8. #8
    Beginner Beginner san is on a distinguished road
    Join Date
    Jan 2019
    Posts
    4
    Points
    65
    Quote Originally Posted by HIGHTEC.henk-piet.glas View Post
    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

  9. #9
    Advanced Advanced HIGHTEC.henk-piet.glas is on a distinguished road
    Join Date
    May 2017
    Posts
    66
    Points
    1227.5
    Hi San,

    Quote Originally Posted by san View Post
    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

+ Reply to Thread

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.