Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CubeMX and the HAL library

I have used Emblocks in the past multiple times with STmicroelectronics STM32. I was verry happy with it. Then after some time I got license for KEIL for work so used that for some years. Now I'm back with Emblocks (now EMbitz) but the ST has switched in the mean time to the HAL library and has build very nice tool called CubeMX. I think this is a very handy tool for quickly starting a project. Now I have seen multiple threads about this CubeMX but I'm not able to find a clear answer.

- Is there an easy way of importing CubeMX generated files?
- Once imported. If I change some setting in CubeMX, do I need to completely import the files again?
- If CubeMX not supported by EMbitz. Will it be in the future?

Thanks in advance!

Best regards,

Hello LeddeL,
I am actively developing with STM32, using CubeMX and Embitz for writing and debugging my code.

So far I didn't find any quick way to import Cube projects. I have to do so manually.
This is more or less what I do:
1) create a new project with Embitz, selecting the MCU I want to use
2) delete (from disk) the *.c and *.h files that Embitz creates. DO NOT delete *.ld and *.S
3) delete everything from the Embitz project with "Delete files".
4) create the project files with the Cube, by selecting "Other toolchains" in the project settings
5) Now add all the Cube-generated files in Embitz ("add recursively" is a good option), plus the linker script of your choice, for example stm32f207zg_flash.ld
6) The Cube generates files for IAR and other compilers. You should neutralize these files, by right-clicking on them and choosing not to compile/build.
7) Open Embitz build options, go to #define section, remove everything, then add your MCU, for example STM32F207xx

This should be more or less all. Perhaps there are other conflicting files that you have to deactivate. As a general rule, use Embits-generated *.S and *.ld and not those of the Cube.

Should you regenerate the project, just remember to add/remove new files in Embitz.

Ups, emBitz does'nt support the STM32F7 and some new F0+ MPU's directly, so the startupfile (ending .s) and the Linker file (ended .ld) must also be replaced by the generated one of CubeMX. You also need to load the mpu fitted svd file for special function register view in debug mode.

The generated IAR Code is different in some aspects and it's a better choice to generate Code for a GCC Compiler directly. I have good experiences using ST4STM32 Code. You just Need to generate a dummy Project and Import the files generated by CubeMX into the dummy Project.

It's a good idea to replace the jtag Firmware of the nucleo board with the j-link Software released for free by segger. The advantage is the the near doubled Speed at Debugging, upload and the well made fix of the chip bug if the first f7 Chips. In Addition, segger offers a nice source Level Debugger that can be optionaly used and this is very versatile. I have done some experiences with this and this work pretty nice at all.
@ mdctech: Thanks for your reply! The steps you describe is a 1 time job or everytime I change some setting in CubeMX I need to do all the steps you describe? If that is the case it's way to much work for me  Wink

@ DD4DA: I also tried the SW4STM32 toolchain. Everything works out of the box and working with CubeMX is great with that toolchain. But I have one really big problem with SW4STM32, and that is the lack of live variable viewing. I find it really a shame they did not implemented this. I use this so much in debugging projects! Or do you know of a way to have live variable viewing in this toolchain that I'm not aware of?

I believe there will be a Keil Uvision importer in Embitz in version 1.2? But does anyone know when version 1.2 will arrive?

Best regards,
It's a 1-time job!
The only case when you need to perform manual actions is when you add or remove a peripheral. Then you will have to add the new HAL files in the Embitz project, and remove those no longer on the disk.

I like your method to solve this problem. At the same time, I am still eagerly waiting a native support from EmBitz to supoort
1) Importing CubeMX projects into EmBitz
2) Using STM32Cube_FW_Fx (such as STM32Cube_FW_F4) libraries instead of SPL

Your answer covered the instructions for the first use case. For the second use case, I have been using the following steps
1) Download the STM32CubeF4 library, such as from
2) Expand the ZIP file into a fixed location
3) Create a new project for the target processors, such as F407VE
4) Move the startup file (startup_stm32f4xx.S) and linker file (stm32f407ve_flash.ld) into a fixed location
5) Delete everything from the project library - except the main.c and the project file (*.ebp)
6) Remove all files (right click) from the project tree, except the main.c
7) Add the startup file from the fixed location
8) In Project Build Options, select Device, change the linker script location to the fixed location
9) In Project Build Options, select Compiler settings, add the following directories
- fixed location of your own files
- HAL Driver inc file, such as S:\STM32Cube_FW_F4\Drivers\STM32F4xx_HAL_Driver\Inc
- CMIS include file, such as S:\STM32Cube_FW_F4\Drivers\CMSIS\Device\ST\STM32F4xx\Include
10) Add the CubeFx library files to project tree, such as
- Drivers\CMSIS\Device\ST\STM32F4xx\Source\Templates\system_stm32f4xx.c
- Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_gpio.c
- Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_rcc.c
11) In Project Build Options, select Compiler settings, select #deifnes (for project level)
and add the processor type, such as
- STM32F407xx
12) Create a simple blink LED program to verify your steps
13) Debug your program
14) Save project as a user template
Cheers, Ollie
I have a small problem using the HAL libraries.
Right click "Find implementation" is not working, cannot find the HAL library functions: "Not found: <function name>" .
The "Find declaration" is working, picks the declarations in the HAL headers. (compiling and debugging is working well)
My interpretation is that this is not a specific problem for HAL library. The "Find declaration" works properly based on the defined search libraries. My guess is that EmBitz has been heavily tested for the model where all source files are stored in the project directory.

My practice has been to store all library type of source files outside of the project folders. I have kept all external libraries without any modifications in separate subdirectories and my own libraries in different subdirectories.

I have not checked, if there is already a ticket for this - there should be.
Cheers, Ollie

Forum Jump:

Users browsing this thread: 1 Guest(s)