• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1574 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6654: Check pending interrupt

Gildas ROLLAND
Intellectual 640 points

Part Number: TMS320C6654
Other Parts Discussed in Thread: SYSBIOS

Hi,

I have an interrupt that could be triggered a second time in a very short time. So I want to check at the end of my interrupt sub routine if the interrupt is pending again.

The only solution I found is to read the Interrupt Flag Register. Could you confirm me that there is no better solution? (I didn't find anything in sysbios nor csl)

Do you have an example of MVC usage to read IFR, in C/C++ code?

Thanks for your help

(I use sysbios 6.46.00.23, ccs 6.1.3, on tms320c6654)

  • 0
    TI__Guru 65405 points
    Hi Gildas,

    I've forwarded this to the experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru** 116870 points
    Gildas,

    Please look at the Interrupt masking feature for HWI in TI RTOS/SYSBIOS. By default all interrupts HWI in TI RTOS are set to MAskingOption_SELF which means interrupt nesting is allows but the same ISR can`t interrupt itself. This default behavior can be chnaged by providing a custom mask or specify this mask to be MaskingOption_None or MaskingOption_Bitmask
    However this is highly dangerous and you could run intto system problems.

    I would recommend that you look at the following documentation for TI RTOS masking:
    software-dl.ti.com/.../IHwi.html

    for Quicker understanding, you can also look at the explanation of this setting in TI Training series on TI RTOS:
    training.ti.com/ti-rtos-workshop-series-5-10-using-hwi

    Note: Interrupt masking is covered from time interval 30 -35 mins from the start of that video

    The CSL code for the device in the Platform development kit (PDK) provides C code to read and write IFR. If you are using our SDK software then the CSL functions are defined in the file csl_chipAux.h found under pdk_c665x_x_x_x\packages\ti\csl

    I hope this help provide some guidance.

    Regards,
    Rahul
  • 0
    Guru 13202 points

    Hello!

    You describe the situation as "interrupt may get triggered second time" while ISR is still busy servicing previous request. Effectively it means interrupt event period can be shorten than ISR duration. At this moment you consider interrupt happened just second time, and yes, you probably can detect it with flag register. But try to look beyond: what happens if your interrupt was triggered not only second, but third time during ISR run? You'll have no mechanism to detect it.

    Suppose you want ISR to run as many times, as interrupt was triggered. Then I would suggest another schedule. For your external interrupt make a very short HWI handler, which will be posting actual ISR as SWI. Then one may use Swi_inc() function to update SWI trigger counter. If you decide go this way, please read carefully 3.5.5 Using a Swi Object’s Trigger Variable in SYSBIOS user guide to avoid misconception about trigger variable.

    Hope this helps.

  • 0
    Intellectual 640 points
    Hi,

    Thanks for your answers.
    My need is not to serve this second isr, but just to be informed that it has occured before the end of previous.

    So Rahul's solution based on CSL should be the easiest for my need. I'll try it

    regards
  • 0 in reply to Gildas ROLLAND
    Intellectual 640 points
    Hi,

    Reading of IFR is functionnal, but It don't allow me the check my pending interrupt.

    I've put my pending detection code inside the sub routine of the interrupt that I want to monitor and nothing append.
    I've put the same code into another interrupt, and it detect that the interrupt I want to monitor is pending.

    Is there any protection that prevent IFm bit in IFR to go high if we are currently processing this interrupt
    I didn't find anything about this in sprugh7.

    In case this could have an impact, my interrupt is gpio18, and I use CpIntc to map and dispatch it

    thanks
  • 0 in reply to Gildas ROLLAND
    Intellectual 640 points
    Hi,

    Nobody could explain me why I don't see IFm bit set in IFR when the same interrupt occured a second time while I'm still processing the previous one.
    Does this mean that I've lost the second isr?

    Thanks
  • 0 in reply to Gildas ROLLAND
    TI__Guru** 116870 points
    Gildas,

    Can you share what code you have in both the interrupt routines, one where you check the IFR and the other that is detecting the interrupt is pending? I am not sure if there is any routing issue that is causing this. Have you also looked at section 9.4.1 in www.ti.com/.../sprugw0c.pdf to make sure that the IER and GIE bits are setup correctly.

    There is no protection on this register as far as I can tell but I can check internally if there is something in design that is not documented.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    TI__Guru** 116870 points
    One other thing to check is to see if the TI RTOS somehow disables the interrupt when it enters the ISR. Please look at the section for MAsking interrupts and Nesting interrupt explained here and see if you are running into one of those scenarios:
    training.ti.com/ti-rtos-workshop-series-5-10-using-hwi

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Intellectual 640 points
    Rahul,

    My chech is the same in both interrupt routines:
    if (0 != (IFR & (1 << myInterruptNumber)))

    To do my test, i've added in my routine, before the previous IFR check, a while on timer7 to be sure to have the interrupt a second time.
    I've also tried to add a Hwi_post (myInterruptNumber) and in this case the IFm bit is set and I correctly detect it with my check.

    I've tried to do the same thing whith a timer interrupt. In the timer interrupt routine I've added a while longer than the timer configured and after this while, I've checked the IFR bit corresponding to this timer. The pending interrupt is correctly detected by my check

    So it's seems that it's the gpio interrupt signal that is not stored into IFR. Could this be due to gpio module or usage of CpIntc_dispatch?

    I've read your documentation and it confirm that the mask is not between gpio and IFR, but between IFR and cpu. So IFR should reflect received interrupt signal even if sub routine is not called because interrupt is masked.

    Regards
  • 0 in reply to Gildas ROLLAND
    Intellectual 640 points
    Hi Rahul,
    No idea on my issue?
  • 0 in reply to Gildas ROLLAND
    Intellectual 640 points
    Hi,

    I've found my answer in source code of CpIntc_dispatch which start by disabling host interrupt.
    So in case of use of CpIntc_dispatch, pending interrupts must be check into CIC registers and not in IFR register

    regards