• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 994 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.

CCS/TMS320F28379D: Can CPU2 execute code from globally shared RAM?

Graham Reitz29
Intellectual 960 points
Part Number: TMS320F28379D

Tool/software: Code Composer Studio

When trying to run code on CPU2 from GSRAM it looks like it's ending up in an ITRAP:

 82             LB _c_int00         ;Branch to start of boot._asm in RTS library
        $../F2837xD_CodeStartBranch.asm:82:107$(), code_start:
000000:   004113C7    LB           _c_int00
000002:   0000        ITRAP0       
000003:   0002        POP          IFR
000004:   0000        ITRAP0       
000005:   0000        ITRAP0       
000006:   0000        ITRAP0       
000007:   0000        ITRAP0       
000008:   0000        ITRAP0       
000009:   0000        ITRAP0       
00000a:   13C7        MPYS         P, T, *+XAR7[0]
00000b:   0001        ABORTI

The appropriate registers in MemCfgRegs.GSxMSEL.bit.MSEL_GSn have been set in the CPU1 code, and the linker command file is configured for each core based on the GSnRAM it would like to use.

I'm guessing that CPU2 is trying to run its code before the before CPU1 has set the MemCfgRegs registers???

If CPU2 can execute code from GSRAM I'm not sure how to set it up.

Kindly,

Graham

  • 0
    TI__Guru 55700 points
    Graham,

    Most of the TI engineers are out of office for Christmas and new year holidays. Please expect delay in response till early next year.

    Regards,
    Manoj
  • 0
    Expert 1100 points
    Graham,

    I managed to run some code on GSRAM using CPU2 for a long time ago. What I did is, I modified the CodeStartBranch.asm of CPU2 so that it waits a specific IPCFLAG from CPU1 to load the program. In other words, CPU2 waits CPU1 to gain control of some GSRAMs. On the CPU1 side, I wrote a code that gives the control of GSRAM to CPU2 (using MemCfgRems registers) and sets the IPCFLAG. After setting IPCFLAG, CPU2 continues to load the program and jump to main. This is how I solved this problem.

    Regards,

    Hakan
  • 0 in reply to Hakan B
    TI__Guru** 113835 points
    Hi Graham,

    By default (after reset) GSRAMs ownership is with CPU1 which means only CPU1 code has write/execute permission from all the GSRAMs. CPU1 code need to change the ownership of these specific GSRAM block to CPU2 (by setting MSEL_GSx bit in GSxMSEL register to '1') so that CPU2 can execute from that GSRAM block.

    Mr. Hakan has explained the solution for the same. Please try that and let us know if you still have any further queries on this.

    Regards,
    Vivek Singh
  • 0 in reply to Hakan B
    Intellectual 960 points
    Hi Hakan,

    Did you recall if the modifications to CodeStartBranch.asm you wrote were in assembly? Or is their a way to do it with C/C++?

    Kindly,
    Graham
  • 0 in reply to Graham Reitz29
    Expert 1100 points

    Hi Graham,

    I did the modification using assembly on the CodeStartBranch.asm. Actually, I am not an expert of assembly, what I did is, I wrote the C code on an test project. Then using assembly view of CCS, I got the assembly version of that code. But I have to say that you have to have at least little bit opinion about assembly language in order to pick necessary part of the code. After getting necessary assembly code, I modified the CodeStartBranch.asm using that piece of code.

    You can find how to view assembly version of C code in the link below.
    e2e.ti.com/.../68716

    Regards,
    Hakan