• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 458 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.

Codec Engine: UNIVERSAL_processAsync / processWait are broken

Stefanos A.
Prodigy 150 points

Other Parts Discussed in Thread: TMS320C6472

This is a continuation of my previous thread here: http://e2e.ti.com/support/embedded/bios/f/355/p/275403/972159.aspx

The problem manifests on my system (TMS320C6472) when running the OCT MIDAS demo (SYS/BIOS 6.35, CE 3.24.00.08, CGT 7.4.4). If I replace this call:

status = UNIVERSAL_process(hOct, &inpBufDesc, &refBufDesc, &outBufDesc, &inArgs, &outArgs);

with a processAsync/Wait pair:

status = UNIVERSAL_processAsync(hOct, &inpBufDesc, &refBufDesc, &outBufDesc, &inArgs, &outArgs);
status = UNIVERSAL_processWait(hOct, &inpBufDesc, &refBufDesc, &outBufDesc, &inArgs, &outArgs, -1u);

the system hangs in the processWait call. The remote servers receive the messages and process successfully, but the replies are either not delivered or are delivered to the wrong queues.

Using ROV, I see the following broken behavior: once a remote server finishes processing, its reply is invariably delivered to the MessageQ with id:1. This occurs even if MessageQ id:1 does NOT belong to the Codec Engine (i.e. if I construct a few queues before so that the CE queues start from id:2, then the messages will still lands in the queue with id:1.)

At this point I am stumped. UNIVERSAL_processAsync/Wait seem to be broken internally.

Ideas welcome.


Edit: some more information.

The first two replies from the remote servers arrive correctly on core 0 (UNIVERSAL_processWait returns). Any reply after that goes to MessageQ id:1 and stays there indefinitely (UNIVERSAL_processWait hangs).

My MessageQ transport configuration, in case it matters, is as follows:

var Notify = xdc.useModule('ti.sdo.ipc.Notify');
Notify.SetupProxy = xdc.useModule('ti.sdo.ipc.family.c647x.NotifyCircSetup');

var MessageQ = use('ti.sdo.ipc.MessageQ');
MessageQ.SetTransportProxy = xdc.module('ti.sdo.ipc.transports.TransportShmNotifySetup');
MessageQ.maxRuntimeEntries = 32;

Trying different transport proxies does not appear to help (if anything, it prevents CE from connecting to the remote servers. The documentation here is kind of sparse for C6472.)

  • 0
    Prodigy 150 points

    More information: if I create my own MessageQ at id:1, I can retrieve the misdelivered _UNIVERSAL_Msgs and forward them to the correct queue:

    // Fixme: terrible hack to forward misdelivered messages inside UNIVERSAL_processAsync / UNIVERSAL_processWait
    MessageQ_Msg msg;
    if (MessageQ_get(context->hack_queue, &msg, 0) == MessageQ_S_SUCCESS)
    {
        MessageQ_QueueId id = MessageQ_getReplyQueue(msg);
        MessageQ_put(id, msg);
    }

    With this hack, UNIVERSAL_processWait completes successfully, as long as the queue depth specified in UNIVERSAL_create is 1 (i.e. UNIVERSAL_create is called with "algorithm_name:::1"). If higher depths are used, then the hack does not work and UNIVERSAL_processWait still hangs.

  • 0 in reply to Stefanos A.
    TI__Genius 12025 points

    Stefanos,

    Sounds like a bug. I will forward you post to the development team. Some team members are on vacation, there might be a delay in getting back to you.

    ~Ramsey