• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1105 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.

MessageQ_get hangs when multiple writers

Jonathan Nate
Prodigy 90 points
Other Parts Discussed in Thread: BIOSLINUXMCSDK

my mcsdk version is 3.0.4.18

Hi

I've started doing some simple processing on my evm/6638 board. I have a problem with using multicore API. Based on the ipc sample i've done this

DSP side

create recv queue (on each)

while(1)

{

MessageQ_get(...)

msg->debug_field = MultiProc_self();

MessageQ_put(reply_queue_id...)

}

ARM side

create recv queue

open 8 send queues

for (i=1 to 8)

{

MessageQ_put(...)

MessageQ_get(...,MessageQ_FOREVER)

}

This works OK. But when I tried,

for (i=1 to 8)

MessageQ_put(...)

for (i=1 to 8)

MessageQ_get(...,MessageQ_FOREVER)

the second call to MessageQ_get hangs.

According to the debug field, I see that in the first scenario everything is OK - the messages are returned from each core. I also tried using the MessageQ_count API, but it always return 0 (on the ARM side).

I understand that MessageQ uses HW semaphores inside to protect against write-overlaps so that's supposed to be OK. I also figured maybe since all DSP writers arite at the same time, the queue is not signalled again, but using MessageQ_get didnt help me either. Am I missing something (basic)?

thanks

JN

  • 0
    Prodigy 90 points
    Update: I added a delay in each core before putting the message back, it now looks like this

    DSP side

    create recv queue (on each)

    while(1)

    {

    MessageQ_get(...)

    msg->debug_field = MultiProc_self();
    Task_sleep(500*MultiProc_self()); // NEW ADDITION
    MessageQ_put(reply_queue_id...)

    }

    this makes the SW to run smooth with no hanging in the ARM. So it kinda looks like racing :(
  • 0 in reply to Jonathan Nate
    TI__Mastermind 20790 points

    Jonathan Nate,
    Good to see, you are trying smooth communication on the ARM. Please find the some more information about the MessageQ_put.
    MultiProc_self:This API returns the processor ID of the processor running.
    MessageQ_put:
    If the destination queue is local, the message is placed on the appropriate priority linked list and the ISync signal function is called.
    If the destination queue is on a remote processor, the message is given to the proper transport and returns.
    An ISync object has two main functions:

    • signal
    • wait

    Whenever MessageQ_put() is called, the signal() function of the ISync implementation is called.
    If MessageQ_get() is called when there are no messages on the queue, the wait() function of the ISync implementation is called.
    The timeout passed into the MessageQ_get() is directly passed to the ISync wait() API.

  • 0 in reply to Pubesh
    Prodigy 90 points
    Hello Pubesh, thanks for the quick reply.

    I understand that the queue has an internal signalling mechanism. However, I don't see if I can have any effect on it. I'm in the ARM side and I call MessageQ_get, and I expect to get 8 replies, since I have 8 cores sending messages to this queue. Is there any specific behaviour for ARM MessageQ? HW limitations (such as interrupt handling)? Sould I use different synchronization method?

    thanks
  • 0 in reply to Jonathan Nate
    TI__Mastermind 20790 points
    Jonathan,
    Please check the latest version of MCSDK3.x along with IPC. This version will support an Inter-process communication between DSP-DSP and ARM-DSP(ARM portion). The IPC version is 3.22.2.11
    Find the latest MCSDK download for Keystone II,
    http://www.ti.com/tool/bioslinuxmcsdk