We have been using MessageQ components for some time to share messages between the ARM and DSP cores on the Keystone II. Recently we discovered that with heavy usage, we are occasionally seeing both corrupted messages and queue dropouts (MessageQ_put from DSP is being called, MessageQ_get on ARM stops seeing messages). We are looking over our configuration and initialization.
First, we have not been calling Ipc_start() from the DSP, but only from the ARM. According to the documentation, we would expect that MessageQ would not function this way, yet it has, to a large degree.
Second, including a call to Ipc_start() in the DSPs' main.cpp gives us the following linker error:
Undefined Symbol:
ti_ipc_transports_TransportRpmsgSetup_sharedMemReq__E
Reference in file:
C:\Users\mcobb04\Documents\SVN_Checkouts\working\sw\DSP\projects\Standard\Debug\configPkg\package\cfg\app_pe66.oe66
The following lines from our .cfg seemed most relevant:
var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ');
var VirtioSetup = xdc.useModule('ti.ipc.transports.TransportRpmsgSetup');
var NameServer = xdc.useModule("ti.sdo.utils.NameServer");
var Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion');
Cache.setMarMeta(0xA0000000, 0x0FFFFFFF, 0);
xdc.loadPackage('ti.ipc.ipcmgr');
BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');
var params = new HeapBuf.Params;
params.align = 8;
params.blockSize = 512;
params.numBlocks = 256;
var msgHeap = HeapBuf.create(params);
MessageQ.registerHeapMeta(msgHeap, 0);
xdc.loadPackage('ti.ipc.transports').profile = 'release';
MessageQ.SetupTransportProxy = VirtioSetup;
Does it make sense that we are getting some message functionality without Ipc_start, perhaps through IpcMgr_ipcStartup()? Is Rpmsg the appropriate transport for ARM->DSP?
We are using the TCI6638K2K EVM (I realize that TCI is supported through FAEs, but we are only using the broad market functionality of the chip -- it is what was available),
IPC version 3_22_00_05