Errors in startup_stm32f429xx.s when converting a project to C++

[Kevin Flanagan]

Posted on August 10, 2017 at 01:10

This question is going to be a bit long winded, I apologize. 

I am using an ST144 Nucleo 429zi and need to do the firmware in C++. (by edict of management)

I have been digging around  on how to convert ST CubeMX C projects to C++ projects inside of Atollic TrueSTUDIO for ARM V7.12 and feel I am so close.

Specifically I have referenced the following articles (and the comments in them): 

https://stackoverflow.com/questions/35288808/first-project-for-stm32-with-hal-in-c

 

http://www.openstm32.org/forumthread1244

 

https://mcuoneclipse.com/2014/07/22/exclude-source-files-from-build-in-eclipse/

 

https://isocpp.org/wiki/faq/mixing-c-and-cpp

 

http://www.openstm32.org/forumthread539

 

*Subtle note, to get the HAL linked in you also need to duplicate the Project Properties->Path and Symbols->Symbols between GNU C and GNU C++ (That's not in the articles, but similar to what you do with the Project Properties->Path and Symbols->Includes).

Well, this almost works, I am down to five errors, all in the generated file startup->startup_stm32f429xx.s 

undefined reference to '_ebss' (line 106)

undefined reference to '_estack' (line 80)

undefined reference to '_sbss' (line 98)

undefined reference to '_sdata' (line 93)

undefined reference to '_sidata' (line 87)

I find this strange,

I did find a reference to unchecking 'exclude unused' on the MCU for Eclipse, 

https://www.eclipse.org/forums/index.php/t/1065128/

 

I have not found where that setting is in true Studio.

I am open to suggestions on what is causing the error, and the best way to go about fixing this problem. 

I have repeated the steps for converting to C++ on both my project and a blank shell using the 429zi defaults from a project generated by CubeMX v4.21.0. They both compile fine as C projects and generate the same 5 errors when converted to C++. I have attached a .zip of the shell project and some screen shots.

Again, thanks in advance, hope it was not to, too long winded...

-Kevin 

#429zi #c++

[Tesla DeLorean]

Posted on August 10, 2017 at 02:25

These should be coming from the linker script, which should be from a coherent source as the startup file.

[Kevin Flanagan]

Posted on August 10, 2017 at 18:46

Sorry to be dense, but not having in the past touched the linker script, do care to expand on it a little? Or have a good reference on how to generate (I assume) a new one?

[valentin]

Posted on August 10, 2017 at 22:37

https://community.st.com/0D50X00009XkeVwSAJ

I program in C++ as of now and have been using Atollic up until recently. Just switched to Eclipse because of pretty printing support there.

There's nothing special to converting the project into C++ really. Just import the CubeMX project and then go new->convert c/c++.

Then in settings copy symbols and includes from c to c++.

I just checked vs one of my projects:

C++ Linker needs '-Wl,-cref,-u,Reset_Handler' in other options.

Only 'No shared libraries' ticked in General options. Make sure to select the cubemx generated linker script there, too.

All of this should be default anyway though.

(For GNU ARM Eclipse, you have to rename the startupxxx.s file to startupxxx.S -> capitalize S. Otherwise assembler compiler ignores it).

[Tesla DeLorean]

Posted on August 10, 2017 at 21:04

Well for starters look at a working GNU/GCC project. 

https://drive.google.com/open?id=0B7OY5pub_GfINVZnNXFvTGxaWmM

 

The entire firmware image, including what you have initialized in RAM is packed into FLASH. Code in the startup.s then clears and copies areas of RAM as part of the unpacking process. The linker constructs the image, and the linker script describes how this is done, and places symbolic markers that define where certain data has been placed within the image. It is these symbols that the startup code is not finding. The script and startup need to match each other.

C++ adds another dimension, as it has a list of constructors (ctors) that must be called during initialization. This is done after SystemInit() brings up the chip and memory interfaces, and before the main() function is called.

/* Call the clock system intitialization function.*/

  bl  SystemInit/* Call static constructors */    bl __libc_init_array/* Call the application's entry point.*/  bl  main