cancel
Showing results for 
Search instead for 
Did you mean: 

Unknown type name 'HAL_StatusTypeDef' Error

akoluacik
Senior

Hi, I am trying to use the peripherals with their peripherals rather than initializing it with CUBEMX tool. I am only selecting 'Serial Wire' option of Debug mode under System Core -> SYS with CUBEMX. However, when I build my program, it throws the error in the title. I googled it but found nothing helpful. How can I solve this problem?

Thx in advance for your helps.

7 REPLIES 7

Make sure you uncomment/select the modules you want in stm32f7xx_hal_conf.h

Make sure your project has "Include Paths" point to the appropriate CubeF7 directories/folders holding the include files you expect to pull in.

Make sure the command line to the compiler has USE_HAL_DRIVER and the specific IC you're using.

Perhaps review the meta-data in a working/functional project, and use that as a reference/template?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

- I am using RTC, but do I need to enable it because I don't use HAL Library, I am using registers. I am coding in register(low) level?

- I looked at it, and everything is fine I guess, because related locations were added. I didn't mention but when I click CTRL+Left Click, I can see the definition of HAL_StatusTypeDef, but the compiler somehow cannot.

- STM32F746xx and USE_HAL_DRIVER symbols were already added.

I cannot understand the last statement/suggestion, perhaps my English isn't enough to understand. May you please make it clear? And what else do I need to check/add, or what else you can recommend?

Take a project that works, and review and understand the configurations and setting that project is using. Apply those same settings to your own.

It is generally easier to change something that is working than it is to fix something that is broken.

There are lot of pieces of code and include files that get pulled in selectively based on #define in stm32f7xx_hal_conf.h and others.

You have to #include the top level include file, and it needs to fetch the others.

Perhaps generate the preprocessor output, and inspect that to see what is and isn't seen by the compiler.

Show the full error messages in context. Start with the FIRST error as this can compound into other errors.

If you're doing register level work you shouldn't need the HAL, rather just the includes that provide the CMSIS register names, etc.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I think I've solved the problem. As I said, I am implementing the program with HAL Registers, so I wanted to implement my header and source files, in one of the source files, I included "stm32f746xx_hal_def.h" once I commented it, the problem is fixed. This time, however, I cannot use UNUSED macro to prevent the compiler warnings, and I don't wanna include the definition in my header file. Is there any suggestion to handle this issue? I think we can do this by using macro conditions?

> I don't use HAL Library

> USE_HAL_DRIVER symbols were already added

Don't you see anything wrong here?

> I am implementing the program with HAL Registers

First you have to understand what the HAL is and what the registers are.

@Anıl Koluaçık​ What is "HAL registers"? Functions or macros with names __HAL_*** or "low level" (LL) macros?

The library includes are meant to be used in this way:

  • You include only "stm32f7_hal.h" in most of your source files (in main.c it is included via main.h).
  • You define your exact STM32 model in the preprocessor defines, and also define USE_HAL_DRIVERS.
  • The ...hal.h includes ...hal_conf,h located in your project. This file is important, you can edit it and should at least look into it.
  • That also includes ... hal_def.h which you don't modify and usually don't need to include explicitly.
  • You don't need to include ...hal_gpio.h, ...hal_uart.h and so on, because these are already pulled in via the ...hal_conf,h (inlcuded from stm32f7_hal.h).

I was having the same problem and included the exact lib of the driver I needed (so I had #include <stm...i2c.h> instead of the general stm...hal.h)

Thanks Pavel, you saved me.