General questions on STM32CubeIDE

[brokenkeyboard]

Hello,

(Hobbyist there) A few years ago I tried to develop on STM32 microcontrollers (the so called 'blue pill' to be exact) but the toolchain installation and the whole code generating process made me give up (also there wasn't full linux support if I'm not wrong, up to this day I still can't find official linux drivers for the ST-link). Fortunaly ST released the STM32CubeIDE which encompasses everything, making things a lot more easier for beginners.

But after a few days of testing with the software and consulting documentations, I have a few questions and things I fail to achieve:

1) When creating an STM32Project, I can choose between C and C++, but I don't see the difference between the two. At the end I just have a bunch of .h/c files and no .cpp files whatsoever (and especially no main.cpp). What does this mean ? Do I have to manually create .cpp and .h files in the Src and Inc folders, and must I copy the content of main.c in my own main.cpp ? How to tell the software to compile using these files ? And by the way where should I put C/C++ libraries and how to tell the compiler to use them ?

2) I don't quite understand the CMSIS libraries. From what I understood they mainly contain registers define and very little functions, and must be used with the documentation of the ARM processor in hand. But I didn't understand if it was truly ARM or ST who published those libraries for ST MCUs (for example I read that it was indeed released by ARM but also read things like 'STM32 CMSIS-compliant libraries'). Also do the HAL and/or LL libraries rely on the CMSIS to work ? If not what are the differences of LL libraries and CMSIS libraries ? And do the HAL libraries rely on the LL libraries to work ?

3) And I understood that HAL libraries/drivers provide an abstraction layer and are more or less microncontroller-independant, unlike the LL libraires who provides a sometimes crucial hands-on control (controlling registers bits, etc.). But I'm confused on how to use them. I found the advanced settings option to switch between HAL and LL drivers for each peripheral, but I don't understand exactly what the 'Generated Function calls' option do. When all drivers are HAL selected, none of the .._ll_...c/h files are present in the project directory tree and the _hal_..c/h files corresponding to the peripherals selected are here, but also some that I didn't select when generating the project (like i2c) while others (that I also didn't select) are not there (like _hal_adc); and when selecting one driver as LL, GPIO for instance, the ..._ll_gpio.h/c appears, but also a bunch of others LL .c/h files, and others stay hidden. Why is that ? And does this mean that selecting the LL driver means using the LL driver and/or the HAL driver while selecting the HAL driver means using only the HAL driver ? Can I initialize the peripherals using the HAL driver and then use the LL driver as long as I know what I'm doing ? Can I only call files that are visually present in the project directory tree ?

4) And finally, when building the project (using the 'hammer' icon), I can choose between building for the release or for debug (btw I know I can (un)comment the #define USE_FULL_ASSERT for debugging the functions parameters ) but for uploading the code I only found the debug option. How can I just build in release mode (once the project is completed) and upload it ? Online I found people advising to use a special configuration for debug, but I thought it to be absurd and there had to be an option to just upload the compiled code.

Thanks in advance for your replies.

[KnarfB · Accepted solution]

Hi,

> 1) When creating an STM32Project, I can choose between C and C++ ...

> Do I have to manually create .cpp and .h files in the Src and Inc folders

Yes. I would not copy the stuff because C code will be re-generated when you are changing the device configuration. If you really want C++, write your own code in separate files and call your C++ entry point from the generated main().

> 2) I don't quite understand the CMSIS libraries.

Look at the licensing terms in each file. There are files from ARM for the cores and files from ST under Device. I bet (better: hope) these files were generated from some internal hardware description. They are the lowest level and correspond (somehow) to the .svd files used by the debugger for showing peripheral register values.

> Also do the HAL and/or LL libraries rely on the CMSIS to work ?

Yes. A typical HAL struct is UART_HandleTypeDef defined in stm32f0xx_hal_uart.h (for STM32F0). Its first member "Instance" is a CMSIS struct USART_TypeDef.

> And do the HAL libraries rely on the LL libraries to work ?

No, they are independent of each other.

> 3.

For all types of peripherals that you activate in the device configuration there should be a pair of hal .[ch] files generated. sometimes there are extra ex files and some files may be generated as dependencies of others. Only all those can be used.

4) And finally, when building the project

In the latest STM32CubeIDE (Version: 1.3.0) the green play button icon (menu: run) should do what you want.

[brokenkeyboard]

Hello,

Thanks for your answer, it is greatly appreciated. Things are a bit clearer now. I checked my software version and it happened to be the 1.12 (this is where having repositories for the software would have come handy, moreover there isn't even some automated update availability check), so I manually downloaded the newest version from ST's website (but instead of upgrading the old one I now have two versions of the software...) and reopened my project, the button is now there and I can happily use it. Just to be curious was there an option to show/hide it in 1.12 or was it just missing ?

And just to be sure, when creating my .cpp/h files and/or including C/C++ libraries I do not need to instruct the compiler anything as long as I put them in the Src and Inc folders (but is it advised to put the libraries here ?)

I'm still puzzled as to why the i2c lib (for example) is required when not using any communication protocol but I guess I won't push the investigation any further for the moment. And if the LL and HAL libraries aren't interconnected why do I still see the _hal_gpio.c/h files when using LL for the GPIO drivers ? Is it because ST expects people who want a hands-on to still require some HAL functions (like initialization) ?

And finally do you know where I can find documention on CMSIS libraries and .svd files ? I already found the relatively well hidden ..._User_Manual.chm (by the way if there are people working on ST who pass by there I'd like to point out that when opening those files they pretend to only document HAL drivers while describing HAL and LL drivers in reality, and the .chm format is kind of out-dated an is not exactly natively supported under Linux) and I suppose I must refer to the complete datasheet of the STM32 MCU I'm using to check the registers functionning, but is there some kind of general documentation as to how it works (globally) ?

Thanks for your patience.

[TDK]

> And just to be sure, when creating my .cpp/h files and/or including C/C++ libraries I do not need to instruct the compiler anything as long as I put them in the Src and Inc folders (but is it advised to put the libraries here ?)

You're free to create whatever project structure you want, but including your own files in the Src/Inc is an acceptable and common approach.

> I'm still puzzled as to why the i2c lib (for example) is required when not using any communication protocol but I guess I won't push the investigation any further for the moment.

I2C files are only needed if you're calling them or trying to compile them. Not sure what you're seeing.

> And if the LL and HAL libraries aren't interconnected why do I still see the _hal_gpio.c/h files when using LL for the GPIO drivers ? Is it because ST expects people who want a hands-on to still require some HAL functions (like initialization) ?

Some HAL functions need the LL library, while others do not. Regardless, if you're using CubeMX, the necessary HAL/LL files will be copied to the directory when you generate code.

The best reference for the HAL functions is within the source file themselves. Some things change over time. For example, at the top of "stm32h7xx_hal_adc.c" it tells you everything you need to call in order to use the ADC.

[Piranha]

> And finally do you know where I can find documention on CMSIS libraries and .svd files ?

What documentation do you need for them? They just define registers and bits, which are documented in reference manual. If you mean CPU core register documentation, then those are defined in a programming manual. And for some not so often required things you have to search for ARM's Technical Reference Manual.

> is there some kind of general documentation as to how it works (globally) ?

Application notes. For example AN4013 and AN4776 for timers.

[brokenkeyboard]

Hello and thanks for your answer,

About the i2c library, In the project generation with CubeMX (which is included in CubeIDE) I only activated the GPIO (with LL), NVIC and SYS (default) peripherals (see attachment). So according to KnarfB's answer I should only have the .c/h files drivers corresponding to those three peripherals (+ dependencies), but I have some drivers in the directory tree which I find hard to believe are required like I2c lib, see attachment (but maybe they are actually required for non-obvious reasons so I should do a deep check of the libraries).

When you said regardless you mean that wether or not the HAL GPIO library (for instance) needs the LL GPIO library CubeMX will copy both of them anyway ?

[brokenkeyboard]

Thanks for your answer,

I'll try to find those.

[TDK]

Interesting. I don't have an explanation for why I2C is being brought in. Is HAL_I2C_MODULE_ENABLED defined in stm32f0xx_hal_conf.h? Just curious. There are bugs in CubeMX so I wouldn't spend a lot of time on it. Or, as you said, maybe there are non-obvious reasons for why they're included. You could delete the file and see if you get compiler/linker errors.

> When you said regardless you mean that wether or not the HAL GPIO library (for instance) needs the LL GPIO library CubeMX will copy both of them anyway ?

What I meant was that CubeMX will only bring in what's necessary. For example in your code, it doesn't bring in the LL TIM library because the HAL TIM library doesn't need it.

[brokenkeyboard]

I just checked and yes, the HAL_I2C_MODULE_ENABLED is defined in stm32f0xx_hal_conf.h. What if I want to use the LL and HAL libraries but the CubeMX doesn't bring the LL lib because the HAL lib doesn't need it ? I just can't or should I manually bring the HAL lib myself ?

And I just thought for a bit, but if CubeMX bring everything that's necessary, and that some HAL lib need LL lib (but not the opposite), why does it still bring the HAL lib when selecting LL (even if HAL needs LL for this peripheral, HAL isn't necessary in the first place since I asked for LL) ?

Oh and I just tried to comment the #define HAL_I2C_MODULE_ENABLED and deleted all i2c files, and everything compiles fine. Quite strange.

[KnarfB]

I would not recommend spending time to figure out why. It may change anyway with the next update.

RCC = root core complex which is used for setting up the on-chip clocks PWR = power management etc..

The linker will remove all unused stuff.

You can debug step through the code to find out which components are used.

Or, check the .map file whats really in your executable. STM32CubeIDE Build Analyzer View is a GUI frontend for that.