Error: Compiler generates FPU instructions without an FPU - How to fix this?

[White_Fox]

Hi guys

I made a project with CubeMX for a STM32F334. This project built fine already multiplet times.

Now, I get suddenly this error message:
#error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"

As I said, the project was built fine most times, and in the SystemInit function in system_stm32f3xx.c, there is the fpu present check. I do not see any reason why this message comes up.

As I looked for an explanation, I found someone whith this problem, and it seemed to be about wrong including order. If this is a reason: How can I ensure the right order?

I already regenerated the code by CubeMX multiple times. If I accidently removed an include file or did other things wrong, I assumed that this will fix the problem, but it does not. Does anyone have any other ideas how to solve?

Best regards

[Pavel A.]

Check the compiler options in project settings? Is floating point selected there?

STM32F3 does not have a FPU so FPU instructions should not be generated.

 

 

[Tesla DeLorean]

It would likely be a mismatch in -cpu, -arch or --fpu command line options, where by it thinks its build for a cm3 vs cm4, or a soft fp

The Linker can also complain if objects or libraries mismatch.

 

[White_Fox]

Hi guys

Thanks for replying.

I'm quietly sure that my F334 has a fpu. Even though it was a long time ago, but I used it already, and in the current project I'm working with arm_math.h and it's float32_t types, and it built fine yesterday and today morning.

The error message in my first post contains a link to a file "Drivers/CMSIS/include/core_cm4.h". I think, as the F334 bases on a M4 core, this should be fine (shouldn't it?).

The compiler settings does also not looking wrong to me, but to be hornest I have no idea what really would right or wrong, so I better attach a screenshot of them.

[Tesla DeLorean]

>>I'm quietly sure that my F334 has a fpu

Yes, me too, it's using an CM4F implementation, technically I think people could option a CM4 without the FPU, not sure anyone has. The 32-bit FLOAT engine isn't remotely comparable to to 80x87 or 6888x FPU, and ill-suited to a lot of math.

However this is a TOOL CHAIN complaint, so OPTIONS, or INCLUDES, have been pulled in where there's an inherent mismatch of settings vs expectations.

Look for circular references, multiple / different instances / versions of include files being mixed together.

Something where you generate and review the pre-processor output stage might be the most enlightening.

[Pavel A.]

Sorry, my bad. It has FPU, per the data sheet.

Your project path has spaces. Better avoid this.

[waclawek.jan]

Show the command line used to compile and the complete output of compilation (copypaste text, don't screenshot).

JW

[White_Fox]

Here is the whole console output after a build run:

15:57:26 **** Incremental Build of configuration Debug for project SPV ****
make -j32 all
arm-none-eabi-gcc "../Core/Src/trs.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/trs.d" -MT"Core/Src/trs.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/trs.o"
In file included from ../Drivers/CMSIS/DSP/Include/arm_math.h:322,
from ../Core/Inc/trs.h:12,
from ../Core/Src/trs.c:10:
../Drivers/CMSIS/Include/core_cm4.h:105:8: error: #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
105 | #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
| ^~~~~
make: *** [Core/Src/subdir.mk:49: Core/Src/trs.o] Error 1
"make -j32 all" terminated with exit code 2. Build might be incomplete.

15:57:26 Build Failed. 2 errors, 0 warnings. (took 280ms)

[Andrew Neil]

#error "Compiler generates FPU instructions for a device without an FPU (check _FPU_PRESENT)"

That #error directive will undoubtedly be within some #if checks.

So go to line 105 in core_cm4.h and see what it's checking - then check how your project has those things configured

[waclawek.jan]

In trs.h, before #include "arm_math.h" insert #include "stm32f3xx.h"

---

> So go to line 105 in core_cm4.h and see what it's checking

It's checking presence of _FPU_PRESENT symbol, exactly as the wording of the error says ;)

JW

[White_Fox]

It is getting more interesting now. I did as waclawek.jan told me, and I get a new error.

I do not have a file stm32f3xx.h in my Core/Inc directory, but a file stm32f3xx_it.h. I tried both, and get the same error in both cases:

Description Resource Path Location Type
cannot find -larm_cortexM4lf_math: No such file or directory SPV C/C++ Problem

But I remember that I worked at this file before the fpu problem occured first time, and including the arm_math.h file was related of one of the last actions I did.

To the new error message: I included the arm_math.h several times before (and used it!) without any problem. It is a miracle to me why it provokes this trouble now. I also have the file in my project folder, but did not added its path to the linker. But even I do so, the error message above remains.

[White_Fox]

I commented some uses of arm_math.h and refering code lines out. Unfortunatelly I have to renew some important things, but it builds now again without compiler errors.

Circular references as Tesla DeLorian mentioned are likely, I will investigate that deeper next week.

I'm glad that my the project builds now, but before I mark the thread as solved, I want to find out what went wrong in detail.

Thank you very much for your comments and gentle help, this forum is great.

See you next week. :)

[waclawek.jan]

>>I'm quietly sure that my F334 has a fpu

> Yes, me too, it's using an CM4F implementation, technically I think people could option a CM4 without the FPU, not sure anyone has.

AFAIK all STM32 with Cortex-M4 do have the FPU.

I think the initial ARM proposal did not count with Cortex-M4 without FPU, as that was a distinctive feature from Cortex-M3; but later probably some of ARM's licencees wanted to have a smaller core configuration (maybe FPU presence also impacts ARM's roayalties?) yet benefit from other Cortex-M4 features and/or compatibility. So for example the lower-end Nordic nRF52xx don't have FPU, higher-end do. Similarly some of the ATSAM4 don't have FPU (e.g. the low-power SAM4L) some do.

JW

[waclawek.jan]

I don't know how would including a header file (stm32f3xx.h) would lead to a complaint on missing library, there should be no such relationship. That file btw. is the standard CMSIS-mandated device header (more precisely a header which includes it), i.e. the header which provides you symbols like GPIOA, USART1, etc.

But instead of including that file, you can alternatively just simply add

#define __FPU_PRESENT  1U

before including arm_math.h

JW

[White_Fox]

Yes, I also would think that including such a standard CMSIS file can occur such faults.

 

---

@waclawek.jan wrote:

#define __FPU_PRESENT  1U

Meh....very dirty hack...

Nevertheless, I think I better post the project here:
https://drive.google.com/file/d/17_1CG1do-ibiIFhB936ovG-yIqqe8FCl/view?usp=drivesdk

Just go to the trs.h file and comment the include line out or remove the comment, and try to build. Maybe some of you see what's going wrong here. It is a very small project I think.

[waclawek.jan]

> Meh....very dirty hack...

What's dirty in that, exactly?

The files you are trying to compile are written so that they expect this symbol to be defined by the user. That's because the user is the one, who has the knowledge whether the given chip does have FPU or not, and should convey this knowledge through tis symbol. As I've said above, this usually gets defined through the CMSIS-mandated device headers and that is the method you are supposed to use - and supposedly you would not find that meh and dirty. As I've said, I see no reason why inclusion of the device headers would cause a *linker* error.

---

The link you gave requires me to log in to google, which I won't do. I know ST insists on the idiotic restriction of .zip files here, users usually use 7zip to circumvent this. Other users use github to share code, which allows anonymous downloads, too.

Although, looking at the directory listing, it appears this is a CubeIDE project; I don't use CubeIDE so I personally probably won't be able to compile the project with identical settings as you do; so maybe somebody else would help you.

JW

 

[waclawek.jan]

I don't think there's any such limitation at the moment at all.

But again, chances are, that problems stem from some particular setting at your side, so let's try to look at that. Again, start with posting the complete command line and the complete output including the error.

JW

[White_Fox]

Ok, I did so as waclawek.jan told me. I defined the fpu_setting in my trs.h file, right before including arm_math.h. It works now again, great.

As I packed the project, I commented this line out, so you should get the same error as I get before if you try to build. If you try it by yourself, just take a look at .../SPV/Core/Inc/trs.h. This is the file where the fault happens.

Here is the console output when I build without arm_math.h:

 

09:17:26 **** Build of configuration Debug for project SPV ****
make -j32 all 
arm-none-eabi-gcc "../Core/Src/main.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/main.d" -MT"Core/Src/main.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/main.o"
arm-none-eabi-gcc "../Core/Src/stm32f3xx_it.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/stm32f3xx_it.d" -MT"Core/Src/stm32f3xx_it.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/stm32f3xx_it.o"
arm-none-eabi-gcc "../Core/Src/trs.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/trs.d" -MT"Core/Src/trs.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/trs.o"
arm-none-eabi-gcc -o "SPV.elf" @"objects.list" -larm_cortexM4lf_math -mcpu=cortex-m4 -T"C:\Users\Oli\E-Technik Studium\Master\Abschlußarbeit II\Software\SPV\STM32F334C8TX_FLASH.ld" --specs=nosys.specs -Wl,-Map="SPV.map" -Wl,--gc-sections -static -L../Drivers/CMSIS/Lib/GCC/ --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
Finished building target: SPV.elf
 
arm-none-eabi-size SPV.elf 
arm-none-eabi-objdump -h -S SPV.elf > "SPV.list"
 text	 data	 bss	 dec	 hex	filename
 14704	 4	 2020	 16728	 4158	SPV.elf
Finished building: default.size.stdout
 
Finished building: SPV.list
 

09:17:27 Build Finished. 0 errors, 0 warnings. (took 559ms)

 

 

Now the console output after build with arm_math.h, but without #define FPU_PRESENT:

 

9:19:09 **** Incremental Build of configuration Debug for project SPV ****
make -j32 all 
arm-none-eabi-gcc "../Core/Src/trs.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/trs.d" -MT"Core/Src/trs.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/trs.o"
In file included from ../Drivers/CMSIS/DSP/Include/arm_math.h:322,
 from ../Core/Inc/trs.h:13,
 from ../Core/Src/trs.c:10:
../Drivers/CMSIS/Include/core_cm4.h:105:8: error: #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
 105 | #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
 | ^~~~~
make: *** [Core/Src/subdir.mk:49: Core/Src/trs.o] Error 1
"make -j32 all" terminated with exit code 2. Build might be incomplete.

09:19:10 Build Failed. 2 errors, 0 warnings. (took 236ms)

 

The error output tells:

 

Description	Resource	Path	Location	Type
#error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"	core_cm4.h	/SPV/Drivers/CMSIS/Include	line 105	C/C++ Problem

 

 

Now the console output with #define FPU_PRESENT 1U in trs.h:

 

09:24:07 **** Incremental Build of configuration Debug for project SPV ****
make -j32 all 
arm-none-eabi-gcc "../Core/Src/main.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/main.d" -MT"Core/Src/main.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/main.o"
arm-none-eabi-gcc "../Core/Src/stm32f3xx_it.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/stm32f3xx_it.d" -MT"Core/Src/stm32f3xx_it.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/stm32f3xx_it.o"
arm-none-eabi-gcc "../Core/Src/trs.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DARM_MATH_CM4 -DSTM32F334x8 -DUSE_FULL_LL_DRIVER -DHSE_VALUE=8000000 -DHSE_STARTUP_TIMEOUT=100 -DLSE_STARTUP_TIMEOUT=5000 -DLSE_VALUE=32768 -DEXTERNAL_CLOCK_VALUE=8000000 -DHSI_VALUE=8000000 -DLSI_VALUE=40000 -DVDD_VALUE=3300 -DPREFETCH_ENABLE=1 -c -I../Core/Inc -I../Drivers/CMSIS/DSP/Include -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/trs.d" -MT"Core/Src/trs.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/trs.o"
arm-none-eabi-gcc -o "SPV.elf" @"objects.list" -larm_cortexM4lf_math -mcpu=cortex-m4 -T"C:\Users\Oli\E-Technik Studium\Master\Abschlußarbeit II\Software\SPV\STM32F334C8TX_FLASH.ld" --specs=nosys.specs -Wl,-Map="SPV.map" -Wl,--gc-sections -static -L../Drivers/CMSIS/Lib/GCC/ --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
Finished building target: SPV.elf
 
arm-none-eabi-size SPV.elf 
arm-none-eabi-objdump -h -S SPV.elf > "SPV.list"
 text	 data	 bss	 dec	 hex	filename
 14704	 4	 2020	 16728	 4158	SPV.elf
Finished building: default.size.stdout
 
Finished building: SPV.list
 

09:24:08 Build Finished. 0 errors, 0 warnings. (took 496ms)

 

Edit:
I'm curious what you guys will find. The CubeMX file is also included.

 

 

[Pavel A.]

Let's do a quick experiment.

Run CubeMX v. 6.11.1. Created a new project for the 1st STM32F334 listed in the MCU selector. It was STM32F334C4T6. Did not configure anything, just set the project type as STM32CubeIDE and generated code.

Guess what, the CMSIS device definition file stm32h334x8.h  does contain 

 

 

#define __FPU_PRESENT 1U

 

 

Can you try this for your specific STM32F3?

 

[White_Fox]

---

@Pavel A. wrote:

Guess what, the CMSIS device definition file stm32h334x8.h  does contain 

---

Ofcourse, I would expect that the fpu-present-flag is defined somewhere.

This project was set up with CubeMX, so I did already what you told me. The .ioc-file is in the attachement above.

[White_Fox]

Even though if I marked a post as solution, I still would like to know what happened under the hood. Why fires the compiler the error if I include arm_math.h in trs.h, but accept it somewhere else?

Just for a better understanding.

Nevertheless, thank you all for the discussion and your help.

[waclawek.jan]

> Why fires the compiler the error if I include arm_math.h in trs.h, but accept it somewhere else?

"somewhere else" are presumably files, which do #include stm32f3xx.h directly or (most probably) indirectly, as that's the expected way how you let the compiler know which STM32 are you using, and thus, whether it does have FPU or not.

That's why I recommended to #include stm32f3xx.h into trs.c; and to me, the real mystery is, why would that cause a linker error.

As I've said I don't use CubeIDE so can't try to compile your project.

JW