• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1059 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.

Loading *.out using CCS and a debugger

Venkatasai Thotakura
Intellectual 460 points

Hi,

I've couple of questions regarding the debugging environment of CCS, it would be helpful in solving my other issue.

1. Does loading a *.out using CCS and a debugger load it in to RAM, If yes while executing it starts from 0x0000 location which generally we suppose to be in ROM (Does any virtual memory mapping take place to the RAM so that it can accommodate the whole image (.out)?

2. One more case would be like if RAM of a board is less than the flash memory of it (generally I think this is the case) and if the .out which we want to debug is greater than the RAM size and fits in FLASH (of course) how does this kind of scenario work?

3. Does resetting and reloading(the .out) would clear the RAM contents like variables?

Cheers

  • 0
    TI__Guru**** 171004 points

    Hi,

    I am not 100% sure if I completely understand your questions 1 and 2 above, but I have the following comments:

    The location of the various pieces of your firmware (code, data) is entirely defined by the user-configurable linker command file - either in Flash or RAM.

    Likewise, the entry point of the code (what address/symbol it starts executing) is defined by the linker option --entry_point (by default it is set to the symbol _c_int00 that points to the beginning of the runtime support library).

    Virtual memory is something entirely dependent on the device used and it is usually not turned on by any ROM or runtime support library routines. Since you mentioned Flash memory, I suppose you are using a microcontroller which really does not have such virtual memory mechanisms.

    Good references about the linker command file, its influence in placing code and how the debugger works are shown in the links below:

    http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer

    http://processors.wiki.ti.com/index.php/Debug_Handbook_for_CCS

    Regarding question 3: NO if you are using the COFF binary format, but YES if you are using ELF. All un-initialized variables are automatically initialized to zero when using ELF.

    Hopefully I addressed your questions,

    Rafael

  • 0 in reply to desouza
    Intellectual 460 points

    Hey desouza,

    Let me add some points to my questions,

    1. Where does the .out which we load using CCS (with the help of a debugger) sit in, RAM or FLASH?

    If the loaded .out sits in RAM, then

    2. In most of the cases where the size of the .out can be higher than the storage capacity of RAM (which can comfortably sit in FLASH), how the size issue is dealt? As we have to debug from RAM according to my understanding, Is any algo/technique that's internal to CCS dealing it?

    Thanks for the links :) , I know how the linker command files work, my question is specific to while loading .out using CCS but not where the .text and .bss and others go while FLASHED (which's defined in Linker CMD file).

  • 0 in reply to Venkatasai Thotakura
    Guru 192875 points
    Hi Sai,

    First of all I guess you know that while building and debugging a program.... during that time itself you'll get to decide whether you need to go for Flash or RAM based code. If your code is huge and cannot accommodate in RAM (when your project is configured for RAM) then you'll get the code size error. Hence you need to shift to Flash configuration immediately. Once the .out file is generated, it knows where to run from as the configuration had been selected previously while building the code itself. Also, this is done by modifying the linker file and main code.
    So.... its not like - every time you load any out file it will go and load always in RAM or Flash.

    Regards,
    Gautam
  • 0 in reply to Venkatasai Thotakura
    TI__Guru**** 463421 points

    Sai,

    Venkatasai Thotakura said:
    1. Where does the .out which we load using CCS (with the help of a debugger) sit in, RAM or FLASH?

    This is controlled by your linker command file (which specifies the memory regions on the target (like RAM or FLASH) and where the code gets loaded). Specifically the SECTIONS directive in the Linker Command File Primer link that Rafael already mentioned. If you are familiar with how linker command files work, then you are familiar with this already. When you load the out file with CCS, the loader will read the debug information in the out file (generated by the linker) to determine where to load all the code sections in memory (specified by the linker command file)

    Venkatasai Thotakura said:
    2. In most of the cases where the size of the .out can be higher than the storage capacity of RAM (which can comfortably sit in FLASH), how the size issue is dealt? As we have to debug from RAM according to my understanding, Is any algo/technique that's internal to CCS dealing it?

    This is controlled by the linker command file (which specifies where in memory the code sections are loaded and how big those memory regions are (like RAM) ) and the debugger memory map (which tells the debugger where and how big all the memory regions are). If the linker command file and debugger memory map are valid, then you will get an error message that the generated code will not fit. if your linker command file defined the memory regions correctly, you will get a linker error like 10099

    Thanks

    ki