C++ project link failure when using ST-provided startup assembly code

[mahaun]

Description

The Reset_Handler() in the ST-provided stm32l476xx.S assembly file is calling __libc_init_array, which causes the linker to throw the error "undefined reference to _init" when I try to build. According to google the suggested fix is to remove the "-nostartfiles" linker option, but I see a lot of complaints about newlib-nano producing large C++ executables when it handles C++ startup/teardown. Now I am wondering if I made the wrong choice, and should have stayed with the provided C startup code.

I'm using an stm32l476 discovery board, for which no template was available, so I used the generic Cortex-M template. The README_DEVICE files say to remove the GNU ARM Eclipse startup C file and replace it with the vendor assembly file, but is this really the recommended option?

Versions

plugin version 3.1.1-201606210758 Eclipse Neon latest Oracle Java Windows 7 64-bit latest GNU ARM embedded toolchain

[diabolo38]

Why don't you start from CubeL4 project (SW4STM32 or atolic) project or use CubeMX to generate an eclipse project you can then look at or use as ref ? In this project the template startup assembly+ sys c file are used nothing is added or removed

the full linker command is -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -specs=nosys.specs -specs=nano.specs -T"../STM32L476RGTx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -lm

note that the linker .ld file may have some symbol use by lib/startup (heap ad stack size plus default section start/end etc... )

In order to use the gnu arm eclispe base startup file or project you'll have to understand what you do and be ready to do some manual work if not fully functional.

lib produce large code is likely because you do not have the option to remove unused section "-Wl,--gc-sections " Anyway be ready to pay 15K+ to use sprintf and variant

[ilg-ul]

should have stayed with the provided C startup code

the C startup code was provided for good reasons. of course you can use any startup code you like, but you'll need to handle lots of newlib oddities.

the structure of the generated projects will soon change, when the new packet based wizards will be available. the new STM projects will also be integrated with CubeMX.

please take a look at the demo projects available from https://github.com/micro-os-plus/eclipse-demo-projects.

[ilg-ul]

README_DEVICE files say to remove the GNU ARM Eclipse startup C file

can you be more specific which file says this?

[mahaun]

I was referring to system/src/cmsis/README_DEVICE.txt which says

The current version of the Eclipse managed build plug-in does not process .s, but only .S. If you want to use the assembly startup_Device.s, you must exclude the _startup.c and exception_handlers.c from build, and rename the vendor provided assembly file to startup_XXX.S, where XXX is the actual device name.

But you have confirmed what I suspected, that there has been a lot of work to optimize your startup code for newlib. I very much doubt that ST's "gcc" port makes a similar effort, especially for C++ projects. I have used the Cube software for pin planning and to spit out the basic required CMSIS files (register definitions), but in all other respects I try to avoid using any ST code because the quality is so poor. I would like to try and use your startup code if I can.

I'll try a different approach this time, starting with your F7 demo project and then modifying it for the L4. Peripherals are fairly similar between those two chips.

[ilg-ul]

I was referring to system/src/cmsis/README_DEVICE.txt which says "If you want to use the assembly startup_Device.s"

ah, ok, this does not recommend to use the assembly file, it is only a suggestion in case you really want to do it.

I very much doubt that ST's "gcc" port makes a similar effort

it does not.

I have used the Cube software for pin planning ... I try to avoid using any ST code because the quality is so poor.

the ST code might not be great, but using Cube to generate the initialisation code should be fine.

actually I recommend keeping the Code in the loop, like I did in the demo projects, so you can easily update the initialisation if needed during development.

starting with your F7 demo project and then modifying it for the L4

perhaps starting with the F0 project is more appropriate, since it also gets the HAL library from Cube.

[mahaun]

It probably does not matter very much (F7, F4, or F0) because I am only keeping the initialization code.

I don't want the HAL library (or the LL code). I write all of my own drivers, so the first thing I have to do when adapting an ST demo project is to write the clock setup (PLL, etc) and systick handling myself so I can delete the HAL.

[ilg-ul]

I write all of my own drivers

"been there, done that"

but I ended up learning that life is too short to spend it on reinventing everything.