Compiler errors: unknown type name 'HAL_LockTypeDef' and 'HAL_StatusTypeDef' using CubeMX and Atollic TrueSTUDIO 7.1

[joseph23]

Posted on August 11, 2017 at 17:36

I'm attempting to compile a STM32F303RE project using the Cube MX generated HAL drivers for Atollic TrueStudio 7.1. I'm getting 39 errors on stm32f3xx_hal_dma.h, stm32f3xx_hal_uart.h, and

stm32f3xx_hal_uart_ex.h wherever a HAL_StatusTypeDef or HAL_LockTypeDef type is referenced.

>:(

Each header file that has these errors has a #include 'stm32f3xx_hal_def.h' where the type is defined at the top of the file.

This seems to be related to using the HAL drivers in source files other than main.c. I've created a bare bones blinky project using CubeMX and I initially had the same errors, until Iincludedstm32f3xx_hal.h in the external source file that I created that calls the HAL driver functions. Unfortunately this solution didn't work with my more complicated project.

If the header file defining the type is right there, why in the world would the compiler not see it? I feel like I'm missing something really basic, but I can't figure this out. Any help would be greatly appreciated!

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on August 11, 2017 at 17:42

Check module import settings in project's 

stm32f3xx_hal_conf.h file

[joseph23]

Posted on August 11, 2017 at 19:10

Ok, so I'm using a UART, GPIO, and a timer in this project.  Currently the stm32f3xx_hal_conf.h file shows the following:

#define HAL_MODULE_ENABLED

/*#define HAL_ADC_MODULE_ENABLED */

/*#define HAL_CAN_MODULE_ENABLED */

/*#define HAL_CEC_MODULE_ENABLED */

/*#define HAL_NAND_MODULE_ENABLED */

/*#define HAL_NOR_MODULE_ENABLED */

/*#define HAL_PCCARD_MODULE_ENABLED */

/*#define HAL_SRAM_MODULE_ENABLED */

/*#define HAL_HRTIM_MODULE_ENABLED */

/*#define HAL_OPAMP_MODULE_ENABLED */

/*#define HAL_SDADC_MODULE_ENABLED */

/*#define HAL_TSC_MODULE_ENABLED */

/*#define HAL_COMP_MODULE_ENABLED */

/*#define HAL_CRC_MODULE_ENABLED */

/*#define HAL_CRYP_MODULE_ENABLED */

/*#define HAL_DAC_MODULE_ENABLED */

/*#define HAL_I2S_MODULE_ENABLED */

#define HAL_IWDG_MODULE_ENABLED

/*#define HAL_LCD_MODULE_ENABLED */

/*#define HAL_LPTIM_MODULE_ENABLED */

/*#define HAL_RNG_MODULE_ENABLED */

/*#define HAL_RTC_MODULE_ENABLED */

/*#define HAL_SPI_MODULE_ENABLED */

#define HAL_TIM_MODULE_ENABLED

#define HAL_UART_MODULE_ENABLED

//#define HAL_USART_MODULE_ENABLED

/*#define HAL_IRDA_MODULE_ENABLED */

/*#define HAL_SMARTCARD_MODULE_ENABLED */

/*#define HAL_SMBUS_MODULE_ENABLED */

/*#define HAL_WWDG_MODULE_ENABLED */

/*#define HAL_PCD_MODULE_ENABLED */

#define HAL_GPIO_MODULE_ENABLED

#define HAL_DMA_MODULE_ENABLED

#define HAL_RCC_MODULE_ENABLED

#define HAL_FLASH_MODULE_ENABLED

#define HAL_PWR_MODULE_ENABLED

#define HAL_CORTEX_MODULE_ENABLED

//#define HAL_I2C_MODULE_ENABLED

And in the System Configuration section:

#define VDD_VALUE ((uint32_t)3300) /*!< Value of VDD in mv */

#define TICK_INT_PRIORITY ((uint32_t)0) /*!< tick interrupt priority (lowest by default) */

#define USE_RTOS 0

#define PREFETCH_ENABLE 1

#define INSTRUCTION_CACHE_ENABLE 0

#define DATA_CACHE_ENABLE 0

I'm not using any extended UART or USART functionality.  Just a vanilla 115200 8N1 UART.

I don't see anything that is off here, but it's very possible that I'm missing something.

Thanks for the quick response!

[joseph23]

Posted on August 14, 2017 at 16:34

To use a HAL driver is there anything that needs to be done other than to include the header for that file?  If there are other headers to include, does the order of inclusion matter?

[Tesla DeLorean]

Posted on August 14, 2017 at 17:07

The compiler needs a command line define USE_HAL_DRIVER so that the ♯ include 'stm32f3xx.h' pulls in the conf.h file.

You should review the sample/example/template projects under the Cube install, and look at the project metadata, and project specific files.

[Morty Morty]

Posted on August 31, 2017 at 11:21

This is a bug in stm32f3xx_hal_def.h. It defines HAL_StatusTypeDef and HAL_LockTypeDef, yet only after(!) including stm32f3xx.h, which in turn includes files that require HAL_StatusTypeDef and HAL_LockTypeDef. Thus if you move the include behind those definitions it compiles fine.

[Morty Morty]

Posted on September 11, 2017 at 16:09

Could someone from ST confirm that is is/is not a bug?

[Mike Hooper]

Posted on September 27, 2017 at 16:56

Morty,

I have confirmed the same issue. And I have confirmed that your suggested fix does indeed work.

Thanks!

[Amel NASRI]

Posted on September 11, 2017 at 17:34

Hi

moritz.struebe

‌,

Please share your .ioc file allowing to reproduce issue.

-Amel

[Morty Morty]

Posted on September 11, 2017 at 17:51

st.mcu

‌: This is not related to CubeMx, but a bug in the HAL-Library: Create any project with STM32CubeMx that will include the

stm32f3xx_hal_conf.h

in your project (e.g. STM32F334). Create a new C-File:

#include 'stm32f3xx_hal_rcc.h'

void f(void);

Try to compile that C-File.

[Tesla DeLorean]

Posted on September 11, 2017 at 21:22

So how is it that I can build

STM32Cube_FW_F3_V1.9.0\Projects\STM32F303ZE-Nucleo\Examples\CRC\CRC_Example\MDK-ARM

without the world ending?

Defines : USE_HAL_DRIVER,STM32F303xE,USE_STM32F3XX_NUCLEO

Project has stm32f3xx_hal_conf.h defining modules pulled

File pulls via ♯ include 'stm32f3xx_hal.h'

[Morty Morty]

Posted on July 06, 2018 at 12:37

Why is this marked as resolved? As far as I can see this is still an issue with STM32Cube FW_F3 V1.9.1!

[Amel NASRI]

Posted on July 06, 2018 at 13:19

Hi

moritz.struebe

,

I marked this question for action to review it later.

The action from my side is resolved as I haven&39t so much things to add. But your question remains open as you didn&39t selected one of the answers as correct.

In STM32Cube packages we have an inclusion model that has to be respected.

It is described in

https://www.st.com/resource/en/user_manual/dm00122016.pdf

for STM32CubeF3 (Paragraph: File inclusion model).

-Amel

[Morty Morty]

Posted on July 06, 2018 at 13:45

Ok, I see (although I strongly disagree with the design decision).  Yet in that case stm32f3xx_hal_def.h should not include stm32f3xx.h in line 46.

Also something like

♯ ifndef __STM32F3xx_HAL_H

♯ warning Please do not include this file directly but stm32f3xx.h. See UM 1786.

♯ endif

would be nice.