Skip to main content
Georgy Moshkin
Senior
November 20, 2018
Solved

Why __FPU_PRESENT and AMR_MATH_CM4 are not defined for TrueStudio projects generated in STM32CubeMX?

  • November 20, 2018
  • 7 replies
  • 3811 views

Each time I add __FPU_PRESENT and AMR_MATH_CM4 to symbols to get project compile properly, yet getting 30 warning about __FPU_PRESENT redefined.

Project is made straight-forward: configure pins, select TrueStuido, pressing "generate code". Opening project in TrueStudio, build. Getting errors, adding __FPU_PRESENT and AMR_MATH_CM4 to symbols, building again with warnings.

This topic has been closed for replies.
Best answer by waclawek.jan

__FPU_PRESENT has always been defined in the CMSIS-mandated device headers, except that it used to be guarded. For example, this is from stm32f4xx.h from the SPL era

#if !defined (__FPU_PRESENT)

 #define __FPU_PRESENT            1      /*!< FPU present                                  */

#endif /* __FPU_PRESENT */  

JW

7 replies

Singh.Harjit
Senior
November 20, 2018

I ran into the same thing last week.

In the CMSIS 5 version of the processor file, there is a #define __FPU_PRESENT which is the redefinition the compiler is complaining about.

I'm using the STM32F411CE, so, for me, this file is called stm32f411xE.h and it is located at:

<your installation specific>\CMSIS\Device\ST\STM32F4xx\Include\stm32f4

If you include your version of stm32f411xE.h in your C code where it is necessary, then you won't need to add __FPU_PRESENT at the command line. You will still need to add ARM_MATH_CM4 because that is for CMSIS math.

Apparently, this is a change from CMSIS 4 and vendors haven't updated the tool chains for this change.

Amel NASRI
Technical Moderator
November 22, 2018

Hi @Georgy Moshkin​ ,

To more understand the faced issue, could you please precise the following:

  1. which device did you selected?
  2. do you still have the same problem with STM32CubeMX V5?
  3. can you share a .ioc file to reproduce it?

Thanks

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Tesla DeLorean
Guru
November 22, 2018

It's ARM, not AMR

Pretty sure you don't need to define them explicitly, the compiler should be doing this if the Core and FPU settings are coherent with having hardware floating point support. ie cpu=cortex-m3 isn't going to get you there, neither will SoftFP settings.

Bringing in the normal .H files for the parts should allow this to work, look at the defines pushed into the compiler command line more critically.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Nawres GHARBI
Technical Moderator
November 23, 2018

Hi @Georgy Moshkin​ 

Could you please attach your ioc it will be helpful to get the issue's root cause

Georgy Moshkin
Senior
November 27, 2018

I could not reproduce the problem, my old *.ioc are converted to TrueStudio projects and compile without errors.

Check my STM32 Bootloader - flash your STM32 with AES-encrypted binaries right from web browser!
Singh.Harjit
Senior
November 27, 2018

​The issue is that __FPU_PRESENT is now defined in the CMSIS device files. I've attached an example of the header file. Just search it for "__FPU_PRESENT".

In Georgy's case (and my case), when we defined __FPU_PRESENT on the compiler command line, there is a redefinition because it is also defined in the CMSIS device file.

waclawek.jan
Super User
November 27, 2018

__FPU_PRESENT has always been defined in the CMSIS-mandated device headers, except that it used to be guarded. For example, this is from stm32f4xx.h from the SPL era

#if !defined (__FPU_PRESENT)

 #define __FPU_PRESENT            1      /*!< FPU present                                  */

#endif /* __FPU_PRESENT */  

JW

Singh.Harjit
Senior
November 27, 2018

​Thank you! I've been wondering how this suddenly became an issue and your detective work completely answers it!

ST needs to add the guard back because it is creating an issue on Embedded Studio, too.