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() returns -1 occasionally.

Hi,

This is how the MessageQ is created without specifying MessageQ_Params:

d_MqHandle = MessageQ_create(d_AppInfo.lMsgqName, NULL);

Questions:

1. what is the synchronizer in this case?

2. MessageQ_get() would return -1 sometimes along with NULL pointer to MessageQ_Msg* d_Msgq, subsequent MessageQ_get() will not get any more msg. What is causing this problem?

3. I tried using MessageQ_count and sleep 200 us before calling MessageQ_get(), but worried about taking too much CPU time using this polling mechanism, is there any better solution to this problem?

Thanks,

Zhao

  • Hi zhao,

    Please let us know the the version details of the IPC package that you are using for your experiments.

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    --------------------------------------------------------------------------------------------------------

  •  

    Hi zhaoLi,

    zhaoLi said:
    1. what is the synchronizer in this case?

    When you use the MessageQ_create() function, there is no synchroniser. The synchronizer instance is used to signal IO completion.

    The synchronizer is used in MessageQ_put() and MessageQ_get(). The synchronizer signal is called as part of MessageQ_put().

    The synchronizer waits in MessageQ_get() if there are no messages present.

    zhaoLi said:
    2. MessageQ_get() would return -1 sometimes along with NULL pointer to MessageQ_Msg* d_Msgq, subsequent MessageQ_get() will not get any more msg. What is causing this problem?

    3. I tried using MessageQ_count and sleep 200 us before calling MessageQ_get(), but worried about taking too much CPU time using this polling mechanism, is there any better solution to this problem?

    By any chance you ran the IPC image processing Master/slave example enclosed in "..\mcsdk_2_01_02_06\demos\image_processing\ipc\evmc6678l\" ?? That example works and you can refer the source code.

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • I am using IPC that is part of syslink_2_00_05_85.
    I know it is kind of old. Since we are migrating to newer Linux kernel and we might have to use new IPC package anyway.
  • Hi Shankari,
    Thanks for your reply.
    What is causing my #2? Why would MessageQ_get() return prematurely with -1, what signal caused it to return?

    We developed this MessageQ when syslink_2_00_05_85 just came out. We used your example of MessageQ and adapted from it.

    I do not know where to get "..\mcsdk_2_01_02_06\demos\image_processing\ipc\evmc6678l\". Please advise.

    Thank you,
    Zhao
  • Hi Zhao Li,

    Zhao Li said:
    I do not know where to get "..\mcsdk_2_01_02_06\demos\image_processing\ipc\evmc6678l\". Please advise.

    Sure.

    Go to this link: http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html

    and download MCSDK version bios_mcsdk_02_01_02_06_setupwin32.exe

    After installing the MCSDK, you will find the image processing demo at the path specified in the previous post.

    Import both the Master and slave example into CCS. Load the master example into core 0 and load the slave examples into other cores and run. This example uses messageQ reader and writer with synchronizer.( I ran the example on C6678 EVM and it works)

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • Hi Shankari,

    Thanks for the link. But at this stage of the product development, my need is to know why it returns with -1 and have a fix in Syslink_2_00_05_85 that prevents MessageQ_get() from returning with error.

    I am using DM8168 with Linux 2.6.37+ kernel on the ARM side.

    Zhao

  • Not sure what side of the core the MessageQ_get() failure is occurring (ARM or DSP).

    If its on the DSP, their is only one scenario that would return MessageQ_get with -1 (MessageQ_E_FAIL).  This is when the synchronizer returns with a failure other than a timeout. In the default case, the synchronizer being used in the Semaphore.  So you must ensure MesageQ_get is being called from a Task context at all times.

    If its happening on the ARM side, you can try enabling tracing for the Syslink driver and the user-level to gather more information.  Take a look at the following:

    http://processors.wiki.ti.com/index.php/SysLink_UserGuide#Configuring_trace

    Source for both IPC and Syslink are provided in the product.

    -  IPC MessageQ source code at $IPC_ROOT/packages/ti/sdo/ipc/MessageQ.c

    - Syslink MessageQ source code at $SYSLINK_ROOT/packages/ti/syslink/ipc/hlos/usr/MessageQ.c

  • Hi Arnie,

    Thanks for the help. It is the ARM side. I will enable the traces. But where will the traces be printed out? Linux console or any Linux log files? I have only SSH into the device running Linux.

    Please advise.

    Zhao
  • Linux console on the user-side. "dmesg" for the kernel-side outputs.
  • Arnie,

    I have followed the setup instructions you sent http://processors.wiki.ti.com/index.php/SysLink_UserGuide#Configuring_trace

    (1)  /sbin/insmod /dev/syslink.ko TRACE=1 TRACEFAILURE=1

    verified in dmesg that syslink trace enabled and syslink SetFailureReason enabled.

    (2) put export TRACE=1; export TRACEFAILURE=1; export TRACECLASS=3; in .cshrc

    verified that "env" has these variables set.

    (3) in "products.mk" under syslink directory, it contains the following:

    # SysLink HLOS driver options variable (choose one): 0 or 1
    #
    SYSLINK_BUILD_DEBUG=1
    SYSLINK_BUILD_OPTIMIZE=0
    SYSLINK_TRACE_ENABLE=1

    (4) products.mk and makefile are attached. We don't change defaults in these files so by default SYSLINK_TRACE_ENABLE is on.

    6746.makefile.zip

    Still there are no traces from the console or dmesg. What am I missing? I guess GT_setTrace() API calls are optional, right?

    Thanks,

    Zhao

  • The enablement of tracing for SysLink looks correct. Can you move to a newer version of SysLink?  I know modification were made to SysLink to ensure proper tracing output.  It may be that your version doesn't have it all.