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.

[TDK]

> 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 ?

You can tell CubeMX which ones you want to use (HAL vs LL) in Project Manager -> Advanced Settings -> Driver Selector.

> why does it still bring the HAL lib 

You can drill down from the top-level "stm32f0xx.h" to see how things get included. You either live with that, or make up your own include scheme that only includes the LL stuff.

[brokenkeyboard]

I'll try to do that. By the way I said the big green play button worked for what I wanted, but I just realized that I still can't upload my code if I don't enable the debug serial wire when creating the project with CubeMX. And when creating a new run configuration I just can't get rid of the debugger (for when the project is over or in case I need the pins used by the serial wire), despite selecting the qualifier armle -/fgh/Release/myproject.elf. What am I doing wrong ?

[KnarfB]

> I still can't upload my code if I don't enable the debug serial wire when creating the project with CubeMX

The MCU will be flashed through that interface, so you should enable it. You would only disable it if you need those pads for other functions or for security reasons. Thats possible, but requires extra effort.

[brokenkeyboard]

Sorry I didn't see your answer, but during the day I noticed that actually in the CubeMX part of the CubeIDE software (where I generate the project, the .ioc file) I can disable the serial wire and free the 2 pins, and upload the code using the 'run' button...

But I need to reset the board (I'm using a 'blue pill' board) with the reset switch (or by unplugging the STLink) before every upload and pull the BOOT0 high with the headers; or else I get a ' No device found on target' error.

However I'm confused because in the console I read this line when uploading: 'SWD Debug  : Enabled', despite using no-debug in the .ioc file for the project and selecting the 'Release' version when creating/selecting the run configuration. Is it something I shouldn't be bothered with or is the 'debug' version of my code sent to the board ? If so, how can I actually send the 'release' version ?

And by the way why when creating a run configuration, 2 files are generated which only differ by 'shared file' (in 'common'), why is that ?

[KnarfB]

The SWD debug pins are "hard" configured in SWD mode during a hardware reset of the MCU regardless of what you are "soft" configuring in Cube. If not configured as SWD in cube, the firmware will override the reset configuration of the chip soon after reset by your "soft" configuration. Therefore, in that case, debugging only works with a hardware reset (NRST pin).

If SWD is "soft" configured, a reset... can be soft triggerd from the debugger without using the NRST signal.

There is a nice app note: AN4989 "STM32 microcontroller debug toolbox"

Unfortunately those app notes are hard to find :persevering_face:

[brokenkeyboard]

Ok I'll read it. But still, am I sending the 'debug' or 'release' version of my code ?, and if it is the 'debug' one how to upload the 'release' one ? Do I have to use hacks like this: https://www.youtube.com/watch?v=R2hfq4S_-B0&feature=youtu.be or use the CubeProg software (both look pretty overkill to me) ?

[KnarfB]

In the video you mentioned, at 2:11 is show how to manage a Debug or Run configuration. In STM32CubeIDE there is a black drop-down triangle next to the icons for that or use the "Configurrion..." menu entries in the Run menu. In that Run/Debug configuration dialog, you can check/enter/change the .elf file to be used.

[brokenkeyboard]

Well I did mention finding this menu, but I'll take this as a confirmation that I'm indeed uploading the 'release' version. But I still don't understand why I see the 'SWD Debug  : Enabled' line in the console when uploading and why in the 'debugger' part of the 'run configuration' menu I still see a bunch of debugger features that can't be disabled.

[KnarfB]

Uploading==Programming==Flashing is done with the same tools and is the first step of debugging. Both can share the same .launch file. A difference is in the Startup tab where in Run most things are grayed out, because Run doesn't halt the core at the main breakpoint.

[brokenkeyboard]

Oh ok I see. This was a bit wicked to understand, I suppose I'll have to dig into Eclipse's and/or TrueStudio's documentation to further my understanding. Thanks for your help.