Mixed use of HAL and LL driver functions

[CTabo.1]

Hello,
I have a project where I use both HAL and LL functions, on different files, for different funcitions.

As described in UM2319, I defined both USE_HAL_DRIVER and USE_FULL_LL_DRIVER as compiler preprocessor symbols.

In this case I have an error indicating that the stm32_assert.c file is absent.
UM2319 says the stm32_assert.c file must be added only if I use LL drivers in stand-alone mode, but in my case I use both HAL and LL functions.

I see that stm32_assert.c defines the assert_param() function, that is also defined in the stm32g0xx_hal_conf.h.
In my case, can it create a redefinition conflict, when building?

Moreover, if I try to omit USE_FULL_LL_DRIVER preprocessor symbol, the build is successful.
My be this depend on the fact that, at the moment, I am using only few LL functions (the CRC ones)?

Thank you,

Carlo

[TDK]

> In this case I have an error indicating that the stm32_assert.c file is absent.

You need to have assert_param defined somewhere (typically in _conf.h file, which redefines it to assert_failed).

You need to have assert_failed somewhere as well, typically in error_handler.c or stm32_assert.c.

If you generate with HAL, these should be generated correctly for you.

[CTabo.1]

Hello,
I have defined assert_failed() in a dedicated file.

If I define only USE_HAL_DRIVER and not USE_FULL_LL_DRIVER, I have no problems.
If I define both USE_HAL_DRIVER and USE_FULL_LL_DRIVER, I have the following error:

stm32g0xx_ll_dma.c:24:10: fatal error: stm32_assert.h: No such file or directory

In this case, if I add the stm32_assert.h file, the build succeded.

So, is it ok to include the stm32_assert.h in a project where both USE_HAL_DRIVER and USE_FULL_LL_DRIVER are defined?
Because UM2319 says that stm32_assert.h should be included only in LL stand-alone projects.

Thank you,

[Tesla DeLorean]

Have stm32_assert.h check for reentry, perhaps then refer to it in stm32g0xx_hal_conf.h

Remove duplication. If you don't have stm32_assert.h, or in the Include Paths, it can obviously fail.

As the programmer decide where it is you want this material reside so things that are in common don't get duplicated

[TDK]

I wouldn't get too hung up on it--if it needs that file, just include it.

If this is something being generated directly by CubeMX and it throws that error, it's definitely a bug and include the IOC file. But if it comes about because you're modifying generated code, you're sort of expected to own the code at that point and make the necessary modifications.

You can look at the file and see it needs that definition only when USE_FULL_ASSERT is defined.

#if defined(USE_FULL_LL_DRIVER)

/* Includes ------------------------------------------------------------------*/
#include "stm32g0xx_ll_dma.h"
#include "stm32g0xx_ll_bus.h"
#ifdef USE_FULL_ASSERT
#include "stm32_assert.h"

 

[CTabo.1]

Hello @TDK and @Tesla DeLorean.

I have seen that the code generated with CubeMX, where I use both HAL and LL drivers

builds correctly and:
- Defines both USE_HAL_DRIVERS and USE_FULL_LL_DRIVERS.
- Add the stm32_assert.h file to the project.
- Do not remove duplication of assert_param() neither in stm32_assert.h, nor in stm32g0xx_hal_conf.h.
- Include stm32g0xx_hal.h and stm32g0xx_ll_<ppp>.h, by means of main.h, in all source files.

So I have decided to define both USE_HAL_DRIVERS / USE_FULL_LL_DRIVERS and add stm32_assert.h, without any modification to avoid assert_param() duplications, also in my actual project, generated without CubeMx.

It build succesfully, and even if something is still not clear to me, for the moment is ok. 

Thank you,

Carlo

[FBL]

Hello @CTabo.1 

Thank you for your feedback.

An internal ticket 161883 has been submitted to avoid duplicated definitions generated by CubeMX.