• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 1348 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.

BUG in GCC linker script tm4c1294ncpdt.lds

Stefan Tauner38
Prodigy 150 points

Other Parts Discussed in Thread: TM4C1294NCPDT

Hi,

the linker script I have been using has a major issue: It makes the startup code "initialize" global variables with constants that are supposed to be written at higher addresses following the .data section. This can easily be reproduced by adding initialized global variables and constants to a project and observing the resulting memory contents at the beginning of main. I can create a minimal working example if need be, but it should be pretty clear...

The fix for the issue is trivial: the .data and .rodata sections in the linker scripts need to be swapped. The correct order of the respective sections in the linker file are as follows:

    .data : ALIGN (4) {
        __data_load__ = LOADADDR (.data);
        __data_start__ = .;
        KEEP (*(.data))
        KEEP (*(.data*))
        . = ALIGN (4);
        __data_end__ = .;
    } > REGION_DATA AT> REGION_TEXT

    .rodata : {
        *(.rodata)
        *(.rodata*)
    } > REGION_TEXT

I am currently using CCS 6.0.1.00040 and TivaWare 2.1.0.12573. The linker script with the bug is located in ccs_base/arm/include/tm4c1294ncpdt.lds but I have not checked if other devices are affected!

Side question: is it enough to replace the file in ccs_base to make newly created projects use the fixed file?

  • 0
    TI__Guru**** 244440 points
    Hello Stefan,

    Code Composer installed files must be reported to the Code Composer Forum. In this case if you want to make the change permanent then yes changing the file should be sufficient in ccs_base. However it is good to double check with CCS Forum users.

    Regards
    Amit
  • 0
    Guru 92251 points

    Stefan Tauner38 said:
    The fix for the issue is trivial: the .data and .rodata sections in the linker scripts need to be swapped. The correct order of the respective sections in the linker file are as follows:

    I think this may be the same problem as reported on the CCS forum in Errors in CCSv6 created project for a TM4C129 project using the GNU v4.7.4 compiler.

    My suggested fix was to the ResetISR function in the  tm4c1294ncpdt_startup_ccs_gcc.c source file, rather than a change to the linker script.

  • 0
    Guru 92251 points

    Stefan Tauner38 said:
    am currently using CCS 6.0.1.00040 and TivaWare 2.1.0.12573.

    Can you try and see if CCS 6.1.0.00104 fixes your problem?

    I have just created the same example from Errors in CCSv6 created project for a TM4C129 project using the GNU v4.7.4 compiler using CCS 6.1.0.00104, and the two project creation problems reported with CCS 6.0.1.00040 have been fixed in CCS 6.1.0.00104.

  • 0 in reply to Chester Gillon
    Prodigy 150 points

    No, actually it made it worse because I can't even make it work correctly with said change anymore. Now not even the code seems to end up at the right places. When I download and run a binary (with just an endless loop as main) it immediately ends up in the FaultISR provided by the startup code and breakpoints (e.g. in the startup code do not work at all). I have created a new CCS project for this test.


    For the old code (that did not work previously), I verified that the updated CCS does not initialize the variables correctly either (additionally to not executing the code correctly as explained above).

    I have switched over to the TI compiler for now, but only because I have to get my work done...

    I am fine with moving this thread to the CCS forums, if that's possible. Thanks everyone for the help so far.

  • 0 in reply to Stefan Tauner38
    Guru 92251 points

    Stefan Tauner38 said:
    No, actually it made it worse because I can't even make it work correctly with said change anymore. Now not even the code seems to end up at the right places. When I download and run a binary (with just an endless loop as main) it immediately ends up in the FaultISR provided by the startup code and breakpoints (e.g. in the startup code do not work at all). I have created a new CCS project for this test.

    OK, I can now repeat the problem with a GNU v4.8.4 example created with CCS 6.1 ending up in the FaultISR after starting a debug session.

    [On my previous test I did get an entry to the FaultISR but dismissed that as a glitch]

    Under CCS Project Properties -> Debug -> Auto Run and Launch Options -> Auto Run Options I unticked both "On a program load or restart" and "On a reset" to investigate the start up code. The following sequence is repeatable:

    1) Start a debug session.

    2) The program counter is at the start of the __do_global_dtors_aux function, which is incorrect as it is not the reset vector.

    3) Single stepping through the __do_global_dtors_aux function causes an entry to the FaultISR after attempts to pop the stack.

    4) Assert a System Reset.

    5) The program counter is at the start of the ResetISR, which is the correct reset vector.

    6) Can now step through the start-up code and reach main.

    This may be the same issue as I reported previously in Tiva program created with CCS v6 using GNU compiler doesn't reach main, but for which didn't get to the bottom of. I think the problem may be the CCS debugger not correctly determining the entry point of the start-up code. Will attempt to investigate.

  • 0 in reply to Stefan Tauner38
    Guru 92251 points

    Stefan Tauner38 said:
    No, actually it made it worse because I can't even make it work correctly with said change anymore. Now not even the code seems to end up at the right places. When I download and run a binary (with just an endless loop as main) it immediately ends up in the FaultISR provided by the startup code and breakpoints (e.g. in the startup code do not work at all). I have created a new CCS project for this test.

    The problem is a combination of the CCS default linker script not defining the entry point, and a change in behavior of GCC v4.7.4 (included in CCS 6.0) and GCC v4.8.4 (included in CCS 6.1). See Project for a TM4C1294NCPDT created in CCS 6.1 using GNU compiler doesn't run to main for details.

    Adding the following to the linker script to set the entry point allowed the program created in CCS 6.1 with GCC v4.8.4 to run to main:

    ENTRY(ResetISR)

  • 0 in reply to Chester Gillon
    Prodigy 150 points
    Thanks, let's hope TI picks it up soon...