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

[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.

[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

[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. :)

[White_Fox]

Hi everyone

I think I have the problem identified now, but no idea how to solve yet.

From my headerfile trs.h:

ifndef INC_TRS_H_
#define INC_TRS_H_

#include <stdint.h>
#include "arm_math.h"

//...
void setHrtimPwmToAll(float32_t pwm);

#endif /* INC_TRS_H_ */

The trouble starts as I include the arm_math.h. I need it to declare the setHrTimPwmToAll() function, or the compiler comes back with struggling what a float32_t is. And as I include the arm_math.h file, I get the fpu missetting error. I assume that there is a switch which is just toggled (where it better should be set), as I include the arm_math.h also in the main file (and in trs.c, where I did much more float32_t-stuff before I declared a function in trs.h). Trying to change the include file order did no success, removing them in other files also do not makes anything better.

As I include the arm_math.h in trs.h, the fpu missetting error occurs, no matter what I do outside the trs.h file.

Has anyone a solution for this?

[waclawek.jan · Accepted solution]

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

[White_Fox]

---

@waclawek.jan wrote:

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

What's dirty in that, exactly?

---

Well, at least to me, these project header files have a kind of do-not-touch-me-smell, and to override these configurations (even though it would be a fix) seems a little odd to me as it seems not to be intended to be re-configured by the user.

I'm also not sure, if this is not the problem but a symptome of another. I included the arm_math.h already in the trs.c file and main.c file successfully with no problems, maybe there is something which prevents me to use an already in external files defined type and this fault will bite me next time at another place?

But I will try it next week...better to get it working even in that way.

The link you gave requires me to log in to google, which I won't do.

---

I can understand this, I assumed that this would be public to all and I want to delete this files later. Do you have an idea how long I can edit and delete an attachement here in the forum?

[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