• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 345 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC4357 Interrupt re-enable problem

Umang Patel83
Prodigy 200 points

Hi,

I'm currently writing code in which I have created critical sections by disabling channels which are of lower priority than a specified channel. Suppose 5 is the specified channel. Then all channels 5- 128 will be disabled while 0-4 channels will be serviced. I do not want to use _enable_IRQ and disable_IRQ calls to do the same.

I have an sci interrupt driven code driver which works fine.  But doesn't work well when I create such critical section (according to the logic I described above). I'm assuming that the problematic section of the code is when I try to mask the interrupts using vimREG->REQMASKCLR0 and then unmask the interrupts using vimREG->REQMASKSET0. 

I'm assuming that if any interrupts occur when the code is in critical section (interrupts are masked) then the IRQ will be queued. After the code exits the critical section, the pending interrupt will then trigger a IRQ interrupt service routine.

Please correct me if I am wrong.

-Umang

  • 0
    TI__Guru 59540 points
    Hello Umang,

    I have forwarded your questions to one of our system architecture experts so that they may review your description of the implementation and provide guidance/support.
  • 0
    TI__Guru**** 159445 points

    Hello Umang,

      Your understanding is correct that the masked interrupts will remain pending until they are unmasked in the VIM. I'm not sure what you meant that the sci interrupt code does not work. What problem do you see? How long is the critical code you are running and during which time how many interrupts (lower priority channels than channel 5) could have happened?

      Which SCI are you using? Is it the SCI3 with its default interrupt request mapped to channel 64 or you are using LIN/SCI with the interrupt request mapped to channel 13? Is it possible that you have other higher priority channels (higher than the SCI but lower than channel 5) become pending? When you unmask the interrupts the higher priority channels will be serviced first? The longer your critical code section is, the higher chances that there could be more interrupts become pending. When you exit your critical section, the SCI interrupt may not be serviced immediately until other higher priority channels are serviced. This is just one possible factor that might affect the SCI operation. For example, an external device might have sent a character to the SCI. Since the interrupt is masked it will wait until it is unmasked and until all higher priority channels are serviced. If the SCI interrupt is pending for too long then the external device could send another character that creates an overrrun conditon. If you can elaborate what SCI problem you are facing then we can try to understand the root cause of your problem.