Global constructors in a C++ project with GCC on the MSP432

Dan Cermak

Hi,

I have run into some issues while porting a C++ project from the MSP430 to the MSP432 with the initialization of global objects.

To be more specific, I have taken the uart example project from the MSPGCC examples folder and I am using the startup_msp432p401r_gcc.c and system_msp432p401r_gcc.c files (the latter is nearly empty, as I initialize most of the System later, I also threw away SystemCoreClockUpdate() since it seems to be never called). I have taken the compiler flags for the gcc arm compiler and included them in my own build script.

The C++ projects consists of many classes with only static members, so afaik these should be initialized in _start() (also called _mainCRTStartup() in newlib and the TI example). One of these classes contains an event queue, which is just an array filled with a certain struct. When the array is initialized, the compiler calls the constructor of each struct and somehow one of these constructor calls causes a jump into a not-executable region of the memory thereby resulting in a Usage Fault.

My guess is that some of the global initialization routines end up somewhere else in the flash and are maybe not copied correctly into RAM? But to be honest I am totally lost here, so I would be very grateful for any input.

I also looked into the examples provided by ARM (which are bundled with the arm-gcc toolchain) and they specifically mention that most of their Makefiles are not compatible with C++ global constructors/destructors. They provide one which is compatible with C++ and the difference seems to be that the C++ version defines __NO_SYSTEM_INIT, whereas the C version defines __STARTUP_CLEAR_BSS and __START=main . I have however not seen these macros in the TI examples and defining __NO_SYSTEM_INIT didn't help.

However both examples from ARM differ in their linkscripts, specifically the C++ version has a lot of lines with KEEP( ... ) (where ... is e.g. *(.init_array), *(.fini_array), *(.preinit_array), etc). I guess this might have some influence, but the differences between the ARM linkscripts and the TI linkscript are rather non-trivial. If someone is more fond of them, I would be grateful for any advice what these sections are and where to correctly include them (or whether they are needed at all on the MSP432).

Thanks in advance,

Dan

over 9 years ago

0 Chris Sterzik over 9 years ago

TI__Guru 68021 points

Dan,
I will need to reach out to some different resources and return to this thread next week.

Chris

0 Dan Cermak over 9 years ago

Intellectual 690 points

I have further debugged the issue and created a very simple minimal example. It contains only the default initialization from the TI examples, a simple main() and an event stack (just an array of structs). The necessary files should be attached to this message. I have build the project as follows:

/ti/msp432_gcc/arm_compiler/bin/arm-none-eabi-g++ -o EventQueue.o -c -Wall -Wextra -Werror -MD -ffunction-sections -fdata-sections -fno-exceptions -DTARGET_IS_MSP432P4XX -Dgcc -mcpu=cortex-m4 -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -g3 -gstrict-dwarf -std=c++03 -fno-rtti -Wdelete-incomplete -I/ti/msp432_gcc/arm/include/CMSIS -I/ti/msp432_gcc/arm/include -I/ti/msp432_gcc/arm_compiler/arm-none-eabi/include EventQueue.cpp
/ti/msp432_gcc/arm_compiler/bin/arm-none-eabi-g++ -o main.o -c -Wall -Wextra -Werror -MD -ffunction-sections -fdata-sections -fno-exceptions -DTARGET_IS_MSP432P4XX -Dgcc -mcpu=cortex-m4 -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -g3 -gstrict-dwarf -std=c++03 -fno-rtti -Wdelete-incomplete -I/ti/msp432_gcc/arm/include/CMSIS -I/ti/msp432_gcc/arm/include -I/ti/msp432_gcc/arm_compiler/arm-none-eabi/include main.cpp
/ti/msp432_gcc/arm_compiler/bin/arm-none-eabi-gcc -o startup_msp432p401r_gcc.o -c -Wall -Wextra -Werror -MD -ffunction-sections -fdata-sections -fno-exceptions -DTARGET_IS_MSP432P4XX -Dgcc -mcpu=cortex-m4 -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -g3 -gstrict-dwarf -std=c99 -I/ti/msp432_gcc/arm/include/CMSIS -I/ti/msp432_gcc/arm/include -I/ti/msp432_gcc/arm_compiler/arm-none-eabi/include startup_msp432p401r_gcc.c
/ti/msp432_gcc/arm_compiler/bin/arm-none-eabi-g++ -o uart_test -Wall -Wextra -Werror -MD -ffunction-sections -fdata-sections -fno-exceptions -DTARGET_IS_MSP432P4XX -Dgcc -mcpu=cortex-m4 -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -g3 -gstrict-dwarf -D__MSP432P401R__ -Wall -Tmsp432p401r.lds -l'c' -l'gcc' -l'nosys' -Wl,-Map=uart_test.map startup_msp432p401r_gcc.o main.o EventQueue.o

(the paths are hardcoded, but I can upload a build script).

I have uploaded the binary onto the MSP432 Launchpad and followed the execution with the GDB. I let the debugger execute until _libc_init_array and then proceeded to single step:

Breakpoint 4, 0x0000035a in __libc_init_array ()
(gdb) nexti
0x0000035c in __libc_init_array ()
(gdb) n
Single stepping until exit from function __libc_init_array,
which has no line number information.
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x376

0x0000060c in _init ()
(gdb) nexti
0x0000060e in _init ()
(gdb) nexti
0x00000610 in _init ()
(gdb) nexti
0x00000612 in _init ()
(gdb) nexti
0x00000614 in _init ()
(gdb) nexti
0x00000616 in _init ()
(gdb) nexti
0x00000376 in __libc_init_array ()
(gdb) nexti
0x00000378 in __libc_init_array ()
(gdb) nexti
0x0000037a in __libc_init_array ()
(gdb) nexti
0x0000037c in __libc_init_array ()
(gdb) nexti
0x0000037e in __libc_init_array ()
(gdb) nexti
0x00000380 in __libc_init_array ()
(gdb) nexti
0x00000384 in __libc_init_array ()
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x386

0x00000108 in frame_dummy ()
(gdb) nexti
0x0000010a in frame_dummy ()
(gdb) nexti
0x0000010c in frame_dummy ()
(gdb) nexti
0x00000116 in frame_dummy ()
(gdb) nexti
0x00000118 in frame_dummy ()
(gdb) nexti
0x0000011a in frame_dummy ()
(gdb) nexti
0x0000011e in frame_dummy ()
(gdb) nexti
0x00000120 in frame_dummy ()
(gdb) nexti
0x00000122 in frame_dummy ()
(gdb) nexti
0x0000011c in frame_dummy ()
(gdb) nexti
0x00000386 in __libc_init_array ()
(gdb) nexti
0x00000388 in __libc_init_array ()
(gdb) nexti
0x0000037e in __libc_init_array ()
(gdb) nexti
0x00000380 in __libc_init_array ()
(gdb) nexti
0x00000384 in __libc_init_array ()
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x386

_GLOBAL__sub_I__ZN10EventQueue11event_stackE () at EventQueue.cpp:3
3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000322      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000328      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x0000032a      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x32e

__static_initialization_and_destruction_0 (__initialize_p=0, __priority=0) at EventQueue.cpp:3
3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x000002f6      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x000002f8      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x000002fa      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x000002fc      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000300      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000302      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000304      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000306      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x0000030a      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x0000030c      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x0000030e      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000310      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x314

Stack<event, unsigned short, (unsigned short)2>::Stack (this=0x20000454 <EventQueue::event_stack>) at Stack.hpp:8
8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002be      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002c0      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002c2      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002c6      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002c8      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ca      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ce      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002d0      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002d2      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x2d6

event::event (this=0x2000045c <EventQueue::event_stack+8>) at EventQueue.hpp:14
14        event() {}
(gdb) nexti
0x000002a6      14        event() {}
(gdb) nexti
0x000002a8      14        event() {}
(gdb) nexti
0x000002aa      14        event() {}
(gdb) nexti
14        event() {}
(gdb) nexti
0x000002ae      14        event() {}
(gdb) nexti
0x000002b0      14        event() {}
(gdb) nexti
0x000002b2      14        event() {}
(gdb) nexti
0x000002b4      14        event() {}
(gdb) nexti
0x000002b8      14        event() {}
(gdb) nexti
0x000002d6 in Stack<event, unsigned short, (unsigned short)2>::Stack (this=0x20000454 <EventQueue::event_stack>) at Stack.hpp:8
8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002d8      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002da      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ca      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ce      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002d0      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002d2      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x2d6

event::event (this=0x20000454 <EventQueue::event_stack>) at EventQueue.hpp:14
14        event() {}
(gdb) nexti
0x000002a6      14        event() {}
(gdb) nexti
0x000002a8      14        event() {}
(gdb) nexti
0x000002aa      14        event() {}
(gdb) nexti
14        event() {}
(gdb) nexti
0x000002ae      14        event() {}
(gdb) nexti
0x000002b0      14        event() {}
(gdb) nexti
0x000002b2      14        event() {}
(gdb) nexti
0x000002b4      14        event() {}
(gdb) nexti
0x000002b8      14        event() {}
(gdb) nexti
0x000002d6 in Stack<event, unsigned short, (unsigned short)2>::Stack (this=0x20000454 <EventQueue::event_stack>) at Stack.hpp:8
8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002d8      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002da      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ca      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ce      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002dc      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002de      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002e0      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002e2      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002e4      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002e6      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002e8      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ea      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ec      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002ee      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x000002f0      8         Stack() : wr(0), rd(0) {}
(gdb) nexti
0x00000314 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at EventQueue.cpp:3
3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000316      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000318      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x0000031a      3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x0000032e in _GLOBAL__sub_I__ZN10EventQueue11event_stackE () at EventQueue.cpp:3
3       EventQueue::event_stack_t EventQueue::event_stack;
(gdb) nexti
0x00000386 in __libc_init_array ()
(gdb) nexti
0x00000388 in __libc_init_array ()
(gdb) nexti
0x0000037e in __libc_init_array ()
(gdb) nexti
0x00000380 in __libc_init_array ()
(gdb) nexti
0x00000384 in __libc_init_array ()
(gdb) nexti
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x386

0x0000043c in register_fini ()
(gdb) nexti
0x0000043e in register_fini ()
(gdb) nexti
0x00000446 in register_fini ()
(gdb) nexti
0x00000386 in __libc_init_array ()
(gdb) nexti
0x00000388 in __libc_init_array ()
(gdb) nexti
0x0000038a in __libc_init_array ()
(gdb) nexti
0x00000000 in interruptVectors ()
(gdb) nexti
UsageFault_Handler () at main.cpp:10
10      __attribute__((interrupt)) void UsageFault_Handler() {}
(gdb) nexti
0x0000024e      10      __attribute__((interrupt)) void UsageFault_Handler() {}

So something goes wrong at 0x38a, which belongs to _libc_init_array (one of the last instructions according to objdump):

00000350 <__libc_init_array>:
 350:	b570      	push	{r4, r5, r6, lr}
 352:	4e0f      	ldr	r6, [pc, #60]	; (390 <__libc_init_array+0x40>)
 354:	4d0f      	ldr	r5, [pc, #60]	; (394 <__libc_init_array+0x44>)
 356:	1b76      	subs	r6, r6, r5
 358:	10b6      	asrs	r6, r6, #2
 35a:	bf18      	it	ne
 35c:	2400      	movne	r4, #0
 35e:	d005      	beq.n	36c <__libc_init_array+0x1c>
 360:	3401      	adds	r4, #1
 362:	f855 3b04 	ldr.w	r3, [r5], #4
 366:	4798      	blx	r3
 368:	42a6      	cmp	r6, r4
 36a:	d1f9      	bne.n	360 <__libc_init_array+0x10>
 36c:	4e0a      	ldr	r6, [pc, #40]	; (398 <__libc_init_array+0x48>)
 36e:	4d0b      	ldr	r5, [pc, #44]	; (39c <__libc_init_array+0x4c>)
 370:	1b76      	subs	r6, r6, r5
 372:	f000 f94b 	bl	60c <_init>
 376:	10b6      	asrs	r6, r6, #2
 378:	bf18      	it	ne
 37a:	2400      	movne	r4, #0
 37c:	d006      	beq.n	38c <__libc_init_array+0x3c>
 37e:	3401      	adds	r4, #1
 380:	f855 3b04 	ldr.w	r3, [r5], #4
 384:	4798      	blx	r3
 386:	42a6      	cmp	r6, r4
 388:	d1f9      	bne.n	37e <__libc_init_array+0x2e>
 38a:	bd70      	pop	{r4, r5, r6, pc}
 38c:	bd70      	pop	{r4, r5, r6, pc}
 38e:	bf00      	nop
	...
 398:	0000060c 	.word	0x0000060c
 39c:	00000600 	.word	0x00000600

Anyway, as the execution reaches 0x38a a Usage Fault is triggered and the INVSTATE Bit is set it the CFSR register.

I hope these information can help someone who is more fond of assembly and compiler internals.

Cheers,

Dan

0 Dan Cermak over 9 years ago in reply to Dan Cermak

Intellectual 690 points

I am afraid the file upload did not work in the previous post (at least I cannot download the files). Therefore I reuploaded them here as a tar.gz archive. It also contains the SConstruct build script. To use it, set the ARM_ROOT environment variable to the root folder where the mspgcc toolchain was installed and run scons.

minimal.tar.gz

0 Dan Cermak over 9 years ago in reply to Dan Cermak

Intellectual 690 points

I have recompiled my minimal example with Linaro GCC which is bundled with Code Composer Studio 6.2. and the result is more or less the same. The code causes a usage fault in __libc_init_array() only at a different address. The last steps in gdb are now:

0x0000042a in register_fini ()
(gdb) 
0x0000036a in __libc_init_array ()
(gdb) 
0x0000036c in __libc_init_array ()
(gdb) 
0x0000036e in __libc_init_array ()
(gdb) 
0x00000000 in interruptVectors ()
(gdb) 
UsageFault_Handler () at main.cpp:10
10      __attribute__((interrupt)) void UsageFault_Handler() {}

and the dissasembly of __libc_init_array() reads as follows:

00000334 <__libc_init_array>:
 334:	b570      	push	{r4, r5, r6, lr}
 336:	4e0f      	ldr	r6, [pc, #60]	; (374 <__libc_init_array+0x40>)
 338:	4d0f      	ldr	r5, [pc, #60]	; (378 <__libc_init_array+0x44>)
 33a:	1b76      	subs	r6, r6, r5
 33c:	10b6      	asrs	r6, r6, #2
 33e:	bf18      	it	ne
 340:	2400      	movne	r4, #0
 342:	d005      	beq.n	350 <__libc_init_array+0x1c>
 344:	3401      	adds	r4, #1
 346:	f855 3b04 	ldr.w	r3, [r5], #4
 34a:	4798      	blx	r3
 34c:	42a6      	cmp	r6, r4
 34e:	d1f9      	bne.n	344 <__libc_init_array+0x10>
 350:	4e0a      	ldr	r6, [pc, #40]	; (37c <__libc_init_array+0x48>)
 352:	4d0b      	ldr	r5, [pc, #44]	; (380 <__libc_init_array+0x4c>)
 354:	1b76      	subs	r6, r6, r5
 356:	f000 f94b 	bl	5f0 <_init>
 35a:	10b6      	asrs	r6, r6, #2
 35c:	bf18      	it	ne
 35e:	2400      	movne	r4, #0
 360:	d006      	beq.n	370 <__libc_init_array+0x3c>
 362:	3401      	adds	r4, #1
 364:	f855 3b04 	ldr.w	r3, [r5], #4
 368:	4798      	blx	r3
 36a:	42a6      	cmp	r6, r4
 36c:	d1f9      	bne.n	362 <__libc_init_array+0x2e>
 36e:	bd70      	pop	{r4, r5, r6, pc}
 370:	bd70      	pop	{r4, r5, r6, pc}
 372:	bf00      	nop
	...
 37c:	000005f0 	.word	0x000005f0
 380:	000005e4 	.word	0x000005e4

The CFSR register also has the INVSTATE bit set upon entering the UsageFault_Handler().

Since the __libc_init_array() looks exactly the same as with the gcc version from ARM, only shifted slightly in memory, I suspect that maybe something else is causing the problem.

0 Chester Gillon over 9 years ago in reply to Dan Cermak

Guru 92251 points

Dan Cermak said:
I have recompiled my minimal example with Linaro GCC which is bundled with Code Composer Studio 6.2. and the result is more or less the same. The code causes a usage fault in __libc_init_array() only at a different address.

I compiled your example with the GNU v4.9.3 compiler that comes with CCS 6.2, and when debugger using CCS 6.2 confirm that the program also crashes with a Usage Fault before main is reached.

I have attached the project compiled in CCS 6.2 for reference, since it contains the map file with the allocated addresses. msp432_gcc_global_constructors.zip

The following CCS 6.2 debugger screen shot shows the instruction leading up to the usage fault:

The pop {r4, r5, r6, pc} instruction changes the program counter to zero, and when the processor attempts to execute the instruction at address zero a Usage Fault occurs - since address zero contains the reset vector which is not a valid instruction. Prior to the pop the stack pointer is the value 0x20000458 which according to the linker map file is within the EventQueue::event_stack variable in the .bss segment. Therefore, suspected the crash is caused by a stack overflow.

When single stepping into the _mainCRTStartup() noticed that the GCC startup code is setting the stack pointer to the value 0x20000468 which from the linker map file is the lowest address of the .stack section.

The msp432p401r.lds file in your example defines the stack with:

    .stack (NOLOAD) : ALIGN(0x8) {
        _stack = .;
        __stack = .;
        KEEP(*(.stack))
    } > REGION_STACK AT> REGION_STACK
	
	__StackTop = ORIGIN(REGION_STACK) + LENGTH(REGION_STACK);

From using using arm-none-eabi-objdump.exe found that _mainCRTStartup() sets the initial stack pointer to the value of the __stack symbol, which in the example msp432p401r.lds is the lowest address of the .stack segment which leads to the stack corrupting the global variables as the stack grows down.

When the msp432p401r.lds was changed to the following, to define the __stack symbol at the highest address of the stack, the program then successfully reached main:

    .stack (NOLOAD) : ALIGN(0x8) {
        _stack = .;
        KEEP(*(.stack))
    } > REGION_STACK AT> REGION_STACK

    __StackTop = ORIGIN(REGION_STACK) + LENGTH(REGION_STACK);
    PROVIDE(__stack = __StackTop);

Given the TI copyright header on the example msp432p401r.lds I guess you got a buggy link script from a TI example program. If so, which TI example?

0 Dan Cermak over 9 years ago in reply to Chester Gillon

Intellectual 690 points

Dear Chester,

you are my savior!

Thank you for that in depth analysis, your modification of the linker script fixed the problem.

Concerning the linker scripts, I simply took them from the TI includes. The provided file should be equal to the linker script from the MSPGCC package as found in: MSP432_GCC_ROOT/arm/include/msp432p401r.lds . This is also the same file which is bundled in Code Composer Studio 6.2 (which is in the following location ccs620/ccsv6/ccs_base/arm/include/msp432p401r.lds).

In case someone from TI reads this, could you please check the rest of the linker script? And could you please upload a fixed version to MSPGCC and CCS?

And once again thank you very much Chester!

Cheers,

Dan

0 Dan Cermak over 9 years ago in reply to Chris Sterzik

Intellectual 690 points

Dear Chris,
were you able to reach the other resources? This is imho a pretty serious bug in the linker script, which should be fixed upstream, too.

Cheers,
Dan

0 Chris Sterzik over 8 years ago in reply to Dan Cermak

TI__Guru 68021 points

Thanks Dan and Chester. Yes a bug has been filed, but I do not have any resolution at this time.

Regards,
Chris

0 Bob Heilmaier over 8 years ago in reply to Chris Sterzik

TI__Prodigy 595 points

Hey Dan,

Chris filed the bug against the GCC linker script and the file has been reviewed afterwards.
A CCS MSP432 header and support file update (which includes the fix from Chester and other bugfixes) can be expected by the end of February.
The fix will be pushed to the next release of the MSP432GCC Support Package as well. Release for that is planned for end of Q1.

Chester,
thanks a lot for looking into this and helping Dan to be able to continue.

Regards,
Bob Heilmaier

0 Chester Gillon over 8 years ago in reply to Bob Heilmaier

Guru 92251 points

Bob Heilmaier said:
A CCS MSP432 header and support file update (which includes the fix from Chester and other bugfixes) can be expected by the end of February.

During the investigation into CCS: CCS: C++ (g++) program crash in mallo_r during startup found that the Reset_Handler() function in the startup_msp432p401r_gcc.c support file in CCS 7.0.0.00042 is missing the code to to copy the data segment initializers from flash to SRAM.

Can that be fixed at the same time?

Thanks.

0 Bob Heilmaier over 8 years ago in reply to Chester Gillon

TI__Prodigy 595 points

Hey Chester,

thank you so much for pointing me there, I wasn't aware of it.

Yes, this bug will be added to the releases as well.

Best regards,

Bob

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

Global constructors in a C++ project with GCC on the MSP432