STM32F4 HAL library build errors.

[NKunwar]

I am getting compile error in a lot of HAL files (gpio, rcc , spi). The error is for registers and peripherals which are not present in F407 but are present in F42/43 like. Since the HAL files are common for whole F4 series, these regs and functions are defined in HAL files.

>> GPIOJ and GPIOK check done in "IS_GPIO_ALL_PERIPH".

>> SPI peripherals which are not present in F407 like SPI4 and forwards.

>> RCC_SAIPLLSAIClkDivConfig and other PLLSAI related functions and definitions in rcc.h

Some of the functions have "#if defined (STM32F427_437xx)" but a lot others do not. Also some function are used in for all controllers within the series and hence have registers used for higher controllers too like the "GPIO_DeInit" function in hal_gpio.c.  

I have stm32f4xx.h included in my project which has definitions for registers of F407 and hence registers like GPIOJ/GPIOk; SPI4 and onwards are not defined in this .h file.

I wanted to know how can I use the HAL library for F407 without modifying anything in it. I downloaded the zipped library from github page of ST.

[Tesla DeLorean]

The model is passed as a command line to the compiler.

Perhaps try looking at the templates/examples for the STM32F407G-DISCO board

STM32Cube_FW_F4_V1.24.0\Projects\STM32F4-Discovery\Templates\SW4STM32\STM32F4-Discovery\.cproject

...
								<option id="gnu.c.compiler.option.include.paths.282795374" name="Include paths (-I)" superClass="gnu.c.compiler.option.include.paths" useByScannerDiscovery="false" valueType="includePath">
									<listOptionValue builtIn="false" value="../../../Inc"/>
									<listOptionValue builtIn="false" value="../../../../../../Drivers/CMSIS/Device/ST/STM32F4xx/Include"/>
									<listOptionValue builtIn="false" value="../../../../../../Drivers/STM32F4xx_HAL_Driver/Inc"/>
									<listOptionValue builtIn="false" value="../../../../../../Drivers/BSP/STM32F4-Discovery"/>
									<listOptionValue builtIn="false" value="../../../../../../Utilities/Log"/>
									<listOptionValue builtIn="false" value="../../../../../../Utilities/CPU"/>
									<listOptionValue builtIn="false" value=""/>
									<listOptionValue builtIn="false" value="../../../../../../Drivers/CMSIS/Include"/>
								</option>
 
								<option id="gnu.c.compiler.option.preprocessor.def.symbols.90444414" name="Defined symbols (-D)" superClass="gnu.c.compiler.option.preprocessor.def.symbols" useByScannerDiscovery="false" valueType="definedSymbols">
									<listOptionValue builtIn="false" value="USE_HAL_DRIVER"/>
									<listOptionValue builtIn="false" value="STM32F407xx"/>
									<listOptionValue builtIn="false" value="USE_STM32F4_DISCO"/>
								</option>
...

[NKunwar]

I have the macro defined in my compiler options as "STM32F40_41xxx ". So for functions where the #STM32F427_437xx is added before the definition, compiler does not raise a warning for but it does for the ones where this #def is not done. I do not understand why the #def was not added even though the comment before functions mentions that this can be used for only for STM32F427_437xx controllers.

This issue is on a old code where the HAL release version used is from 2013. I can not update the HAL library as it will break lot of things at application level.

[Tesla DeLorean]

Which version, they are all numbered?

Can't you just download, or use, the version that worked previously?

Doesn't the old/original build environment work?

Got a project or build instructions for that?

What tools? Keil, IAR, GNU?

Can you use a makefile ?

[TDK]

In HAL, there are defines set up to define peripherals like SPI4 or not based on the chip.

For example, the correct #define for the STM32F407 is:

#define STM32F407xx

If this is defined, the HAL files will try to include "stm32f407xx.h" which does not have a definition for SPI4.

https://raw.githubusercontent.com/STMicroelectronics/STM32CubeF4/master/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f407xx.h

Generating a new project in STM32CubeMX should set up the defines for you.

The defines have evolved over the years, so if you project was set up using a much older version, it may not have the correct definitions.

I don't recall any HAL version which hasn't worked with STM32F40x with the correct define, and I have used probably every version. Obviously if it worked at one time, there is no reason it shouldn't still work with the same tools. Something changed.

[NKunwar]

HAL version is V1.3.0 ( 08-November-2013)

The tool chain I am working with is CrossStudio by Rowley Associates.

To give complete context of the situation : The code was written and pushed in a repo from a different machine and I do not have access to the files in that machine.

When the code was pushed in repo; the HAL libraries used were pushed along with the application code but the header files used for controllers (stm32f4xx.h) wasn't. The controller header file is from the tool chain's (CrossWorks) support package on STM32.

I think is the issue is due to change in this stm32f4xx.h. The older file was one common file for all controllers in F4 series, while the newer file calls a .h specific to controller being used. Since the older file was common to all, the the defs for whole series were there.

[TDK]

> HAL version is V1.3.0 ( 08-November-2013)

Sure that's HAL and not SPL?

If the file exists, it's probably on GitHub, in which case you can do an advanced search for the filename along with some unique keywords.

[TDK]

Seems like this is the missing SPL file:

https://github.com/ZongqingHou/CS.Assignments/blob/28f3d7f08b3ac5d27b4188cf4b60527dbe754cf6/RealtimeSystem/CoffeeMechine/Libraries/CMSIS/Device/ST/STM32F4xx/Include/stm32f4xx.h