Motion_EC and Motion_MC libraries will not link after switching to SW & HW floating point support.

[Rstua.1]

Our project compiled and linked with no issues when set to HW floating point support. (i.e. The Properties -> C/C ++ Build -> Settings -< Tool Settings -> MCU Settings -> Floating-point ABI is set to "Hardware implementation ...".). However, some math calculations were (very) incorrect when I ran the program. I switched from "Hardware implementation ..." to "Mix HW/SW implementation..." as this worked before we upgraded all our STMicro software (i.e. libraries and tools). But now I see these errors when I try to compile the project:

c:\st\stm32cubeide_1.3.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: error: ../Middlewares/ST/STM32_MotionEC_Library/Lib\MotionEC_CM4F_wc32_ot_hard.a(motion_ec.o) uses VFP register arguments, LynQ Host.elf does not
c:\st\stm32cubeide_1.3.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: failed to merge target specific data of file ../Middlewares/ST/STM32_MotionEC_Library/Lib\MotionEC_CM4F_wc32_ot_hard.a(motion_ec.o)
c:\st\stm32cubeide_1.3.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: error: ../Middlewares/ST/STM32_MotionMC_Library/Lib\MotionMC_CM4F_wc32_ot_hard.a(motion_mc.o) uses VFP register arguments, LynQ Host.elf does not
c:\st\stm32cubeide_1.3.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: failed to merge target specific data of file ../Middlewares/ST/STM32_MotionMC_Library/Lib\MotionMC_CM4F_wc32_ot_hard.a(motion_mc.o)

... I am confused. What does it mean when the compiler says "... motion_mc.o uses VFP register arguments, LynQ Host.elf does not ..."? Why is this error not exist when I only have HW support, but does exist when I have both HW and SW support??

-thanks

[Miroslav BATEK]

If you use libraries ending with _hard you must use the Floating point ABI settings "Hardware implementation".

If you use libraries without this sufix you must use the Floating point ABI settings "Mix HW/SW implementation".

The libraries are compiled with this different settings and settings in your project must be the same.

[Rstua.1]

Thank you for your response Miroslav. But if I use "Hardware Implementation" my function which depends heavily on trigonometric functions (I am calculating spherical harmonics for magnetic declination) return unexpected results.

Before we upgraded our STMicro libraries, we had configured our project for "Mix HW/SW implementation" and both the EC / MC libraries and the spherical harmonics calculations were working as expected. Now I have to configure for "Hardware implementation" to avoid compiler errors. And I suspect configuring for "Hardware implementation" causes my spherical harmonic calculations to become unusable. (I am expecting magnetic declination values should range from about -25 to 25 degrees. But current magnetic declination is about 180 degrees no matter where in the world I look.)

[Miroslav BATEK]

You can still use the "Mix HW/SW implementation" settings, but in this case use MotionEC_CM4F_wc32_ot.a and MotionMC_CM4F_wc32_ot.a libraries in your project.

[Rstua.1]

Again, thank you for your answer Miroslav, but I have not been able to find files in the current version of the STMicro libraries with out the "_hard" in their name. Further, the IOC configuration GUI only has selections to either include or exclude the MotionEC and MotionMC libraries. There does not appear to be a selection to switch away from the "_hardware" version of the MotionEC and MotionMC libraries in the IOC configuration GUI.

[Miroslav BATEK · Accepted solution]

I see.

You can find the libraries inside the X-CUBE-MEMS1 package which you can download from st.com

https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-mems1.html

[Ozone]

I don't know Motion lib details.

But ABI-wise, "soft" and "soft_fp" are compatible, but "hard" is not.

For the float-abi setting "hard", everthing needs to be compiled that way.

[Rstua.1]

I will try this Miroslav, if it works this will be our short term fix. But would it not be better if all our code used the hardware floating point feature of the STMicro processor? This is a battery operated handheld device. And I would think using the hardware floating point feature of the STMicro processor would extend the battery life when compared to using the software emulation for floating point.

[Miroslav BATEK]

I recommend this article

https://embeddedartistry.com/blog/2017/10/11/demystifying-arm-floating-point-compiler-options/

[Miroslav BATEK]

Softfp mode is not software emulation of FPU. You can read following article:

https://embeddedartistry.com/blog/2017/10/11/demystifying-arm-floating-point-compiler-options/

It seems that if you want to use hard option you need to fix issue in your function (spherical harmonics for magnetic declination), but I'm sorry this is out of my expertise.