[quote user="Amit Ashara"]I do remember @ Chester Gillon's posts and forum replies on the topic of GNU C sometimes in Code Composer Forum and on TM4C as well, so thought it would be a good start to see how we can streamline project creation in CCS IDE for GNU C[/quote]I have found another problem with GNU v4.8.4 C++ code when creating a project for a TM4C in CCS 6.1.2, in that a global constructor was not called. If CCS 6.1.2 is used to create a Cortex-A9 project for an AM4378 using the GNU v4.8.4 compiler, change to link "rdimon" rather than "nosys" and add the following as main.cpp the program produces the expected results on the Cortex-A9: /* * main.cpp */ #include class test_class { public: test_class(); unsigned int get_initialised (void) const; private: unsigned int initialised; }; test_class::test_class() { initialised = 0xfeedabba; } unsigned int test_class::get_initialised() const { return initialised; } test_class global_instance; int main(void) { test_class stack_instance; printf ("global_instance.initialised=0x%x\n", global_instance.get_initialised()); printf ("stack_instance.initialised=0x%x\n", stack_instance.get_initialised()); return 0; } The correct results on the Cortex-A9 show the test_class::test_class() constructor was called for both a global instance and stack instance of the class: global_instance.initialised=0xfeedabba stack_instance.initialised=0xfeedabba Whereas if the same C++ code is run on a TM4C123GH6PM project also created in CCS 6.1.2 with the GNU v4.8.4 compiler, and applying the same project configuration changes as in the previous posts, then the program fails to produce the correct output because the constructor for the global_instance is not called: global_instance.initialised=0x0 stack_instance.initialised=0xfeedabba From a quick look think this is due to a difference in the start-up code used in the default CCS projects for the Cortex-A9 and TM4C devices. The CCS Cortex-A9 default startup_ARMCA9.S initializes the Vector Base Address Register and then branches to the _start runtime library function. Where _start in the runtime library calls global constructors, performs other runtime environment initialization and finally calls main. Whereas the CCS TM4C default startup tm4c123gh6pm _startup_ccs_gcc.c copies the data segment initializers from flash to SRAM, zeros the .bss segment, enables the floating-point unit and then calls main. i.e. the runtime environment initialization which calls the global constructors is not called. Need to determine if the CCS TM4C default startup files NOT calling the _start runtime library function is an omission, or due to the v4.8.4 compiler runtime library _start function not being supported on Cortex-M4 devices. [The CCS MSP432, i.e. another Cortex-M4F device, default startup file msp432_startup_ccs_gcc.c also omits to call the _start runtime library function]
↧