0
\$\begingroup\$

So i'm trying to figure out the cause of a bunch of errors that i'm getting that are related to file paths mainly complaining about HAL_StatusTypeDef which is defined in stm32f4xx_hal_def.h even though I see it's included. Any help is appreciated.

EDIT:

  • I verified and it has to do with ifndef/define macros. Not quite sure what...

Following is a snippet of the hierarchy:

I'll go from bottom to up:

//--------------- main.h ---------------
#ifndef __MAIN_H
#define __MAIN_H

#ifdef __cplusplus
extern "C" {
#endif

#include "app.h"
#include "stm32f4xx_dma.h"
#include <string.h>
#include <stdlib.h>
#include <stdio.h>

#ifdef __cplusplus
}
#endif

#endif /* __MAIN_H */

// --------------- app.h ---------------
#ifndef __USART_APP_H
#define __USART_APP_H

#include "stm32f4xx_hal_usart.h"
#include "mcp9808.h"
#include <stdarg.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>

// --------------- mcp9808.h ---------------
#ifndef __MCP9808_H
#define __MCP9808_H

#include "stm32f4xx_hal_i2c.h"

#define MCP9808_ADDR                    0x18
#define MCP9808_REG_AMBIENT_TEMP_REG    0x5

#endif

// --------------- stm32f4xx_hal_usart.h ---------------
#ifndef USART__INC_STM32F4XX_HAL_USART_H_
#define USART__INC_STM32F4XX_HAL_USART_H_

#include <stdint.h>
#include <string.h>
#include "stdbool.h"
#include "../Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_rcc.h"
#include "stm32f4xx_dma.h"


// --------------- stm32f4xx_hal_i2c.h ---------------
#ifndef __STM32F4xx_HAL_I2C
#define __STM32F4xx_HAL_I2C

#ifdef __cplusplus
 extern "C" {
#endif

#include "stm32f401xe.h"
#include "stm32f4xx_hal.h"
#ifdef __cplusplus
}
#endif

https://www.openstm32.org/forumthread1225#threadId5098

That's it on my end - I didn't modify any of the other HAL files including the following:

// stm32f4xx_hal.h
#ifndef __STM32F4xx_HAL_H
#define __STM32F4xx_HAL_H

#ifdef __cplusplus
 extern "C" {
#endif

/* Includes ------------------------------------------------------------------*/
#include "stm32f4xx_hal_conf.h"

// stm32f4xx_hal_conf.h

Here's a snapshot of the config file. A couple of questions:

  • I recently downloaded the eclipse dark mode but I suspect the olive-coloured highlight indicates the files don't exist? Cause clearly the files that are highlighted don't exist, but I also see the following part highlighted in all of the files.

    ifdef __cplusplus

    extern "C" {

    endif

  • Should I be touching this file considering how it's got all the includes of the file paths?

Snapshot of the config file

The errors that I see are from majority of the header files that are under HAL driver directory, as shown below:

files are the affected

A few out of 130 errors:

STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_exti.h:329:1: error: unknown type name 'HAL_StatusTypeDef'; did you mean 'FLASH_TypeDef'?
 HAL_StatusTypeDef HAL_EXTI_SetConfigLine(EXTI_HandleTypeDef *hexti, EXTI_ConfigTypeDef *pExtiConfig);

STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_exti.h:329:1: error: unknown type name 'HAL_StatusTypeDef'; did you mean 'FLASH_TypeDef'?
 HAL_StatusTypeDef HAL_EXTI_SetConfigLine(EXTI_HandleTypeDef *hexti, EXTI_ConfigTypeDef *pExtiConfig);

Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_gpio.h:238:1: error: unknown type name 'HAL_StatusTypeDef'; did you mean 'FLASH_TypeDef'?
 HAL_StatusTypeDef HAL_GPIO_LockPin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin);

Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_dma.h:145:3: error: unknown type name 'HAL_LockTypeDef'
   HAL_LockTypeDef            Lock;                                                             /*!< DMA locking object 

Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_dma_ex.h:70:1: error: unknown type name 'HAL_StatusTypeDef'; did you mean 'HAL_DMA_StateTypeDef'?
 HAL_StatusTypeDef HAL_DMAEx_MultiBufferStart(DMA_HandleTypeDef *hdma, uint32_t SrcAddress, uint32_t DstAddress, uint32_t SecondMemAddress, uint32_t DataLength);

Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_flash.h:72:3: error: unknown type name 'HAL_LockTypeDef'
   HAL_LockTypeDef             Lock;               /* FLASH locking object                */

Edit:

A somewhat relatable problem discussed here and the solution apparently was to declare the #include “stm32f7xx_hal.h” which I already am doing. Maybe I'm not doing at the right location?

\$\endgroup\$
10
  • \$\begingroup\$ I believe the olive highlights mark a preprocessor define that isn't defined, so anything between them will not be compiled. \$\endgroup\$
    – Ron Beyer
    May 21, 2020 at 18:06
  • \$\begingroup\$ right, but do you see why am I seeing for this preprocessor? imgur.com/a/B8bAeqs \$\endgroup\$
    – MKD
    May 21, 2020 at 18:16
  • \$\begingroup\$ Because you aren't compiling it with C++, so the __cplusplus isn't defined. You are compiling it in "C". \$\endgroup\$
    – Ron Beyer
    May 21, 2020 at 18:19
  • \$\begingroup\$ Understood. Also, you mentioned anything in between won't compile; did you mean from the point of definition till its endif or only the highlighted part (which makes sense)? \$\endgroup\$
    – MKD
    May 21, 2020 at 18:23
  • \$\begingroup\$ Everything between the #ifdef and the #endif will not be compiled (and it also shouldn't throw errors during compilation if there is something wrong inside). \$\endgroup\$
    – Ron Beyer
    May 21, 2020 at 18:26

2 Answers 2

1
\$\begingroup\$
  1. Scroll to the top of the build console output and find the first occurrence of the error.
  2. Identify the last file at the bottom of the "In file included" list. enter image description here
  3. Open that file and add the line #include "stm32wbxx_hal.h" at the top of it. In the example above, this would be the Source/tsc.c file.

More specifically, this issue was caused by tsc.c including stm32wbxx_hal_tsc.h directly instead of going through STM's un-intuitive include convention. Replacing this include with stm32wbxx_hal.h also works.

\$\endgroup\$
0
\$\begingroup\$

I had this problem, too and discovered it was caused by accidentally adding #include <stm32g0xx_hal_i2c.h> to one of my source files. The stm32xxxx_hal_yyyy.h files most likely shouldn't be referenced directly from your source, but rather through the STM32Cube peripheral source files such as 'rtc.c', 'i2c.c', etc.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.