Introducing flags like -mfloat-abi=softfp or -mfloat-abi=hard just causes more of these mismatch errors to appear. I know for a fact that it can work: using the STM Cube IDE i can upload just fine, but via PlatformIO and a raspberry Pi as host it doesn’t seem to work. Is there a type of flag i can add? Would be surprising if an ARM library doesn’t compile on an ARM device which targets an ARM microcontroler, right?
Notice how I link with libarm_cortexM4l_math instead of libarm_cortexM4lf_math. The first one requires hardfloat, the second one softfloat. The builder script does not setup any flags for the FPU (source), so by default you will have softfloat.
Your project does
so it tries to link with the Hardfloat version of the lib and one from an external source (this is wring since board_build.stm32cube.custom_dsp_library =yes is not set in your `platformio.ini). So you get the error
To link with the hardfloat library, you need to the compiler as well as linker flags. This can be done via a script.
First of all, thank you for your swift and comprehensive service which holds this forum together. I see you in tons of threads and you always provide great insight to ignorant people like me. Your suggestion worked right away and I’m now able to develop and debug STM32 DSP applications remotely from a raspberry pi. Good stuff!
I came across your script-suggestion here but was initially confused, since the code does not look like python an pylance doesn’t like it either:
"Import" is not definedPylancereportUndefinedVariable
But that’s just a minor thing.
I wish i was aware of the fact that the ARM DSP lib is already added, that would have saved me some time.
Technically it is mentioned in the documentation page for STM32Cube STM32Cube — PlatformIO latest documentation, but the given example platformio.ini would lead you to the linking errors shown in the issue. The devs should take care of this now.
An extra_script is executed by PlatformIO through the SCons engine and with a lot of runtime-injected functions, like Import(). Static code analyzers can impossibly recognize this situation when just given the .py file. Errors like these should be ignored in Python editors / IDEs.
I have the same issue with an STM32H7, and while I did include the flags for hard and fpv5_d16, that only got me through FreeRTOS compiling. Now when I got to link I have this issue.
I believe I understand the fix… but not the cause. For some reason it seems that STM32 projects just aren’t going to be linked correctly without setting the build_flags in the CCFLAGS AND LINKFLAGS sections? When I set them with build_flags that was effecting cc I think. Is there any way to set the LINKFLAGS to use floating point without the python script? That seems too cryptic for most people to figure out.
I’m fine with the python if I have to. But @maxgerhardt if you could help me understand the issue, it would help the next time I see something like this. Why would the linker flags not be accessible via the .ini?