2017-08-11 08:36 AM
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.2017-09-11 10:51 AM
st.mcu
: This is not related to CubeMx, but a bug in the HAL-Library: Create any project with STM32CubeMx that will include thestm32f3xx_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.
2017-09-11 02:22 PM
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'
2017-09-12 01:53 AM
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.
2017-09-12 04:41 AM
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.
2017-09-12 04:57 AM
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.
2017-09-13 11:24 AM
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.
2017-09-13 11:57 AM
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.
2017-09-14 01:50 AM
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.
2017-09-27 09:56 AM
Morty,
I have confirmed the same issue. And I have confirmed that your suggested fix does indeed work.
Thanks!
2018-07-06 03:37 AM
Why is this marked as resolved? As far as I can see this is still an issue with STM32Cube FW_F3 V1.9.1!