MessageQ E_Timeout, message vanishes

Hi RC,

What timeout value are you using? Is it long enough? You can use ROV to see if there is a message sitting on core 0.

Todd

Hi Todd,

               I used the following

1. core0_status3 = MessageQ_get(messageQ, (MessageQ_Msg *)&MyMsg3, MessageQ_FOREVER);

2. Then i used

do
{
    core0_status3 = MessageQ_get(messageQ, (MessageQ_Msg *)&MyMsg3, 0);

    Task_sleep(1);

}while(core0_status3 < 0);

This loop will continue to run infinitely, if i stop in between [with some additional code], i see the status as -6.

3. at Core0, if i stop the control after messageq_get, i see the ROV for MessageQ has no message at all.

As i told, the second situation [situation 2 in earlier mail/post] works.what can i decode from that..[this is something related to timing] ??

Another experiment, what i did is instead of "MessageQ_FOREVER" for messages from CORE1 and CORE2, i put Null [no wait], i see the status as -6, so what i understand is i tried to fetch message, even before they were put. correct me if i am wrong.

Thanks

RC Reddy

Hi Todd,

             under what situations can that issue happen, please let me know the possible situations which can't GET A MSG whereas PUT MSG has happened successfully. I am using HeapMemMP

1.

WRITER CORE --> Open() --> Alloc() --> put() --> close()

READER CORE --> Create() --> get() --> free() --> delete()

Another doubt what i have, is there some synchronization required between MSG CLOSE (at Writer Core) and MSG GET (at Reader Core). In my case, i am not ensuring that Writer core is closing the MSGQ only after Reader Core has read it. will that affect in anyway?

Thanks

RC Reddy

Clarification...You are using MessageQ and not MSGQ...correct? MSGQ is part of BIOS5 and is not compatible with MessageQ.

MessageQ_close has no impact on MessageQ_get.

Hi Todd,

             Sorry for confusion, i am using MessageQ mechanism [Module, which is part of IPC].

Thanks

RC Reddy

RC,

Why do you have a timeout of 0?  A timeout of 0 means that the MessageQ_get() will return immediately which is why you get a timeout error code.  Now, if a message was actually available before the MessageQ_ge() then you wouldn't get a timeout error code return.

If you want to wait until the remote processor sends you a message, you need a timeout of FOREVER since you don't know when the remote processor is sending you a message.

Judah

Hi Judah,

               please look at my post carefully, I did both experiments [which includes MessageQ_FOREVER also] and it never comes out of the loop [it is stuck in INFINITE Loop] and if i use cache_disable(), it helps me in getting the issue solved.

the behaviour is same on simulator and board also. I feel this is a genuine bug [since the PUT is succesfull and GET is still waiting in INFINITE loop ][only cache disabling is helping, which i think is incorrect in my opinion]. please let me know further on this.

Thanks

RC Reddy

RC,

I might be a little bias here but, I've ranned 100s of messageq tests across different devices so I'm confident there is no bug in messageq.  Make sure your sharedregion from which you you created your heap has cache enabled set to be 'true'.

Which Heap*MP are you using?  Ideally for MessageQ you want to use HeapBufMP.

What device are you running on?  Assuming its one of the EVMs TI provide, If its not an issue...maybe attach your executable to this thread.

Is your program pretty basic as you describe...create a heap, create a messageq, open heap, open messageq on other cores...send messages back and forth?

Judah

RC,

Are you resetting the cores between test runs, either a CPU reset, a System Reset, or a hard reset?  Also, are you running the EVM GEL file that comes with CCS to set up the system peripherals and memories?  If you're not running the GEL file you will experience odd memory performance.

Which EVM are you using and which version of CCS?