• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 280 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28386S: IPC Memory Shared between CPU1 and CM.

Ramon Martins
Prodigy 121 points
Part Number: TMS320F28386S
Other Parts Discussed in Thread: SYSCONFIG

Hi there,

I am programming a prototype to share data between the CPU1 and the CM(Communication Manager), for that the SDK via driverlib provides support for Message Queue, using the same global data declaration in both cores.

On example "ipc_ex2_msgqueue_c28x1" this works fine, but putting more global data with the same principle to share more data, appears a problem the C28x allocates the memory with a alignment of 128 bytes (64 words), while the CM seems don't use any alignment, additionally the order which is allocated the data in the memory changes with the size of the global data, with a other global declaration large enough witch isn't multiple of 128 bytes the struct on memory of C28x appears with a offset relative with the CM core. See the images:

(IPC_CM_to_CPU1_GetBuffer_QPC is my global struct on memory shared between CPU1 and CM)

My data = 248 bytes

CM:

C28x: (As you can see the struct provided by the driverlib has a size which isn't multiple of 128 bytes)

MyData = 992 bytes:

CM: (the data change the order)

C28x: (in this case the driverlib IPC will not work)

I have tried to change the ALIGN of the section in the CM command file, but it didn't work, in C28x i am using the sysconfig to configure the command file, therefore i can not change nothing about the CM_TO_CPU_MEMORY_SHARED section because there is no option for this on sysconfig,

So... can i declare global variables on memory shared or i have to make it only locally? Is there any way to know where the data will be allocated? I already tried to change the align of this SECTION on CM using the parameter ALIGN(128), but there is no change on the result, any suggestions to do this?

Thank you for your guidance.

Ramon Martins.

  • 0
    TI__Mastermind 32015 points

    Hi,

    I would recommend you define the C28-CM data in C28 application and CM-C28 data in CM application only. While sending IPC message, you can pass the address of the data to be shared to the other core. If you use IPC_ADDR_CORRECTION_ENABLE flag, the function will translate the C28 address to CM address or vice versa. Note that this is feature is only supported if the data is placed in C28-CM or CM-C28 MSGRAM.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Prodigy 121 points

    Hi Veena,

    Thank you for your answer.

    The problem is that the driverlib doesn't use this resource to define its variables. So, as I said, when I declare a global variable (large enough) on memory shared, the address that the compiler chooses takes the place of the ipc's buffer one. The ipc.c source file assumes that the buffers will be placed on the same place on both cores without verification or correction. One time this address is used by a const struct, any corrections that I would make are impossible (without changing the source file by myself, which I would NOT do). I tried to use the #pragma LOCATION to make sure of the ipc's buffer's address, but this directive doesn't seem to work well on the CM side.

    PS: About my code, I understand that, in fact, the best practice is to use the proper registers to share the addresses, and this was a "Hello World" program for my application.

    Thank you again for your time.

    Best Regards,

    Ramon Martins.

  • 0 in reply to Ramon Martins
    TI__Mastermind 32015 points

    Ok, Understood.

    Driverlib expects the driverlib defined buffers to be placed at the 0th offset in the respective RAMs. If compiler is assigning it to a different address, you may assign them to hardcoded address

    Regards,

    Veena