• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 990 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.

DSP hanging in MessageQ_open?

Kent Dekome
Intellectual 630 points

Got an OMAP138 , creating a msgQ on the ARM side, putting a msg on the DSP side, but DSP hangs in MessageQ_open?!

How the heck can it hang without returning error?

  • 0
    TI__Mastermind 32475 points

    Kent,

    What do you mean by "Hang"?  Typically MessageQ_open() is done in a while loop until it succeeds.

    Make sure you create the MessageQ's  before you do the opens.

    Judah

  • 0 in reply to judahvang
    Intellectual 630 points

    It doesnt return...simple DSP code fragment...it doesnt get to Task_yield()!

            // send the shared ptrs to ARM...

            MessageQ_QueueId msgQid = 0;
            int i = 0;

            do
            {
                i = MessageQ_open( MSGQ_NAME, &msgQid );
                   Task_yield();
            }
            while( 0 != i );

  • 0 in reply to Kent Dekome
    TI__Mastermind 32475 points

    MessageQ_open queries all processors in your system to see if the MessageQ name was created on that processor.

    In your case of ARM and DSP, if you run this on the DSP, it will send an interrupt to the ARM and wait for its reponse.  Make sure the ARM is running.  Make sure the ARM has created the MessageQ with the name that you are trying to open.

    Judah

  • 0 in reply to judahvang
    Intellectual 630 points

    I got it working thanks...I more slavishly followed the MessageQ example...I dont know whether I had  a func call out of order or what...but I was receiving no error/status msgs on the console to clue me in as to what was wrong, and no source code to step into either...

  • 0 in reply to Kent Dekome
    TI__Mastermind 32475 points

    Kent,

    I think what happened is your task is blocked on a semaphore during the NameServerRemoteNotify_get() query of remote processors.

    MessageQ_open calls NameServer_get which ends up calling NameServerRemoteNotify_get.  The default timeout for the Semaphore_pend() call inside NameServerRemoteNotify_get() is to wait forever.  You can change the default timeout during configuration step in your *.cfg and if you did this I think you would have gotten an error return.

    BTW we ship the sources so that should be available to you.

    Judah

  • 0 in reply to judahvang
    Expert 2250 points
    Hello,

    We are also facing same issue in our project. We have tried changing the timeout value to 5msec instead of OSALSEMAPHORE_WAIT_FOREVER, but in that case we are not able to get the server name.

    This results RcmClient_create to loop forever.

    Can you please suggest what can be the reason that we are not able to get the server name?

    Thanks,
    Krunal
  • 0 in reply to Krunal Patel_11
    TI__Genius 12025 points

    Krunal,

    This is an old thread. Please start a new thread with your problem description including which device you are using, software versions of the main component, and a description of your application execution flow. You will have a better chance at getting a response on a new thread instead of posting to an old thread which is marked "Answered".

    ~Ramsey

  • 0 in reply to Ramsey
    Expert 2250 points

    Hi Ramsey,


    We have already created a thread but we have not received any response on  that. Please find the link for our thread

    Thanks,

    Krunal