Toolchain Test Failed

[sktron]

Hallo,

I just tried to set up a project following your tutorial called “Importing Embedded Projects Built with External Tools”.
After I selected the MCU from the “Devices by type” tab and hit the Next button, a dialog would pop up and test the tool chain, throwing below error message at me.
What is wrong? Btw., I did not use a GCC toolchain provided by your plugin, it is required that I use the arm-none-eabi toolchain, version 4.8.3 (for now, probably newer versions later).

Regards,

—-
Tool arguments: -Wl,–start-group “C:\Users\blah\AppData\Local\Temp\/VisualGDB_TrivialProgram.o” -o “C:\Users\blah\AppData\Local\Temp\/VisualGDB_TrivialProgram.bin” -Wl,-gc-sections -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -TC:\Users\blah\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32/STM32L4xxxx/LinkerScripts/STM32L476RG_flash.lds -Wl,–end-group
c:/gcc_arm_none_eabi/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: error: C:\Users\blah\AppData\Local\Temp\/VisualGDB_TrivialProgram.o uses VFP register arguments, C:\Users\blah\AppData\Local\Temp\/VisualGDB_TrivialProgram.bin does not
c:/gcc_arm_none_eabi/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file C:\Users\blah\AppData\Local\Temp\/VisualGDB_TrivialProgram.o
c:/gcc_arm_none_eabi/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol Reset_Handler; defaulting to 08000000
collect2.exe: error: ld returned 1 exit status
—-

[support]

Hi,

The 4.8.3 toolchain indeed looks quite old. Furthermore, the problem might be caused by an incompatible default VFP setting in your toolchain.

VisualGDB actually comes with a newer one (can be installed from the wizard of from here), so we would recommend using it instead.

[sktron]

Well I also tried the 4.9 version of the toolchain to no avail.
The ones you pointed to are the eabi ones, I am required to use none-eabi.
I have no detailed knowledge of how this works, but have read that the eabi one actually expects a OS (not just some minimal RTOS) being present ( like described here: https://community.arm.com/thread/8672 ), which now puzzles me, as that’s not quite the case on typical Cortex M projects, certainly not mine. Could you shed light on this with regards to the VisualGDB embedded default compiler choice?
Anyway, the none-eabi is what an existing system uses (based on cmake scripts), and I’m tasked to get that working with VisualGDB, I can’t just use any other compiler version. (actually there is different code output and behavior somewhere around the GCC 4.8 versions, concerning TLS variables, producing a difference of firmware works vs. doesn’t)

By VFP setting you mean hard vs. soft float? There was a combobox(?) on the VisualGDB wizard page where I selected hard float, which is what the L4 has.
Could you specify what parts of the tool chain this could conflict with? I’m not super experienced with detailed embedded tool chain setup.

As a side note, what information does the “get settings from makefile” (or similar) button on the wizard’s manual config page actually read? It did not seem to fill in any of the fields. Perhaps because the makefile is somewhat complex and has sub folders of subprojects with own makefiles?

[support]

Hi,

The arm-eabi toolchain does not actually expect an operating system; it’s designed to work with barebone projects (or using RTOSes like FreeRTOS).

Thanks for clarifying that you have specified the FP option manually. Then the problem could be caused by incompatible settings entered somewhere. If you can reproduce this on a new project, could you archive it and send it to us? We should be able to locate the problem quickly for you.

The ‘get settings from Makefile’ button does a very basic scan of the Makefile for lines like “CFLAGS := xxx”. It is very basic and does not handle complex cases as there is no good way of importing those settings from large projects reliably.

[sktron]

Oh I would, but there is no project, I don’t get through the project creation wizard. When I hit “next” after selecting the MCU, it does this toolchain check, which fails.
I meanwhle installed the newest arm-none-eabi gcc, 5.4, this now gives a different error in the toolchain check: command not found (or similar, I translated) and then shows the path to the gcc install folder as the “command” – but only up to the bin folder, not an executable, in the “importing specs” step:

Tool arguments: -x c++ -dM -v -E – -ggdb -ffunction-sections -fno-exceptions -fno-rtti -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -DARM_MATH_CM4 -DSTM32L476RG -I.

 

[support]

Hi,

Sorry about that. You should be able to click “ignore” to get past the error message and get the project created. Then you can send us the project and we should be able to tell you what is going wrong with it.

Regarding the “command not found”, most likely you have specified an incorrect path when importing the toolchain. We normally recommend using the toolchains that VisualGDB itself downloads installs as they are tested to work out-of-the-box.

[sktron]

I uploaded a project where I selected the LED blink example provided by visualgdb, but the compiler selected at the beginning is the mentioned arm-none-eabi-gcc 4.8.3, and this fails to build. as described in the original post.

https://we.tl/kgE5ctjzac

 

[support]

Hi,

Thanks for the project, we have reproduced the problem. It happens because the original ARM toolchain has a bug that does not set the FPU type correctly for Cortex-M4 devices.

The toolchain that comes with VisualGDB fixes this; the original ARM one does not. You can work around this by adding -mfpu=fpv4-sp-d16 to your LDFLAGS, however the standard libraries that come with the toolchain are still compiled with the wrong FPU setting, so they may cause random crashes if your program is using hardware FP.

We would recommend switching to the toolchain shipped with VisualGDB to avoid this problem in the first place.

[Author]

Posts