Previously there was an unfair expectation that was put on the MCU by the xTPInterpreter implementation. This expectation was that any request sent from xTPInterpreter to another core would block on that send, and the next line would already have the response to the query. xTPInterpreter has been updated to be send messages without the expectation of immediate response. It now expects ‘XTP_NO_RESPONSE’ to be returned by any core IPC message, and the actual response to come back from the core on a separate thread (which will make its way to xtpInterpreter’s sendMessage function).
Flow:
IxTPInterpreter => m_IPCInterfaces[coreID]->sendMessage => platform IPC => AudioCore->onXTPMessage()
ReturnFlow:
AudioCore->onXTPMessage()[return value] => platformIPC => IxTPInterpreter->sendMessage()
When sending to the core from xtpInterpreter platform IPC should return XTP_NO_RESPONSE unless there is some actual error in sending the IPC message – it can return some error code in this case (or generically xAF_FAILURE).
After processing an XTP message on the core (the context is within the receive method in platform IPC code) if the message length (msgBuf.msgLen) is > 0 then this message should be sent back to the MCU. The return value of the function can be either xAF_SUCCESS, or some error. In the case of an error the error has already been encoded into an xTP error response – but the platform can use this error for logging as well if they wish. XTP_NO_RESPONSE should not be expected here as the core should return any unhandled commands as an error (in AudioCoreBase).