cancel
Showing results for 
Search instead for 
Did you mean: 

How to change the STM32 family in a project using HAL?

DocAlex
Associate II

Hello,

I am currently using a F4 processor in HAL together with the Stm32cubeIDE.

Thus the IDE generates F4 hal files which later are included in the main program. 

 

To access the specific functions I need to #include "stm32f4xx_hal.h" in my own programs and libraries to make the HAL available in my programs. 

 

When I later want to change the platform to an F7 processor I would need to change all the code to #include "stm32f7xx_hal.h". This is very inconvenient. 

How can I avoid this problem?

 

Thanks in advance

 

Alexander

 

1 ACCEPTED SOLUTION

Accepted Solutions
Andrew Neil
Super User

@DocAlex wrote:

To access the specific functions I need to #include "stm32f4xx_hal.h" in my own programs and libraries to make the HAL available in my programs. 


No, you don't need to do that.

CubeMX (whether standalone or as part of CubeIDE) places the  #include "stm32f4xx_hal.h" within  the auto-generated main.h.

So you just need to #include "main.h" and that will automatically give you the correct version of the HAL header

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

View solution in original post

5 REPLIES 5
Imen.D
ST Employee

Hello @DocAlex ,

To update the application code from STM32F4 to STM32F7 Library, you need to :

  • Replace the stm32f4x_conf.h file with stm32F7xx_conf.h
  • Replace the existing stm32f4x_it.c/stm32f4x_it.h files with stm32F7xx_it.c/Stm32F7xx_it.h
  • Check and update the toolchain startup files (Project files, Linker configuration and vector table location files)

Please refer to this application note, which can help you on your project as it provides a guidance on hardware and peripheral migration : AN4660 Application note Migration of microcontroller applications from STM32F42xxx/F43xxx devices to STM32F7 Series devices.

 

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

Hello @Imen.D,

thank you for the migration guide. 

 

It is quite clear to replace the stm32f4x_conf.h file with stm32F7xx_conf.h files.

In reality I would set up a new F7 project where the necessary files would be generated anyway. 

My question was pointing in a different direction:

 

In my files e.g. Mylibrary.c and Mylibrary.h I need to  #include "stm32f4xx_hal.h". When I now change to project to a F7 family I need to change Mylibrary.c and Mylibrary.h and replace in these files  #include "stm32f4xx_hal.h" with  #include "stm32f7xx_hal.h".

 

Is there any way to include the HAL more general so that it includes automatically F4 or F7 HAL in Mylibrary.c and Mylibrary.h?

 

regards

 

Alexander

 

Andrew Neil
Super User

@DocAlex wrote:

To access the specific functions I need to #include "stm32f4xx_hal.h" in my own programs and libraries to make the HAL available in my programs. 


No, you don't need to do that.

CubeMX (whether standalone or as part of CubeIDE) places the  #include "stm32f4xx_hal.h" within  the auto-generated main.h.

So you just need to #include "main.h" and that will automatically give you the correct version of the HAL header

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

You could define the target plaform (e.g. F4 and F7) on make file level, and thus pass it to each built call.
And of course make those specific includes conditional.
This way you can manage software base for multiple platforms and toolchains, although effort increases.

On a related note, you might need to compare some sections of the reference manuals carefully.
Trying to port code between F1, F3 and F4 devices, I found some subtle (and not so subtle) differences between peripherals that required substantial changes.


@Ozone wrote:

You could define the target plaform (e.g. F4 and F7) on make file level


Indeed.

@DocAlex Or you could do it in the CubeIDE Project - here's how I do that:

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/same-touchgfx-project-for-multiple-cubemx-files-in-the-same/m-p/672534/highlight/true#M37503

Thus You have one Project for F4 and one for the F7.

CubeMX generates a separate main.h for each Project - which has the appropriate HAL include.

CubeMX also generates a separate main.c for each Project - You call your common code from there; eg,

  /* USER CODE BEGIN 2 */
  my_common_setup();
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
	  my_common_loop();
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

 


@Ozone wrote:

you might need to compare some sections of the reference manuals carefully.
Trying to port code between F1, F3 and F4 devices, I found some subtle (and not so subtle) differences between peripherals that required substantial changes.


Indeed.

@DocAlex the AN4660 linked earlier by @Imen.D will help ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.