• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 2068 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.

CCS/TMS320F28377D: CPU2 *.out Load Corrupts RAM used by CPU1

Stuart Baker
Genius 10620 points
Part Number: TMS320F28377D
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

I'm experiencing and issue whereby I have a large SYS/BIOS program splits the usage of global shared ram between CPU1 and CPU2.  It looks as though the act of downloading CPU2 is corrupting RAM utilized by CPU1 for BIOS stack/heap usage, presumably one of the global shared RAMs.

We have verified through the respective output *.map files that there is no unintentional overlapping of CPU1 and CPU2 for any of the global shared ram.  There is a small piece of intentionally overlapping RAM in GS12 RAM.

We believe that the CCS tool is writing to global shared RAM used by CPU1 (stack) when CPU2 is loaded with its respective *.out file.  We have the following test results leading us to that conclusion.

  1. Load CPU1, run to main()
  2. Load CPU2, run to main()
  3. Resume execution on CPU1
    1. Observe an abort during the stack check of the idle thread()
  4. Restart CPU1 no abort() is observed, start CPU2
    1. System runs normally, no abort, everything good
  5. Load CPU2 (CPU1 still running)
    1. CPU1 aborts during the stack check of the idle thread()

Is it possible that the CCS debug tool is writing over some of our shared ram when loading CPU2?  How do we prevent this?  Is there a GEL file setting we should change?

Thanks,

Stuart

  • 0
    TI__Genius 10620 points
    I forgot to mention, the version of CCS being used is 7.2.0.

    Thanks,
    Stuart
  • 0 in reply to Stuart Baker
    TI__Guru* 87145 points
    FYI for others: This issue is being handled offline since the user approached our FAE. We will update the thread later with details.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 10620 points

    I would like to provide some closure to this thread.  Thank you to the individuals who worked behind the scenes to come to a resolution.  The issue here is that the CCS debugger uses shared RAM as a scratchpad when downloading into FLASH memory.  As it turns out, we are using some of this shared memory for our stack on CPU1, and the process of downloading to CPU2 was writing over the CPU1 stack corrupting it.

    The reason that shared RAM is used is that other portions of dedicated CPU specific RAM that could be used have the possibility of being securely locked down, and therefore not guaranteed to be available to the debug tools.  In addition to shared RAM, the debug tools also make use of M0 and M1 RAM.

    I want to note that it is not a valid strategy to simply avoid a specific shared memory region in a given application.  This is because, though internal to TI, we know what shared memory regions we use today, it is possible that these could change or expand over time in order to add additional debug features down the road.

    The proper solution in this case is to disable the "auto run" feature in the debug settings for both CPU1 and CPU2.  In this way, the CPU execution (to main for example) will not begin until after the debugger is finished using shared memory.  These settings can be found in the debug configurations menu:

    I do want to make one additional note as a reminder.  In the C2000 architecture, the stack must be placed into RAM addresses that are in the first 16-bits of the address space.  In the case of this specific issue and debugging, this was already the case, but I wanted to note it anyways in case someone comes across a similar issue.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Guru* 87145 points
    Stuart,

    Thank you for posting the details based of our offline debug.

    For those users that copy some data from Flash to RAM or initialize some RAM even before reaching main(), we always suggest to load the images on both banks before executing the application (even to main).

    Also in this post, I would like to mention that, CCS On-Chip Flash Plugin and UniFlash tools (like many third party tools) are developed for a fully Flash-embedded application, which should be a standalone program that has all the initialized sections linked to flash. Any code that needs to be executed from RAM should be copied from Flash at run time.
    This info is given in TRM.

    Thanks and regards,
    Vamsi