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

Syslink threads and interrupt handling on Linux.

claudio potenza
Intellectual 400 points
Other Parts Discussed in Thread: OMAPL138


Hi all,

I am chasing some timing issues on my system that uses SYSLINK on linux.

I have a custom board with the OMAPL138. The ARM core is running linux (kernel 3.0.23)

I am using:  syslink_2_21_01_05 on the linux side.
(bios_6_35_01_29, ipc_1_25_02_12, TI_CGT_C6000_7.4.2, xdctools_3_25_00_48 on the DSP side).

I have a Linux Real Time thread (at high priority) on the ARM sending a small message to the DSP every few milliseconds.
Normally sending the message (basically MessageQ_alloc followed by MessageQ_put) takes a few hundred microseconds on the ARM.
But sometimes I can see that my high priority thread gets stuck either in MessageQ_alloc or MessageQ_put for up to almost a second.

I am trying to understand if this could be due to some interference with a different Linux low priority task that receives messages from the DSP (at very low frequency, in the order of one every few seconds).

So I'd like to understand exactly how interrupts and messages incoming to the ARM are handled.

I can see that I have two threads created in my system by Syslink.
One is a kernel thread created by the driver when I call Ipc_control(Ipc_CONTROLCMD_STARTCALLBACK)
and another one is a user space thread created when I open the Notify driver.

Looking at the SYSLINK code I seem to understand that the kernel thread is the "bottom half" of the interrupt handling, While I'm not suer what the user space thread does.

So my first question is:

1) When an interrupt is received, I guess the kernel thread is activated to do the real work for the interrupt handling. Does it wakes up the user space thread to perform the work.

2) does this happen only for Notify events or also for MessageQ messages?

thanks

  • 0
    TI__Mastermind 22760 points

    Hi Claudio,

    It's possible that there is contention for the gate that is used in MessageQ_alloc() and MessageQ_put().  If you created the MessageQ heap without a gate, the default GateMP gate will be used.  So anything that uses the default GateMP (on the DSP or Arm) could block your task.  Could you try creating a gate for your MessageQ heap and see if that fixes the problem?

    Best regards,

        Janet

  • 0 in reply to janet
    Intellectual 400 points

    Hi Janet,

    I have already created a GateMP for the heap. My next attempt would be to have two message heaps, each one with its own gate: one for the ARM=> DSP messages and one for the DSP => ARM.

    In the meantime I really would like to understand how the reception of messages work on the Linux side.

    Can you confirm (or otherwise) that each received message will go through the two threads that I have identified (first the kernel thread created by the driver and then the user space thread NotifyDrv_workerThread)?

    thanks

  • 0 in reply to claudio potenza
    TI__Mastermind 22760 points

    Hi Claudio,

    I think that when a message is received on the Linux side, it only goes through one thread: the kernel thread that is created when the NotifyDriverShm is created.  When the DSP interrupts the Arm to signal that a message is available, the ISR posts a semaphore which wakes up this kernel thread.  There is then a sequence of functions that get called by this thread, which looks to me like:

        <arch>IpcInt_isr()
            --> _NotifyDriverShm_ISR()
                --> Notify_exec()
                    --> _TransportShmNotify_notifyFxn()
                        --> MessageQ_put()

    The (kernel side) MessageQ_put() call puts the message on the local message queue and posts the message queue's semaphore.

    The other thread, NotifyDrv_workerThread, is created during Notify_setup(), and is waiting for events.  It must be calling the callback functions that have been registered on the user side with Notify.  I did not see anything in the user side MessageQ code that would indicate that the NotifyDrv_workerThread would be involved with messages.

    Best regards,

        Janet