how to handle cube mx overwriting the hal_conf that has to be modified by devs. this looks like a long standing problem (half a decade) an i see no stable solution

[_richard]

See https://community.st.com/s/question/0D50X0000ArRvt6SQC/stmcubeide-usehalregistercallbacks-definition?t=1681544999233

• the stm32lyxxxhal.h includes stm32yxxx_hal_conf.h.
• stm32yxxx_hal_conf.h contains always regenerated code as follows

/* ################## Register callback feature configuration ############### */
/**
 * @brief Set below the peripheral configuration to "1U" to add the support
 * of HAL callback registration/deregistration feature for the HAL
 * driver(s). This allows user application to provide specific callback
 * functions thanks to HAL_PPP_RegisterCallback() rather than overwriting
 * the default weak callback functions (see each stm32l0xx_hal_ppp.h file
 * for possible callback identifiers defined in HAL_PPP_CallbackIDTypeDef
 * for each PPP peripheral).
 */
#define USE_HAL_ADC_REGISTER_CALLBACKS 0U
#define USE_HAL_COMP_REGISTER_CALLBACKS 0U
#define USE_HAL_DAC_REGISTER_CALLBACKS 0U
#define USE_HAL_I2C_REGISTER_CALLBACKS 0U
#define USE_HAL_I2S_REGISTER_CALLBACKS 0U
#define USE_HAL_IRDA_REGISTER_CALLBACKS 0U
#define USE_HAL_LPTIM_REGISTER_CALLBACKS 0U
#define USE_HAL_PCD_REGISTER_CALLBACKS 0U
#define USE_HAL_RNG_REGISTER_CALLBACKS 0U
#define USE_HAL_RTC_REGISTER_CALLBACKS 0U
#define USE_HAL_SMARTCARD_REGISTER_CALLBACKS 0U
#define USE_HAL_SMBUS_REGISTER_CALLBACKS 0U
#define USE_HAL_SPI_REGISTER_CALLBACKS 0U
#define USE_HAL_TIM_REGISTER_CALLBACKS 0U
#define USE_HAL_TSC_REGISTER_CALLBACKS 0U
#define USE_HAL_UART_REGISTER_CALLBACKS 0U
#define USE_HAL_USART_REGISTER_CALLBACKS 0U
#define USE_HAL_WWDG_REGISTER_CALLBACKS 0U

As I see it there is a conflict in the instruction "Set below the peripheral configuration to "1U" to add the support of HAL callback registration/deregistration feature for the HAL" and silently overwriting the changes.

As I see it the mentioned workaround of adjusting templates is tedious, complex, error prone.

As I see it the hint to define USE_HAL_xyz_REGISTER_CALLBACKS in Project->Properties dialog is not helping as the problem isn't, that it isn't defined, but it is defined with the wrong value.

My recommendation would be to (as in main.c) introduce

/* Private includes ----------------------------------------------------------*/
 
/* USER CODE BEGIN Includes */
 
/* USER CODE END Includes */
 

before

/* Includes ------------------------------------------------------------------*/
 
#include "stm32l0xx_hal_conf.h"
 

in stm32yxxx_hal.h.

That way developers could add an include of their stm32yxxx_hal_conf-customization.h easily.

To prevent redefines in stm32yxxx_hal_conf.h each define should have a #ifndef

Are there better ways then / reasons against this approach?

[AVasi.11]

Writing software on the STM is like solving quests all the time. Unfortunately, in my experience there are more than TI or Microchip, for example. Lots of bugs even in rm that haven't been fixed for years

I managed to solve this quest in 3 minutes, I guessed that there should be settings in the cube

[AVasi.11]

[AScha.3]

as shown by AVasi , you can set REGISTER_CALLBACKS in Cube ;

you have to update Cube/IDE to newer version (IDE 1.10 or newer), to get this callback settings.

look, maybe you have it and just didnt know... or update.

[_richard]

yes, you are right, the cubmx configuration is now possible, even as it is not obvious where to find it.

the suggested #ifndef approach would allow switching configuration easily in code / during build -> cubemx as basline, further configuration e.g. by build profile (defines).

[aseo.1]

CubeMX is a software tool used for configuring and generating initialization code for microcontroller peripherals. It is common for developers to modify the generated HAL configuration files to suit their needs. However, if the HAL configuration files are modified using CubeMX again, the changes made by the developers can be overwritten.

One way to avoid this problem is to keep a backup copy of the modified files and manually merge the changes after CubeMX generates new code. Another approach is to avoid using CubeMX to modify the HAL configuration files once they have been modified by the developer. This can be achieved by disabling the "Generate peripheral initialization as a pair of '.c/.h' files per peripheral" option in CubeMX.

Another possible solution is to use a version control system such as Git to manage changes to the code. By committing changes to the repository and using merge and rebase techniques, it is possible to preserve the changes made by developers while still allowing CubeMX to generate new code.

Finally, some developers prefer to avoid using CubeMX altogether and write their own initialization code. While this approach requires more manual effort, it can provide greater control and flexibility over the generated code.

In summary, there are several ways to handle the problem of CubeMX overwriting HAL configuration files modified by developers. The best approach will depend on the specific needs and preferences of the development team.

[_richard]

yes, there are many ways. some more manual, some more flexible, some more obvious, ... .

the cubemx ui tool is nice to get a easy start to setup a project, especially when using the eclipse (cube) ide.

some developers never leave the ide, never use cmake, never have parameterized builds. never use ci/cd, ... .

the file copy workflow can be done but becomes error prone fast when working in a team and committing in a common repo for the build.

different branches works -> may lead to a lot of merging for two or more branches that just differ in one or more defined values.

if cubemx would define ifdefs both approaches would still work and other (less manual /ui focussed) options would become available. the ifdef approach is not uncommon.