• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 596 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 MessageQ_free hangs DSP on OMAPL138

Ed Willson
Prodigy 60 points
Other Parts Discussed in Thread: OMAPL138

We are using SYS/BIOS 6.35.04.50 and SYSLINK 2.21.01.15 on an OMAPL138 dual core platform. Following various examples from TI's MCSDK and other sources, we have written applications to run on the DSP and ARM.

We use Notify as a synchronisation mechanism and MessageQ to pass data both ways between the ARM and DSP. On the DSP we have a SYS/BIOS task dedicated to handling the MessageQ - it sits blocking on a MessageQ_get call with timeout set to BIOS_WAIT_FOREVER and processes any messages which arrive. When we are done with the message acquired from MessageQ_get, we call MessageQ_free (as stipulated). The messages are allocated dynamically on the ARM side using MessageQ_alloc and sent to the DSP using MessageQ_put.

The issue I have come across is that the MessageQ_free call appears to hang permanently on the DSP. I have checked for double-frees and similar issues but can see nothing obvious. The code has previously worked which suggests this may be a marginal effect.

What might cause MessageQ_free to hang in this way? I have looked through the source for SYSLINK and it appears to call Memory_free, but unfortunately this function is redirected into SYS/BIOS and xdc to the point where I cannot find the actual called code.

Any help would be appreciated.

  • 0
    TI__Mastermind 22760 points

    Hi Ed,

    MessageQ_free() will call Memory_free(), which then frees the memory from the heap that you registered with MessageQ.  This would probably be HeapMemMP or HeapBufMP.  These heaps use a GateMP gate when allocating and freeing memory, so I'm guessing that your call to MessageQ_free() may be stuck in GateMP_enter().

    If you did not create your MessageQ heap with a gate, the default GateMP gate, which is used in many places, will be used for you MessageQ heap.  You might try creating a GateMP gate and setting your HeapBufMP_Params.gate (or HeapMemMP_Params.gate) to this gate.

    Best regards,

        Janet

  • 0 in reply to janet
    Prodigy 60 points

    Thanks for getting back to me Janet,

    Those are the lines along which I was thinking too. As it happens I have now tracked this down. Whilst I had reserved space at the beginning of the structs I was sending for a MessageQ_MsgHeader, I was overwriting the header with uninitialised data, as I had not realised that calling MessageQ_alloc initialises those bytes!

    Perhaps a note could be added to the documentation for MessageQ_alloc - I only figured this out by reading the MessageQ_staticMsgInit documentation.

    Thanks for your help,

    Ed

  • 0 in reply to Ed Willson
    TI__Mastermind 22760 points

    Ok, thanks for the suggestion regarding documentation.

    Best regards,

        Janet