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.

TMS320F28388D: CPU1 to CM IPC message queue problem

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hi,

I'm experiencing a problem with the slightly modified CPU1<->CM IPC message queue example taken from /C2000WARE_5_00_00_00/driverlib/f2838x/examples/c28x_cm/ipc/ipc_ex2_msgqueue_c28x1.c and ipc_ex2_msgqueue_cm.c.  I converted them to .cpp files to compile as C++.

The example works fine, but after I changed the size of the readData array to anything above 0x80 words, even if I only use 0x80 words to send to the CM, it stops working properly - the CM seems to receive corrupted messages. As I increase the size of the readData further, or declare another data array within the MSGRAM_CPU_TO_CM space without using it, the corruption gets worse that the CM only receives the interrupt, but no valid message.

For example:
#pragma DATA_SECTION("MSGRAM_CPU_TO_CM")
uint16_t readData[0xC0];
My question is: is there any restriction on the use of MSGRAM_CPU_TO_CM memory when using the IPC message queue?
Thanks & looking forward to hearing from you for advise.
Mei.
  • Hi Mei,

    Please allow me to get back to you about this tomorrow.

    Best Regards,
    Ben Collier

  • Mei,

    While investigating your problem, I have uncovered a few issues with our IPC MSGQUEUE examples. There is no limit on the amount of data that you can pass with MSGRAM_CPU_TO_CM memory when using the IPC message queue, except for the size of the message ram. I think your problem should be resolved when you fix the below issues.

    This screenshot shows part of the original ipc_ex2_msgqueue_cm.c file:

    The following parentheses need to be added:


    This change makes sure that the remote CPU (the CM in this case) will increment the address correctly when reading the data. I believe you may have been seeing corrupted data due to your address not incrementing correctly.

    Next, it looks like the start address of the readData array will change when the size of the array is increased beyond a certain point, and it will sometimes move to a place that conflicts with the messageQueue. We recommend the following solution:

    You will then need to make the following change to your linker CMD file:

    This will make sure that the data in your readData array will not conflict with the messageBuffer.

    Please let me know if you are still having an issue after making these changes.

    Best Regards,

    Ben Collier