Hi,
We are using OMAPL138 and ipc_1_25_03_15, bios_6_35_04_50, xdctools_3_25_03_72, syslink_2_21_02_10.
Our applications use Heap_BufMP and MessageQ and follow the example_02 for MessageQ that comes with the Syslink examples. There is a lock step handshake between the two cores after creating Rx MessageQs (RESRDY event), opening MessageQs on remote core (READY event) and then a COMPLETE event. we have prints to log MessageQ name, open success and failures.
The code was executing fine without any problems until now when the problems have started surfacing.
The problem observed is that with prints disabled the ARM fails to open one of the Rx MessageQs created by the DSP. The MessageQ that fails is random. The error happens randomly almost 2 of 3 times.
If we enable few prints that dump the result of MessageQ opening, the MessageQ failure occurrences reduce to about 1 in 10 starts.
If we enable all the prints the MessageQ opening never fails, the ARM is able to open all the messageQ created by the DSP.
In all these failures the ARM is beyond the first RESRDY handshake which implies that DSP was able to create all the Rx MessageQs and sent the RESRDY event to ARM. But still the ARM failed to open the MessageQ.
We have tried combinations of having SR0 on the L3_CBA_RAM and also on the DDR2_Shared with the cacheEnable configuration and the corresponding MAR set for cache enabled and disabled.
We suspect that what DSP writes to SR0 is not what the ARM sees. This failure happens even when the SR0 is set in L3_CBA_RAM with SR0.cacheEnable set to false and the MAR register is cleared.
What else could be missing? What configuration on the ARM side should we check or configure differently?
Thanks in advance,
Taran Tripathi
