FreeRTOS Compilation Errors (Type/Order) Despite Correct STM32CubeIDE Configuration

[iotech_sehun]

Hello,

I'm encountering severe compilation errors in an STM32H7 dual-core project (eth_project_CM7) using FreeRTOS (v10.4.6) and LWIP configured via STM32CubeMX (version 6.9.2). All errors point to FreeRTOS header files (task.h, list.h).

The core issue appears to be related to header file inclusion order and the compiler's inability to find FreeRTOS basic type definitions (BaseType_t, TickType_t, etc.), despite thorough configuration checks.

---

1. Project Details

• MCU: STM32H757XI (Cortex-M7 core project: eth_project_CM7)

• IDE: STM32CubeIDE (latest version)

• Middleware: FreeRTOS (M7 enabled), LWIP enabled.

• Language Standard: GNU11 (-std=gnu11) is set in the C Compiler.

---

2. Example Errors (Cascading Failures)

The errors are typical of missing type definitions, causing a cascade of syntax errors throughout the FreeRTOS headers:

• #error "include FreeRTOS.h must appear in source files before include task.h"

• unknown type name 'BaseType_t'

• expected declaration specifiers before 'TaskHandle_t'

• old-style parameter declarations in prototyped function definition

---

3. Troubleshooting Steps Taken (Configuration Confirmed)

I have checked and confirmed all standard fixes as follows:

• Header Inclusion Order Fix (Macro): The preprocessor macro FREERTOS_PLUS_INCLUDE_FREERTOS_H is correctly defined in the MCU/MPU GCC Compiler -> Preprocessor settings. This should force the correct inclusion order but is not working.

• Required Include Paths: All necessary FreeRTOS and Configuration paths are correctly included in the MCU/MPU GCC Compiler -> Include paths:

  • ../Core/Inc (Contains FreeRTOSConfig.h)

  • ../Middlewares/Third_Party/FreeRTOS/Source/include

  • ../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2

  • ../Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F

• C Language Standard: The C Compiler standard is explicitly set to GNU11 (-std=gnu11) to prevent C89/C90 syntax issues.

• Clean and Rebuild: I have repeatedly performed Project Clean, C/C++ Index Rebuild, and IDE restarts.

---

4. Request for Help

Since all configuration settings are confirmed correct, I suspect a deeper issue related to the compiler's preprocessor behavior with the FreeRTOS header files, possibly unique to the H7 M7 core or an IDE bug.

Has anyone encountered this specific combination of persistent FreeRTOS header errors when FREERTOS_PLUS_INCLUDE_FREERTOS_H is correctly set and the Include Paths are complete?

Any advice on where else to look (e.g., linker settings, specific portmacro.h tweaks, or IDE indexing workarounds) would be highly appreciated!

Thank you!

[Souhaib MAZHOUD]

Hello @iotech_sehun 

Thank you for posting! and welcome to STCommunity!

The latest version of STM32CubeMX is 6.15.0. Have you tried it?

BR, Souhaib

[iotech_sehun]

Hello Souhaib,

Thank you very much for the quick response.

I have checked the version of the integrated CubeMX engine within my STM32CubeIDE. I can confirm that I am already using the latest CubeMX version, 6.15.0, for this project configuration.

Despite using the latest available CubeMX configuration (6.15.0) and having confirmed all other settings (as detailed in my original post: correct include paths, FREERTOS_PLUS_INCLUDE_FREERTOS_H set, and C standard set to GNU11), the persistent FreeRTOS compilation errors remain.

This suggests the issue is likely not version-related but perhaps a deeper configuration conflict or a specific bug in how the H7 M7 core handles the FreeRTOS middleware package from the latest F7/H7 Firmware (currently H7 V1.12.1 is selected in my project).

Could you please advise on any other known workarounds for this specific combination of errors, or if there is a recommended setting outside the standard paths and preprocessor macros that might be required for the latest FreeRTOS headers on the STM32H7 M7 core?

Thank you for your continued assistance.

BR, Sehun

[Souhaib MAZHOUD]

Hello @iotech_sehun 

Could you please provide your project so that we can further investigate this issue?