• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 726 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CCS/TMS320F28379D: Problems in dual-core programming at CCS 8.0

TMS320F28379D: problem with shared GS memory between cores

ken hutchinson
Prodigy 195 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello,

I'm trying to create an array on core1 that is r/w and r/o for core2. Another array for the other direction. It runs, and I can modify the memory with the debugger, but the two cores won't modify the memory while running.

In both linker scripts I have:

CPU1TOCPU2_GS : > RAMGS8, ALIGN(4)
CPU2TOCPU1_GS : > RAMGS9, ALIGN(4)

In core 1 I have:

uint32_t CPU1_TO_CPU2_Array[128] = { 0U };
#pragma DATA_SECTION(CPU1_TO_CPU2_Array,"CPU1TOCPU2_GS");
uint32_t CPU2_TO_CPU1_Array[128] = { 0U };
#pragma DATA_SECTION(CPU2_TO_CPU1_Array,"CPU2TOCPU1_GS");

then in a timer interrupt:

    CPU1_TO_CPU2_Array[0]++;

Something similar in core2 to increment     CPU2_TO_CPU1_Array[0]

In core 1, I also try to init and configure the memory:

MemCfg_initSections(MEMCFG_SECT_GS8 | MEMCFG_SECT_GS8);
while(MemCfg_getInitStatus(MEMCFG_SECT_GS8) != 1);

MemCfg_setGSRAMMasterSel(MEMCFG_SECT_GS9, MEMCFG_GSRAMMASTER_CPU2);

/*   tried it this was as well,
EALLOW;
MemCfgRegs.GSxMSEL.bit.MSEL_GS8 = 0; // CPU1 can Read/Write; CPU2 only Read
MemCfgRegs.GSxMSEL.bit.MSEL_GS9 = 1; // CPU2 can Read/Write; CPU1 only Read
EDIS;
while(!(MemCfgRegs.GSxMSEL.bit.MSEL_GS9 == 1 && MemCfgRegs.GSxMSEL.bit.MSEL_GS8 == 0));
*/

Same result with many permutations. The debugger works ok, the program doesn't modify memory. Any ideas what I'm missing? 

thanks

  • 0
    TI__Guru* 82710 points

    Ken,

    Thanks for reaching out to the C2000 E2E forum.  The debugger may be using a different access path, that bypasses the ownership semaphores so that would explain why you see that working(I need to double check this).

    In terms of your code, this looks correct to me as well, the only thing that should need to get modified is the MSEL from CPU1 side as you have done.

    I would add to make sure that in CPU2 you have the same "while" statements looking for the MSEL bits to resolve before using them.

    We have an example of RAM control in C2000Ware in both driverlib and examples here:

    C:\ti\c2000\C2000Ware_3_04_00_00\driverlib\f2837xd\examples\dual\ram (driverlib)

    or

    C:\ti\c2000\C2000Ware_3_04_00_00\device_support\f2837xd\examples\dual\RAM_management (bitfield style)

    I'd suggest building either of these projects and making sure those work correctly on your target.  We can backtrack and see if there are any other difference between this and your code that may not be obvious(device inits, etc).

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 195 points

    I have found two problems and my issue is resolved.

    First was I started with the dual axis project which must have been based on a different C2000. For F28379D, the memory map in the linker file has some subtle differences. My program was too large for the generic CMD file, but after fixing the MEMORY regions, I could play around with the SECTIONS and got it to work. I found sometimes I don't get an error, but it won't run if there isn't enough space in sections like .data and .sysmem. This could use some improvement or a better way to ensure things fit (let me know if there is such a thing)

    Second error was for core2, my program was too big for RAMLS, so I used the RAMGS not used by core1. I didn't realize that core1 must also set MemCfgRegs.GSxMSEL.bit.MSEL_GSx bit for any RAMGS section used for .text by core2 (ie not just what is used for data, also for execution). Then ensure this is set before core2 tries to run. I'm not sure how this will work once I switch from jtag to flash.

    for core2, what SECTIONS must be non-GS ram for it to run enough to wait for the MSEL state?

    thanks

    Ken

  • +1 in reply to ken hutchinson
    TI__Guru* 82710 points

    Ken,

    Thanks for the update; I know for the .ebss and .const sections the linker will throw an error but I will need to see if the same is true for the .data/.sysmem sections.  From your post it sounds like it builds and loads, but then the code gets in the weeds due to not enough memory. The size of these sections for you is static, correct?  I know we run into this with variables like the stack which can overflow if there are too many calls before a return.  We have some memory analysis tools in CCS to help ID stack usage, but that would be post build run/.

    For CPU2 since you will be booting from flash you would just be constrained to wait for MSEL those sections that need to be copied to GS RAM before running.  Thinking about this, the only reason we copy over from flash to RAM is to take advantage of the faster access time/less WS that RAM gives over flash, so we're likely only talking application code vs setup/init type code anyway.  I would say let the flash code take care of all the housekeeping type functions(WD disable, setup the PLL, etc) and then check MSEL after all that is over so you don't waste time doing it after.  

    Let me know if the above needs more clarification.

    Best,

    Matthew