Here is a break down of a typical usage case for the IPC-Lite drivers: First, the sending processor will call a command function. In this example, the M3 is the sending processor and is executing the “IPCLiteMtoCDataRead” function. IPC_FLAG2 is the C28 interrupt flag that will indicate to the C28 that a message is available. I PC_FLAG17 is the response flag that the C28 will use to indicate the command has been processed. The C28 address to read from has also been passed in as a parameter. The function is called in a loop because it will return STATUS_FAIL and not send the message to the C28 until MtoC IPC interrupt 2 and flag 17 are available, after which it will return STATUS_PASS. Second, the receiving processor will decode the command in its IPCCOM register within the ISR. In this example, C28 MtoCIPCINT2 ISR would see that its flag is set, decode the command in the MTOCIPCCOM register, and recognize that a read command was sent. Third, the receiving processor calls the function with the same name as the sending processor’s command function. The C28 would also execute a function called IPCLiteMtoCDataRead, and pass in IPC_FLAG2 as the interrupt flag parameter and IPC_FLAG17 as the status flag parameter. Fourth, if the command received by the function is valid, the driver function processes the read command and acknowledges both the status and interrupt flags. If the command happened to be invalid, only the interrupt flag is acknowledged to free the interrupt for future commands, and the status flag remains set. Fifth, when the sending processor wants the data or result of the function, it will call the “Get Result” function which passes in a pointer to either a 16-bit or 32-bit value to read the result into once it sees that the status flag has been acknowledged. The reason there is a separate GetResult function instead of waiting in the main command function for a result is so that the sending application is not blocked while waiting for the receiving processor to respond before performing any other actions. In this way, the sending processor can send one command and perform other tasks before coming back to get the data when it is needed. Finally, when the interrupt and status flags have been acknowledged or cleared, the sending processor can send a new command.