Banner_AURIX_Security-Solution Banner_AURIX_Security-Solution Banner_AURIX_Security-Solution


infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 2 of 2

Thread: Disable Interrupt in Tricore

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

    Disable Interrupt in Tricore

    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

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

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

+ Reply to 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.