STM32CubeIDE generates invalid code for assert_failed function

[MaslogMike]

I have 1.3.1 STM32CubeIDE. When I choose the generation for full assert the tool generates invalid declaration:

stm32l4xx_hal_conf.h (r. 427 ->)

/* Exported macro ------------------------------------------------------------*/
#ifdef USE_FULL_ASSERT
/**
 * @brief The assert_param macro is used for function's parameters check.
 * @param expr: If expr is false, it calls assert_failed function
 * which reports the name of the source file and the source
 * line number of the call that failed.
 * If expr is true, it returns no value.
 * @retval None
 */
 #define assert_param(expr) ((expr) ? (void)0U : assert_failed((uint8_t *)__FILE__, __LINE__))
/* Exported functions ------------------------------------------------------- */
 void assert_failed(char *file, uint32_t line);
#else

assert_failed is declared as f(char*, unsigned int) and char is signed. In main.c the definition is f(unsinged char *, unsigned int).

#ifdef USE_FULL_ASSERT
/**
 * @brief Reports the name of the source file and the source line number
 * where the assert_param error has occurred.
 * @param file: pointer to the source file name
 * @param line: assert_param error line source number
 * @retval None
 */
void assert_failed(uint8_t *file, uint32_t line)
{ 
 /* USER CODE BEGIN 6 */
......

The definition differs from declaration the compilation always fails. Since I must use strict type checking and I am not allowed to change char from signed to unsigned. It would be nice if assert_failed is either char-based or uint8_t-based.

Anyway, in any coding standard that would be considered as fault. The declaration and the definition must be the same. It is not much, but it is nuisance.

[TDK]

Appears to be an L4-specific bug as it generates correctly for the F4 and H7 series. Didn't check other families:

/* Exported macro ------------------------------------------------------------*/
#ifdef USE_FULL_ASSERT
/**
 * @brief The assert_param macro is used for function's parameters check.
 * @param expr: If expr is false, it calls assert_failed function
 * which reports the name of the source file and the source
 * line number of the call that failed. 
 * If expr is true, it returns no value.
 * @retval None
 */
 #define assert_param(expr) ((expr) ? (void)0U : assert_failed((uint8_t *)__FILE__, __LINE__))
/* Exported functions ------------------------------------------------------- */
 void assert_failed(uint8_t* file, uint32_t line);
#else
 #define assert_param(expr) ((void)0U)
#endif /* USE_FULL_ASSERT */ 

[Amel NASRI]

Hi @Community member​ ,

This is a known limitation that we expect to fix with STM32CubeMX 6.0.0 (will be available soon on the web).

Just stay tuned and make the test for us as soon as this version is available to check it.

-Amel

[MaslogMike]

Hi. Thanks for answers.

Are STM32CudeMX and the IDE in sync? Once I tested some latests versions and their code generation or IOC handling was different.

Anyway, its not a big deal, but just annoying feature. It often makes one extra build cycle for me (no, I am not able to learn avoid that :)

[Amel NASRI]

If you make regular updates of STM32CubeIDE (whenever they are available), you will see that STM32CubeMX and STM32CubeIDE are in sync.

-Amel

[Amel NASRI]

Hi @Community member​ ,

Please note that STM32CubeMX 6.0 is already available. It will be helpful if you can check the reported issue on your side.

-Amel

[MaslogMike]

Hi Amel

​

Thanks for information. I upgared my CubeIDE to 1.4. It seems to have that problem fixed.​

​

Thanks ,

MM​