• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 1438 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.

RM48 disable/enable specific interrupts

Ubaid Mahmood
Intellectual 970 points

Hello,

During runtime, I need to disable and then re-enable interrupts for sci, lin, i2c, and spi. I had a few questions:

1) for sci/lin/spi must I start each component after disabling or enabling?

 i.e. fpr sci/lin

/** - Finaly start SCILIN */
scilinREG->GCR1 |= 0x80U;

2) for sci/lin/spi is enabling/disabling the interrupt sufficient, or must the interrupt level be adjusted simultaneous as well?

i.e. sci

/** - Disable all interrupts */
sciREG->CLEARINT = 0xFFFFFFFFU;
sciREG->CLEARINTLVL = 0xFFFFFFFFU;

/** - set interrupt level */
sciREG->SETINTLVL = (uint32)((uint32)0U << 26U) /* Framing error */
| (uint32)((uint32)0U << 25U) /* Overrun error */
| (uint32)((uint32)0U << 24U) /* Parity error */
| (uint32)((uint32)0U << 9U) /* Receive */
| (uint32)((uint32)0U << 8U) /* Transmit */
| (uint32)((uint32)0U << 1U) /* Wakeup */
| (uint32)((uint32)0U << 0U); /* Break detect */

/** - set interrupt enable */
sciREG->SETINT = (uint32)((uint32)1U << 26U) /* Framing error */
| (uint32)((uint32)1U << 25U) /* Overrun error */
| (uint32)((uint32)1U << 24U) /* Parity error */
| (uint32)((uint32)1U << 9U) /* Receive */
| (uint32)((uint32)0U << 1U) /* Wakeup */
| (uint32)((uint32)1U << 0U); /* Break detect */

3) It appears there is no way to clear any pending interrupts for i2c nor sci, but am able to clear pending interrupts for spi.  Is this correct?

Thanks.

Ubaid

  • 0
    TI__Guru**** 244400 points
    Hello Ubaird

    Wrong forum. Moving it to RM48

    Regards
    Amit
  • 0 in reply to Amit Ashara
    TI__Mastermind 22715 points
    Would you please provide more detail about what you want to achieve? Why do you want to dynamically disabling and and re-enabling interrupts from those module? What is your expected behavior after you re-enabling interrupts from those modules?

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Intellectual 970 points

    There are some hard real-time processing that we need to process. We can not achieve hard real-time time requirements with interrupts enabled. There are select interrupts that we want to process as there are higher priority and it would be acceptable to not meet the real-time requirements.

    Before time-sensitive processing, we want to disable select interrupts, and then re-enable after completion of the critical routine.  When re-enabling interrupts, we want the system to continue to accept and process the lower priority interrupts.

    Side question: I understand that there are low and high priority interrupts.  If a high priority interrupt has triggered, can another high priority interrupt interrupt the first?


    -Ubaid

  • 0 in reply to Ubaid Mahmood
    TI__Guru 68920 points
    Ubaid,

    I'd think this would be better handled in VIM.

    First, you can reorder the interrupt requests so that the priority matches the needs of your application.
    See 15.8.17 VIM Interrupt Control Register[0:31] (CHANCTRL[0:23]).

    Then, while we don't have automatic masking of lower priority interrupts for nesting as a feature of the VIM, you can use the REQENASET and REQENACLR registers to do this priority based masking. You can read REQENASET to find out which channels are enabled, and store this off for later when you exit the ISR. Then you can use REQENACLR to clear the interrupt enable of all the channels lower priority than the one you are servicing. When you're exiting the ISR you can use the saved value from REQENASET - mask it with a bit mask of all the lower priority channels - and write this back to REQENASET to re-enable any channels you disabled on entry - without changing the state of any higher priority channels.

    This has the advantage of being handled at a central point (the VIM) and it's closer to the CPU so the changes will take fewer cycles to affect the CPU's IRQ request input ... than if you try to do this in each individual peripheral.

    Sorry we don't have a good example of this. There are some threads on this forum with regard to nesting interrupts as well. Changing the processor state is important when you do this and it's kind of tricky.
  • 0 in reply to Anthony F. Seely
    TI__Mastermind 22715 points
    I would suggest you to do a system analysis first: How many events will the system react? How often those events would occur? What is the processing time for each event? And most importantly, what is the maximum latency allowed in response to each event? With those those information you can create a picture about how to meed the requirement of the maximum latency allowed in response to each event. You need to be careful in dynamically disabling/enabling interrupts (at module or at VIM). If the IO module keeps running and you not serve in time, you will get data overrun or under-run error that are very hard to debug. After system analysis, you may find that you do not need to dynamically disable/enable interrupts.

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Intellectual 970 points
    Thank you Anthony and Zhaohong!

    I assessed the design and decided to utilize RTI to help achieve the objective to minimize the impact to the system.