• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 412 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/TMS320F28377D: CPU2 *.out Load Corrupts RAM used by CPU1

CCS/TMS320F28388D: Some locations in RAMGS are corrupted when loading a program on CPU2

Nicholas Langrind
Prodigy 240 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: TMS320F28377D,

Tool/software: Code Composer Studio

Hi,

I have a dual-core f28388 project, with one project for CM and another one for CPU2. Each core executes from Flash. I recently added a CPU2 project (which also executes from FLASH), and I have run into trouble. It seems that the act of loading CPU2 in CCS causes initialized data in RAMGS to be corrupted. The initialized data comes from the CPU1 .out file. The CPU2 .out file has no references to the area of RAMGS that is being corrupted.

The issue appears to be identical to the "CCS/TMS320F28377D: CPU2 *.out Load Corrupts RAM used by CPU1" issue. I followed similar procedures to prove (or at least strongly suggest) that it is the process of loading/starting CPU2 that causes the problem, not running it. Furthermore, if I detach CCS and power cycle my board (which is a 28388D Control Card) then it boots and runs fine, and the problematic area of RAM GS is fine.

I tried following the solution presented in "CCS/TMS320F28377D: CPU2 *.out Load Corrupts RAM used by CPU1" but it didn't help. After CCS loads the projects, they are all stopped at the "codestart" section, and the memory is still corrupted.

The locations 0xD2AE-0xD2C7 and around 0xD10A. There could be more, these are just the ones I've noticed.

Thanks for any help!

Best Regards,

Nik

  • 0
    Prodigy 240 points

    Hi,

    I'd like to correct the previous post: the first sentence should say:

    I have a dual-core f28388 project, with one project for CM and another one for CPU1.

    (in other words, CM and CPU1 were happy together until CPU2 came along.)

    Also, I am using CCS 10.1.0.00010 on Windows 10.

    Best Regards,

    Nik

  • 0 in reply to Nicholas Langrind
    TI__Guru** 115271 points

    Hi Nik,

     I recently added a CPU2 project (which also executes from FLASH), and I have run into trouble. It seems that the act of loading CPU2 in CCS causes initialized data in RAMGS to be corrupted. The initialized data comes from the CPU1 .out file. The CPU2 .out file has no references to the area of RAMGS that is being corrupted.

    If you are loading the code in flash then flash plug-in uses GSx RAM to load the API hence that will overwrite the value in GSx RAM. You should not have any application data/code in GSx RAM before loading the code in CPU2. 

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 240 points

    Hi Vivek,

    Thank you for the quick and clear response.

    Is it also true that loading CPU1 will do the same thing, therefore if my CPU2 program were to have initialized data in GSx RAM, I would face a similar issue?

    The reason I ask is that I am trying to visualize a workflow for starting up the debugger with all three cores. Currently I have a Debug configuration (TMS320F28388D.ccxml) that loads all three cores, which is nice in theory because one click on the little bug icon sets up the environment for debugging.

    Now I am thinking that I have to do a few steps - launch the debug configuration, load whichever core(s) that I have rebuilt the .out file, load symbols on the other cores, and restart all three. Does that sound like the simplest viable sequence?

    Thanks again for your help.

    Nik

  • 0 in reply to Nicholas Langrind
    TI__Guru** 115271 points

    Hi Nik,

     Is it also true that loading CPU1 will do the same thing, therefore if my CPU2 program were to have initialized data in GSx RAM, I would face a similar issue?

     

    That is correct. Are you loading code in flash as well as GSx RAM also ? If yes, then that should be avoided because that will not work when you run standalone (without CCS). If not then you just make sure you do not initialize the GSx RAM in application will all the core get loaded. You can do that vis IPC handshake. 

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 240 points

    Hi Vivek,

    No code in GSx RAM, just initialized data. I understand what you are saying. I don't quite know how I want to proceed, but the gist is that __TI_cinit_copy_table is processed in my program's by run_cinit(), and all I have to do is ensure that this is run after the last time the flash plug-in runs. An IPC handshake, as you said, is a good way too coordinate the two cores.

    And in any case, I am able to use the debugger with all three cores reliably now, because of your advice.

    Thanks for the help.

    Sincerely,

    Nik