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.

TMS320F28379D: Cannot pass value from IPCRECV register to variable

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello,

I am trying to set up communications between CPU1 and CPU2 with the IPC. For that, I set up a test variable called Message1 in CPU1 and Message2 in CPU2, which is incremented at a 50kHz rate.

Message1++;
IpcRegs.IPCSENDCOM = Message1;
IpcRegs.IPCSET.bit.IPC1 = 1;

The above code is inside an ePWM ISR in CPU1 that executes at 50kHz. There is an equivalent piece of code in another ISR in CPU2 that executes at a similar rate. But the CPU2's IPC code sends the data to IPCSENDDATA instead of IPCSENDCOM.

Message2++;
IpcRegs.IPCSENDDATA = Message2;
IpcRegs.IPCSET.bit.IPC0 = 1;

In the IPC0 ISR, I have wrote the following (for the CPU1 portion):

PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;
IpcRegs.IPCACK.bit.IPC0 = 1;
TestIpc1 = IpcRegs.IPCRECVDATA;


TestIPC1 is a storage variable for the data that was sent over from CPU2 to CPU1. I also wrote this code in CPU2 for IPC1 ISR

PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;
IpcRegs.IPCACK.bit.IPC1 = 1;
TestIpc2 = IpcRegs.IPCRECVCOM;

The good thing is that the communication from CPU2 to CPU1 works and I can see that TestIpc1 receiving the value of Message2 that was sent over. However, CPU1 to CPU2 doesn't seem to work as TestIpc2 is not changing at all, even though Message1 increments properly.

I wanted to check if IpcRegs.IPCRECVCOM was not changing so I checked it, and surprisingly it was changing. I think this means that the communication itself from CPU1 to CPU2 was working properly.

I also checked if CPU2 was ever arriving to the IPC ISR, and it does arrive to the ISR and it executes everything. But I could notice that the value of IpcRegs.IPCRECVCOM was not getting passed to TestIpc2 even when I clearly stepped through that line.

Long story short, I cannot get CPU2 to pass value from IpcRegs.IPCRECVCOM to another variable (or IPCRECVDATA or IPCRECVADDR for that matter). Do you recognize this bug?

Thank you,

  • Hi,

    Let me know if I got you right. You were able to get the IPC ISR on CPU2 core and you could also see the correct value in IPCRECVCOM register on CPU2. But the reading and assigning that to TestIpc2  variable is not happening. Is that right?

    Could you tell me in which RAM section is TestIpc2 present and whether it is configured to have CPU2 as master?

    Regards,

    Veena

  • Dear Veena,

    Thank you for the quick reply. Yes, you understood it right. I think the IPC itself works, but I cannot pass value from from the RECV register to the variable. But not just from the RECV register, TestIpc2 could not be modified in any way from CPU2. I was trying to figure out how to see which RAM section the TestIpc2 is present in, but I could not find out how to. Could you tell me how I can view it?

    I thought that the problem pertained only to the IPC register and the TestIpc2 variable. But I have noticed that I cannot modify any of the global variables declared in CPU2 and not just TestIpc2, so it looks like we have a much larger problem at hand right now than what I have originally thought. An interesting thing is that when I assign one of the variables in the CputoCla1MsgRAM data section with DATA_SECTION pragma, the variable can be modified.

    I feel like the data section where all of the global variables are being assigned to is either full, not given permission for R/W for CPU2, or just plain not been allocated any memory...

    Thank you,

    Yoon

  • Hi,

    I hope you are aware of the various RAMs available in the device - LS RAMs GSRAMs, MSGRAMs etc. If you are not, kindly go through the TRM on understanding which master have access to which RAMs.

    The allocation of variables of memories is done via linker command files. It depends on whether that variable is a global variable or local variable. If it is global variable, you can find the exact address in the .map file. If it is a local variable, it goes to stack.

    If you are using GS RAM (Global hared RAM) for that variable, you need to make sure that CPU2 has write access to it. By default CPU1 owns the GS RAMs and CPU2 does not have write access to it. You can refer to the dual core examples available in C2000ware on how to configure it.

    Regards,

    Veena

  • Dear Veena,

    I have a superficial understanding about the various RAMs and memory sections. I will definitely study more about them on the TRM as you suggest.

    I had checked the linker command file and I found out that it was derived from an example linker file from C2000Ware called '2837xD_FLASH_CLA_lnk_cpu1.cmd'. The linker file was modified to some degree where some program RAMs and data RAMs were given overlapping space. After fixing this and reassigning the SECTIONS appropriately, the problem was solved. Still, I do not know why this would have been the cause to the problem. Maybe the data RAMs were not allocated properly because program RAM was already taking its place. At any rate, I will try to figure out why exactly this had happened.

    Thank you so much for your help!

    Sincerely,

    Yoon