• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 567 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.

OMAP-L138: When can code be preempted by HWI, SWI

Raman Sridahran
Prodigy 150 points
Part Number: OMAP-L138
Other Parts Discussed in Thread: SYSBIOS

I have scoured the net about details regarding when HWI or SWIs can interrupt executing code; or how the CPU handles an IRQ.  I have gone over the TI documentation about interrupts; but they simply talk about thread priorities - making it seem like an executing thread can be interrupted at any time.  I would like to know if this is the case.

Running TI-RTOS, if the CPU receives a HWI while executing code - can the executing code be preempted anywhere (at/before any instruction)?  Or are there certain instructions that can/cannot be interrupted? 

For example, if the cpu is in the kernel of a pipelined for loop and the CPU receive a HWI can the for loop be halted mid-loop?  Or are there certain instructions which can not be interrupted?

As a second related question - in the documentation for the DSPlib, it states that some functions disable interrupts for parts of their execution.  Do you have any examples of types of code that would require interrupts to be disabled for their successful execution? 

This question is for both the C674x and ARM cores on the OMAP-L138 processor running TI-RTOS.  I am encountering random, rare crashes in a large embedded application and am investigating whether software preemption on these two cores could be the root cause of our issue; and as such am trying to get some more details on how the applications are actually preempted.

  • +1
    Guru 13202 points

    Hello!

    SYSBIOS user guide explains situations when preemption may not occur, most of them when certain thread disables interrupts.

    On the other hand, CPU and Instruction set guide tells something that interrupts are disables couple instructions before the SPLOOP and there are certain conditions to let interrupt preempt the loop. So, generally, interrupts do not get served immediately, and if there is a need to save the state of pipelined loop, compiler will do that.

    Although SYSBIOS may have bugs, and it is possible you stepped on on one them, still it's mature and stable software, where trivial things like improper interrupts handling were sorted out decades ago. So sysbios is a last thing I would suspect. And since you say your application is large and complex, I'd rather suspect it. If you have a feeling something happens around interrupts, there might be a race condition in your app, failure to mutex shared resource and so many other fancy things.

    As to the second question, I could not provide clear example. Nevertheless, in C64x, before SPLOOP was introduced, there was a situation, when pipelining could disable interrupt for too long. In that case user could specify maximum number of cycles, during which the interrupts could be disabled. With this option one could produce less efficient, but quicker interruptible code. In C674x thing are bit different thanks to SPLOOP. But back to our business, I believe DSPLIB code might disable interrupts just to use the most efficient implementations.

    Finally, this all applies to DSP core, honestly I have practically no experience with ARM core, can't say what happens there.

  • 0 in reply to Victor Kazmirenko
    Prodigy 150 points

    Hi rrlagic:

    Thanks for the response.  I do also suspect the issue must be in our code as well as it is a large application, but I am nevertheless glad to hear someone with more experience expressing confidence in sysbios.  

    The real trouble for us is that the crash happens very intermittently (~days); and so we are trying to be judicious about what we spend time investigating as any experiment takes days to provide results.  This information will help us go forward with our debugging.  

  • 0 in reply to Victor Kazmirenko
    Prodigy 150 points

    We have narrowed the issue further and have eliminated thread preemption on the DSP/ARM cores as the root issue.  Thanks again for the clarification.