Problem switching from [Eclipse/GNU MCU] to [Visual/VisualGDB]

[Noyb]

Btw, the Eclipse BSP provides the “arm-none-eabi-x” GCC suite, while the VisualGDB provides the “arm-eabi-x” suite. That might perhaps explain something.

[Noyb]

I changed some settings and it shows that the VisualBSP startup file is embedded without me wanting to :

1>VisualGDB/Debug/mcu__impl_stm32l4.o: In function `Reset_Handler’:
1>e:\…\mcu__impl_stm32l4.c(335): error : multiple definition of `Reset_Handler’
1>VisualGDB/Debug/startup_stm32l476xx.o:C:/Users/me/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32L4xxxx/StartupFiles/startup_stm32l476xx.c:945: first defined here
1>VisualGDB/Debug/mcu__impl_stm32l4__irq.o: In function `Default_Handler’:
1>e:\…\mcu__impl_stm32l4__irq.c(74): error : multiple definition of `Default_Handler’
1>VisualGDB/Debug/startup_stm32l476xx.o:C:/Users/me/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32L4xxxx/StartupFiles/startup_stm32l476xx.c:958: first defined here

[Noyb]

I selected AC6’s compiler as third-party toolchain, it switched to it by creating a new toolchain identified with a $(ToolchainID), adding the default BSP’s startup file to my project (without me asking for, since I already provide one), but removed $(ToolchainDir) macro. Any way to get the current toolchain folder which was asked when locating the ‘gdb.exe’ file ?

[Noyb]

Could you add ‘Pre-compile’ and ‘Pre-link’ “Custom Step” ?

[Noyb]

OK, with a great of patience I got it to work using the AC6 compiler (GCC 6.3.1 arm-none-eabi- / GDB 7.10.1.20160923-cvs).

Here’s the setting files to unzip into “c:\Ac6\SystemWorkbench\plugins\fr.ac6.mcu.externaltools.arm-none.win32_1.15.0.201708311556\tools\compiler\”

Now trying to revert back to VisualGDB supplied (arm-eabi-) toolchain to test if it still fails.

[Noyb]

Forgot the setting files, cannot edit my previous post.

Attachments:

You must be logged in to view attached files.

[Noyb]

OK, that’s it, returning to ‘arm-eabi-‘ makes the ‘HardFault_Handler’ to be invoked, even though it compiles just fine.

Reverting to AC’s toolchain.

Btw if you could stop adding ‘Device-secific files\startup_stm32l476xx.c’ each time I switch from one BSP to another, that would be super fine.

[Noyb]

Looks like there is a library problem regarding FPU support :

VisualGDB (GCC 7.2.0 GDB 8.0.1 rev 2) link against “1>attempt to open c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/lib/thumb/fpu/cortex_m4\libc.a succeeded” but fail at starting up.

While AC6 (GCC 6.3.1 GDB 7.10.1.20160923-cvs) link against “1>attempt to open c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.15.0.201708311556/tools/compiler/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard\libc.a succeeded” which works fine.

Obviously the supplied BSP falls short on hardware FPU support, even though allowing to select one specifically in the project’s ‘Property Pages / ARM Settings’.

[Noyb]

Another problem lies in the fact if you change the project’s ‘Property Pages / Configuration Properties / General / General / Output Directory’ to something else than the default “$(SolutionDir)$(Platform)\$(Configuration)\”, well, “you’re gonna have a bad time” trying to debug the project.

Same problem with ‘Property Pages / Configuration Properties / C/C++ / Output/ Object File Path’ into something else than the default “$(IntDir)” (ie. like “$(OutDir)”) doesn’t even compile at all, as if all object files had to be aggregated into one file.

[Noyb]

This BSP works out of the box : https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads (‘gcc-arm-none-eabi-7-2017-q4-major-win32.zip’ ZIP download)

Once unzipped into, say, “c:\GCC\gcc-arm-none-eabi-7-2017-q4-major-win32\”, you just have to locate the GDB exe and let VisualGDB do the rest.

Btw the GDB’s version parsing is broken, it always show “GDB(“, have to edit the ‘toolchain.xml’ file by hand (<GDBVersion>).

• This reply was modified 7 years, 1 month ago by Noyb.
• This reply was modified 7 years, 1 month ago by Noyb.

[support]

Hi,

If you are using MSBuild, the map file should already be created in the same directory as the ELF file. You can also override it via the Linker Settings -> Advanced (e.g. to $(OutDir)file.map).

Based on our quick research, the -save-temps option always saves the temporary files in the current directory (VisualGDB sets this to the project directory so that relative paths specified in project properties would work as expected). The only way we could suggest to override it would be to add a custom post-build step that would move the generated files to $(OutDir).

Regarding the ELF files, we would advise diagnosing it as follows:

• Dump build command lines from both Eclipse and VisualGDB. E.g. using procmon. If you are using MSBuild, VisualGDB stores all command lines in the .rsp files, so you can simply reuse them.
• Build the project manually using both command line sets. Ensure that the ELF files still produce different results.
• Try linking the files compiled using the Eclipse command lines using the VisualGDB linker command line. This should tell if the problem is related to the linker or the compiler.
• If the problem is linker-related, compare the link command lines and try removing half of the differences to see if this fixes the problem. Repeating this a few times should help pinpoint the setting responsible for the error.
• If the problem is compiler-related, use a similar approach to pinpoint the source file causing the problem and then the command line argument causing it.

Unfortunately this does involve non-trivial amount of troubleshooting, however given the size/complexity of the project, it could be easier than trying to guess the offending setting otherwise.

[Noyb]

Your ‘arm-eabi’ BSP doesn’t provide anything about HARD FPV4-SP libraries. That’s just it. Using a full featured BSP like the one provided with AC6 or directly from ARM (link provided above) solves the problem.

[support]

Hi,

Thanks for the update. The toolchain shipped with VisualGDB indeed uses a slightly different naming scheme, however should be able to locate the correct libraries as long as you specify the ARM core and the floating point mode. Either way, if switching to the original ARM toolchain solves the problem, VisualGDB fully supports it, so we would recommend simply keeping that toolchain.

[Noyb]

Please keep in mind I am in full ‘freestanding’, ‘nostdlib’, ‘nostartfiles’, ‘nodefaultlibs’, ‘no-builtin’ mode, hence the compiler should find the absolutely right compiler as it cannot make the usual guesses and find a fallback toolchain suitable enough. It has to be the one !

[support]

Hi,

Normally this should not be a problem, however if your code depends on some specific constraints of the ARM GNU Toolchain, simply using it instead of the toolchain installed by VisualGDB should be the easiest solution.

[Author]

Posts