cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE: Minor problem in Eclipse indexing result for STM32 projects

OldManVimes
Associate

I have a problem report that I'd like to submit.

Description:

In Eclipse, C/C++ editor views gray out parts that it 'knows' are not included in a build. For an STM32 project this does not work flawlessly resulting in some misunderstanding.

Replication:

Create a STM project for a CPU that defaults to hardware floating points using GCC. An example is a STM32Hxx project.

Enable at least one peripheral (RCC in my case, but this step may be optional).

Compile the project and then and open the source file that contains SystemInit()

Observe that according to the Eclipse editor, __FPU_USED == 0 This is unexpected and hopefully wrong!

Also observe that the compiled output contains this conditional block, so the editor is incorrect and the binary is correct. Observe core_cm7.h for additional context/proof. Hint: It relates to __SOFTFP__

Cause:

The indexer operates on a set of pre-processor flags that differs from the ones used during compilation. It is simply not aware of all compiler flags that affect compiler built-in #define-s.

The indexer bases its work on the output from:

${COMMAND} ${FLAGS} -E -P -v -dD "${INPUTS}"

That translates to:

arm-none-eabi-g++ -E -P -v -dD C:/Users/Me/STM32CubeIDE/workspace_1.0.0/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C 

Note: Odd that ${FLAGS} is empty. This may be a clue.

This in turn outputs the following (and more).

#define __SOFTFP__ 1

#define __VFP_FP__ 1

So what is incorrect is that __SOFTFP__ is defined. It should not be.

Reference: https://wiki.debian.org/ArmEabiPort (look for __SOFTFP__)

On a hunch I changed the indexer command to:

${COMMAND} ${FLAGS} -mfpu=fpv5-d16 -mfloat-abi=hard -E -P -v -dD "${INPUTS}"

That expands to:

xarm-none-eabi-g++ -mfpu=fpv5-d16 -mfloat-abi=hard -E -P -v -dD C:/Users/Me/STM32CubeIDE/workspace_1.0.0/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C

This in turn outputs the following (and more).

#define __VFP_FP__ 1

No more __SOFTFP__. Success!

So from what I can deduce there is a problem in the sense that some compiler flags are relevant to the indexer input generation and these are not passed.

The net effect of this is one of minor confusion about what code gets compiled. The effect is limited to code that depends on compiler provided #define-s.

I hope this may be of use to you. Cheers.

2 REPLIES 2
Mary Solomo
Associate II

Hello,

I think I'm having a similar issue. I am working on STM32G4 and used the STM32CubeMX and STM32IDE tools. After generating the code using the CubeMX and copying DSP libraries from CubeMX repository to project/Drivers folder, I encounter this error during compile: Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)

Well, for this MCU, __FPU_PRESENT is already set to 1. But, Upon checking core_cm4.h, I noticed that __VFP_FP is not defined, and thus FPU_USED will be set to 0.

Please let me know how to resolve the __VFP_FP issue or is there anything I missed.

Note that I've used the DSP library for STM32F4 and Atollic Truestudio and never encountered this problem.

Thanks

Mary Solomo
Associate II

Sorry, I think it is the SOFTFP that is being set as 1. It should be set as 0 so as to define FPU_USED to 1.

#elif defined ( __GNUC__ )

 #if defined (__VFP_FP__) || !defined(__SOFTFP__)

  #if defined (__FPU_PRESENT) && (__FPU_PRESENT == 1U)

   #define __FPU_USED    1U

  #else

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

   #define __FPU_USED    0U

  #endif

 #else

  #define __FPU_USED     0U

 #endif