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.

MCU-PLUS-SDK-AM243X: MCU-PLUS-SDK-AM243X: Is there a fix for Does IpcNotify have a problem when messages are sent from both sides at once?

Part Number: MCU-PLUS-SDK-AM243X

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1286480/mcu-plus-sdk-am243x-does-ipcnotify-have-a-problem-when-messages-are-sent-from-both-sides-at-once/4888944?tisearch=e2e-sitesearch&keymatch=RPMessage_vringPutEmptyRxBuf#4888944

I have the same symptoms (Processor stuck on RPMessage_vringPutEmptyRxBuf:IpcNotify_sendMsg(remoteCoreId, IPC_NOTIFY_CLIENT_ID_RPMSG, rxMsgValue, 1 /* wait for message to be posted */ );

I guess the assumption that one can wait for the message to be posted without any other check or action is not realistic?

Is there a fix for this?

  • I've worked around this issue for the cases where it presents during debug sessions by reducing vring size to 4 so that the mailbox is not overwhelmed when processor operations are resumed. I have a large asymmetry in processor update rates and capacity usage though so I have to restore the vring depth when not debugging.

    The processor of `remoteCoreId` is not paused during debug. I have not investigated why the interrupts to check and clear the mailbox stop firing for it if the mailbox gets full. 

    Regardless I feel that unless the blocking IpcNotify_sendMsg is fixed, I will need to patch in my own implementation. Having one CPU fail (block) because another is not clearing the messages in its mailbox is too fragile for deployment.