Tiva program created with CCS v6 using GNU compiler doesn't reach main

Chester Gillon

Guru 92251 points

Other Parts Discussed in Thread: TM4C123GH6PM

Using CCS I have been unable to create a Tiva program using the GNU compiler which reaches main.

An example sequence is:

1) In CCS 6.0.0.00190 create a new "Empty Project (with main.c)" using the following settings:

2) Set the main.c to contain:

#include <stdio.h>

int main(void) {
	printf ("Hello World\n");
	return 0;
}

3) The project compiles and links without any warnings or errors:

**** Build of configuration Debug for project TIVA_GNU_hello_world ****

"C:\\ti_ccs6_0\\ccsv6\\utils\\bin\\gmake" -k all
'Building file: ../main.c'
'Invoking: GNU Compiler'
"C:/ti_ccs6_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc.exe" -c -mcpu=cortex-m4 -mthumb -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -DPART_TM4C123GH6PM -I"C:/ti_ccs6_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_7-2013q3/arm-none-eabi/include" -ffunction-sections -fdata-sections -g -gstrict-dwarf -Wall -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.c"
'Finished building: ../main.c'
' '
'Building file: ../tm4c123gh6pm_startup_ccs_gcc.c'
'Invoking: GNU Compiler'
"C:/ti_ccs6_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc.exe" -c -mcpu=cortex-m4 -mthumb -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -DPART_TM4C123GH6PM -I"C:/ti_ccs6_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_7-2013q3/arm-none-eabi/include" -ffunction-sections -fdata-sections -g -gstrict-dwarf -Wall -MMD -MP -MF"tm4c123gh6pm_startup_ccs_gcc.d" -MT"tm4c123gh6pm_startup_ccs_gcc.d" -o"tm4c123gh6pm_startup_ccs_gcc.o" "../tm4c123gh6pm_startup_ccs_gcc.c"
'Finished building: ../tm4c123gh6pm_startup_ccs_gcc.c'
' '
'Building target: TIVA_GNU_hello_world.out'
'Invoking: GNU Linker'
"C:/ti_ccs6_0/ccsv6/tools/compiler/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc.exe" -mthumb -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -DPART_TM4C123GH6PM -ffunction-sections -fdata-sections -g -gstrict-dwarf -Wall -Wl,-Map,"TIVA_GNU_hello_world.map" -o"TIVA_GNU_hello_world.out" "./tm4c123gh6pm_startup_ccs_gcc.o" "./main.o" -Wl,-T"../tm4c123gh6pm.lds" -Wl,--start-group -l"c" -l"gcc" -l"nosys" -Wl,--end-group
'Finished building target: TIVA_GNU_hello_world.out'
' '

**** Build Finished ****

4) When attempt to start a debug session on a Tiva launchpad the flash is programmed without error, but the program doesn't reach main.

5) Pressing Supend in the debugger causes the following to be reported in the Console:

CORTEX_M4_0: Error: Debug Port error occurred.

The PC is reported as 0xE3530000 which is not a valid address in flash.

Looking in the memory browser at the start of flash which should be vector table shows a function __do_global_dtors_aux has appeared to be placed at address zero instead of the vector table:

The linker map appears to show that both the .intvecs and .text sections have been allocated to start at address zero:

0x00000000 PROVIDE (_intvecs_base_address, 0x0)

.intvecs
*(.intvecs)

.text 0x00000000 0x2fa0
CREATE_OBJECT_SYMBOLS
*(.text)

The complete CCS project is attached 4722.TIVA_GNU_hello_world.zip

I am not sure if failure for this example project to reach main is either:

a) A mistake I made in creating the project

b) An error in the tm4c123gh6pm.lds GNU linker script or tm4c123gh6pm_startup_ccs_gcc.c start-up "template" files copied into the project by CCSv6 at project creation.

c) A bug in the GNU ARM compiler or linker.

[I haven't had such problems creating projects using the TI ARM compiler]

over 11 years ago

0 AartiG over 11 years ago

TI__Guru**** 173310 points

Chester,

I can reproduce this behavior. One discrepancy I noticed is that the startup_ccs_gcc.c file is naming the interrupt vector section .isr_vector, while the linker script is referencing .intvecs. I tried modifying the startup C file to name the section .intvecs, then rebuilt and reloaded, however the program still did not stop at main. The intvecs was correctly allocated to 0x0 in this case, but there is still something else wrong that is not making it run correctly.

When the program is running, I can suspend the program, then I can do a 'System Reset', and 'Go Main' and reach main, but for some reason this is not happening automatically. I'm also not sure about the support for printf when using GCC compiler. I will have to check into that.

I will file a bug for the code not halting at main when loaded and post the bug number here.

0 AartiG over 11 years ago in reply to AartiG

TI__Guru**** 173310 points

This is being tracked in SDSCM00050137.

0 Chester Gillon over 11 years ago in reply to AartiG

Guru 92251 points

AartiG said:
. I tried modifying the startup C file to name the section .intvecs, then rebuilt and reloaded, however the program still did not stop at main.

I made the same modification to the startup C file, and program also didn't reach main. After I suspended the program it was in the FaultISR. The NVIC_FAULT_STAT register had the value 0x00000001, i.e. the NVIC_FAULT_STAT_IERR "Instruction Access Violation" bit is set. From the datasheet this means "The processor attempted an instruction fetch from a location that does not permit execution."

I haven't yet worked out why Instruction Access Violation occurred.

AartiG said:
When the program is running, I can suspend the program, then I can do a 'System Reset', and 'Go Main' and reach main, but for some reason this is not happening automatically.

I can repeat that, but trying to step over the printf in main causes a crash. The CCSv6 CCS 6.0 tm4c123gh6pm.gel is supposed to performing a System Reset upon connection for the reasons in http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/337557/1181710.aspx#1181710. Therefore, not sure why a manual System Reset makes a difference.

One other thing I noticed is that the TI target startup C function calls the _c_int00 function in the run time library which then call mains.

Whereas the GNU target startup C function initializes the bss and data segments before calling main itself. Need to check if there is any start up function in the GNU run time library which needs to be called before main.

0 AartiG over 11 years ago in reply to Chester Gillon

TI__Guru**** 173310 points

Chester Gillon said:

One other thing I noticed is that the TI target startup C function calls the _c_int00 function in the run time library which then call mains.

Whereas the GNU target startup C function initializes the bss and data segments before calling main itself. Need to check if there is any start up function in the GNU run time library which needs to be called before main.

We were thinking the same thing as well. However, I personally don't have enough expertise on the GNU runtime library to be able to provide an immediate answer on this. The bug should hopefully get into the right hands so they can look into how the startup files should be changed.

0 AartiG over 11 years ago in reply to Chester Gillon

TI__Guru**** 173310 points

Chester Gillon said:
I can repeat that, but trying to step over the printf in main causes a crash.

I'm afraid the support for using printf with GCC on TivaC doesn't appear to be there yet.

Chester Gillon said:
The CCSv6 CCS 6.0 tm4c123gh6pm.gel is supposed to performing a System Reset upon connection for the reasons in http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/337557/1181710.aspx#1181710. Therefore, not sure why a manual System Reset makes a difference.

The System Reset is curretly being done on connect. What appears to be required is a System Reset after loading the program. I can't really explain yet why this helps(there is probably some initialization missing or not happenign correctly somewhere) , but doing a System Reset after the Program Load seems to help. Then you can do "Go Main" and run your code from there. I would recommend removing printfs from the code and also set a breakpoint at the exit point. There seems to be some issues with how exit code is handled as well as simply letting the program run ends up in FaultISR as well. But if I create a simple main program that just prforms some variable operations and perform the above manual steps and set a breakpoint at the end of main to stop the code, it seems to execute ok.

I'll raise this with the Tiva folks and see what we can do to address these issues.

0 Chester Gillon over 11 years ago in reply to AartiG

Guru 92251 points

AartiG said:
What appears to be required is a System Reset after loading the program. I can't really explain yet why this helps(there is probably some initialization missing or not happenign correctly somewhere) , but doing a System Reset after the Program Load seems to help. Then you can do "Go Main" and run your code from there. I would recommend removing printfs from the code and also set a breakpoint at the exit point.

Changed to use the source code of the "Blinky" TivaWare example in a CCS project using the GNU compiler. That showed the same issue as the printf example, in that when started a debug session main wasn't reached. Doing a System Reset after the Program Load and the program then runs correctly (an infinite loop so avoids any issue with the exit code).

0 Chester Gillon over 11 years ago in reply to Chester Gillon

Guru 92251 points

Chester Gillon said:
That showed the same issue as the printf example, in that when started a debug session main wasn't reached.

The hard fault handler was modified to store the exception information pushed onto the stack using the example code from http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

After starting the debug session which failed to reach main, when the debugger was suspended the processor was in the hard fault handler with the following exception information recorded:

lr   unsigned long   0xFFFFFFFF (Hex)
pc   unsigned long   0xFFFFFE44 (Hex)
psr   unsigned long   0x01000000 (Hex)
r0   unsigned long   0x20000F94 (Hex)
r1   unsigned long   0x00000AA4 (Hex)
r12   unsigned long   0x400FD000 (Hex)
r2   unsigned long   0x00000000 (Hex)
r3   unsigned long   0x00000000 (Hex)

The PC and LR register values aren't from valid program addresses, so not sure caused them.

[I did validate that the exception handler reported the expected PC and LR register values when an Instruction Access Violation was deliberately generated]

0 Chester Gillon over 11 years ago in reply to AartiG

Guru 92251 points

AartiG said:
he System Reset is curretly being done on connect. What appears to be required is a System Reset after loading the program. I can't really explain yet why this helps(there is probably some initialization missing or not happenign correctly somewhere) , but doing a System Reset after the Program Load seems to help.

As a work around, I found that under CCS Project Properties -> Debug -> Flash Settings enabling "Reset target during program load to Flash memory" meant that when a debug session was started main was reached without having to perform a manual System Reset. This work-around was successful on two example Tiva projects using the GCC compiler.

Code Composer Studio™︎

Code Composer Studio forum

Tiva program created with CCS v6 using GNU compiler doesn't reach main