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.

[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 September 12, 2017 at 08:53

Yea! Including stm32f3xx_hal.h before any of the other headers will also solve the problem. And thinking about it, that makes things even worse because your code depends on the order the header files are included. I wonder whether the guys at ST have  ever heard of PC-Lint, which is able to check against such issues? Oh wait, uVision has builtin support for PC-Lint! But probably they are not willing to eat their own dog food.

[Tesla DeLorean]

Posted on September 12, 2017 at 11:41

While I'm not a huge fan of stm32f3xx_hal_conf.h, and HAL in general, &sharpincluding a single file is hardly onerous, or difficult to apply consistently.

If you just &sharpinclude 'stm32f3xx_hal_rcc.h' outside of the hierarchy, or pull in an inconsistent set of includes in random orders, I'd imagine that could cause a lot of head-aches.

[Morty Morty]

Posted on September 12, 2017 at 11:57

Fixing the header files isn't too much magic either. It's not like this is a new and unsolved problem. Any 'Best practices in C'-book should have a chapter on how to solve circular dependencies correctly.

[joseph23]

Posted on September 13, 2017 at 18:24

As someone who is fairly new to C and firmware development these circular dependencies are extremely frustrating. Maybe I was reading the wrong books on C, but I had no idea that defining header files in a certain order was necessary. It seems very counter-intuitive from my point of view.

Is this tidbit contained in the ST documentation that the stm32f3xx_hal.h header has to be defined prior to defining the headers that actually contain the functions that I’m trying to use? Maybe I completely missed it or this is just such common knowledge to more seasoned coders that it wasn’t deemed necessary to point it out? If there are ways to structure the header files that eliminates this problem, I for one would very much appreciate it.

Thanks Morty Morty for pointing this out!

If there are specific tutorials or references pointing out good practices for dealing with circular dependencies I’d appreciate a link or two.

[Tesla DeLorean]

Posted on September 13, 2017 at 18:57

Like executing code, order is important, you're inserting file data into a linear stream the compiler is processing. So the same reason you don't list the #includes at the end of the file applies here.

The way C compilers and code works #include files can be pulled in by each other, and visited multiple times. The C++ compilers are intolerant of these kinds of redefinitions, and thus why you see '#ifdef INCLUDE_FOO \ #define INCLUDE_FOO \ #endif' constructs.

Bringing in stm32f3xx.h or stm32f3xx_hal.h achieves the desired effect, whereas slapping in random #include 'stm32f3xx_hal_rcc.h', etc has undesirable effects.

ST provides project templates, the construction of these should be reviewed.

[Morty Morty]

Posted on September 14, 2017 at 08:50

MohawkSpock: Well written C-headers can be included in any order. That's why beginners C-Books often neglect that issue. Thy should however at least have a section on the topic and explain that they do exist. All in all they are a little more complex to solve. That's why I wrote 'Best practices in C' and not 'C for beginners'. In general I do however have the impression that the developers who wrote the ST-Library were no C-gurus.

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

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