• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 695 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/TM4C129ENCPDT: Linkerscript gcc

CCS/TM4C129ENCPDT: GNU Toolchain is overwriting bootloader

Lukas Thumfart
Intellectual 275 points
Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: SEGGER

Tool/software: Code Composer Studio

Dear TI-Team,

I just created a plain project for the TM4C129ENCPDT in CCSv8. I jusr added an while(1) in the main.

Using the actual GNU compiler (v7.2.1 Linaro) and the default linker script.

Now i want to shrink my FLASH in the linkerscript.

FLASH (RX) : ORIGIN = 0x00004000, LENGTH = 0x000FC000

and set

PROVIDE (_intvecs_base_address = 0x00004000);

Why is GNU filling the flash until the 0x00004000 address with 0x00? I know the default fillingoption for sections starting with '.' of the gnu linker is 0x00, but why is there code previous of the 0x00004000 address?

This basic question appeared since the TI compiler is leaving this space as it is and therefore isn't overwriting for e.g a bootloader.

Can you help me to understand this behaviour? Thanks in advance.

regards

Lukas

  • 0
    TI__Guru**** 191906 points

    Hi Lukas,

     Let me try to understand your question. You created a new project and this project will start at 0x4000. How did you program this new project into the flash? Did you program this project via the JTAG interface or this application project is programmed by the bootloader who is sitting at 0x0?

    If you were to use the JTAG to program your firmware image (starting at 0x4000) you will need to make sure that the bootloader is not overwritten. I don't know which IDE/tool you use to program the application image. If you use CCS then please make sure you don't select the "Entire Flash". The default is selecting the radio button "Use the Erase Options Specified Below" and the option that will be selected is "Entire Flash". With the default setting, the CCS will program your application at 0x4000. However, everything from 0x0 to 0x4000 will also be erased. I'm not sure if this is the issue you are asking. If not please clarify your question for me. If you are using  the GNU tool chain to program the flash then the tool should have options that is similar to CCS, I hope , to allow you not erase a certain range of the memory. I have no experience with GNU tool chain. You will need to ask the GNU for support if this is the issue you are asking to resolve.

  • 0 in reply to Charles Tsai
    Intellectual 275 points
    IDE: CCS v8.3
    Programmer/Debugger: Segger J-Link (jtag)
    GNU Toolchain: (v7.2.1 Linaro) ... arm-none-eabi

    When i use the TI-compiler for the same project, the flash-memory from 0x00000000 to 0x00004000 stays the same as when i start debugging. With the gcc-compiler this area gets overwritten (with 0x00).

    regards,
    Lukas
  • 0 in reply to Lukas Thumfart
    TI__Guru**** 191906 points
    Hi,
    If you use CCS then can you try what I suggested? You can try two options. One is to select the radio button "Necessary Pages Only". The other option is to select "Use erase options specified below" and provide your memory range which will start at 0x4000.
  • 0 in reply to Charles Tsai
    Intellectual 275 points

    Unfortunately i dont have this options (not sure because of segger or gnu).

    regards,

    Lukas

  • 0 in reply to Lukas Thumfart
    TI__Guru**** 191906 points

    For experiment, can you try other debug probes such as XDS100v2, XDS200, or XDS110?

    Another thing is for you to find out from GNU if somehow the prefill of 0x0 can be disabled. I hope there are some switches that comes with the GNU to do so. 

  • 0 in reply to Charles Tsai
    Intellectual 275 points
    I am able to skip some flash segments with the onboard programmer of the launchpad, but we actually use the TM4C129ENCPDT at a custom board.It seems that segger is using the ccsv8\ccs_base\common\targetdb\devicestm4c129encpdt.xml.
    I am not able to see the FPU registers in my debugger.
    How to see them?
    I think that they are set wrong and therefore gnu sees a section and fills it with 0x00.

    regards,
    Lukas
  • 0 in reply to Lukas Thumfart
    TI__Guru**** 191906 points
    The xml files are used by the CCS to to view the registers. I don't think during compile the GNU will need to look at these files. I still it is best for you to contact GNU how to configure the linker command file so that unwanted portion doesn't get prefilled with 0x0 to become part of the final binary output.
  • 0 in reply to Charles Tsai
    Intellectual 275 points

    This is my nearly default linkerscript. There are also bootdemos with gcc in the TivaC but i didn't get them to work.

    TI compiler: skips the memoryarea which isn't mentioned by the .cmd file

    GNU compiler: zeropads the unmentioned memory as shown below.

    So my question is: Why and how is the TI compiler doing that in the right way?

    regards,

    Lukas

  • 0 in reply to Lukas Thumfart
    Intellectual 275 points
    I finally got the answer:
    Create a sepperet memoryregion for the bootsection e.g.:
    MEMORY
    {
    BOOT (rx) : ORIGIN = 0x00000000, LENGTH = 0x00004000
    FLASH (RX) : ORIGIN = 0x00004000, LENGTH = 0x000FC000
    SRAM (WX) : ORIGIN = 0x20000000, LENGTH = 0x00040000
    }

    and create a own boot section:

    .boot : {
    __boot_end__ = 0x00004000;
    . = __boot_end__;
    } > BOOT

    now you are able to to debug a application in CCS with a bootloader preflashed.

    the glue is, that without creating a own section gnu thinks that there is one and uses its default filling behaviour with 0x00 to prevent unwanted presets and overwrites your bootloader. Setting the counter in the linkerfile to e.g. . = __boot_end__; will avoid the defaultfill at the end of the section. With this workaround it's still possible to use the --gc-sections flag.

    The TI-compiler doesn't fill sections on thefault.

    thanks for all the answers.

    regards,
    Lukas
  • 0 in reply to Lukas Thumfart
    TI__Guru**** 191906 points
    Hi Lukas,
    Glad you found the solution and it will benefit many in the community who may be looking for the same solution with GNU tool chain.