Bug in stm32l4xx_hal_conf.h template file

[MVigni]

Hi, I just noticed that if Enable Full Assert option is enabled in the Project Manager, the generated stm32l4xx_hal_conf.h file has the following definition for assert failed:

void assert_failed(char *file, uint32_t line);

Which conflicts with the other definition in main.c

void assert_failed(uint8_t *file, uint32_t line)

I guess one of the two must be changed because this causes compile errors.

Also I would suggest to change the definition of the assert_param() macro when the full assert option is not enabled form

#define assert_param(expr) ((void)0U)

to

#define assert_param(expr) ((void)(expr))

so that it will prevent unused variable/parameter compiler warnings in some cases

[Nesrine.JLASSI]

Hi @MVigni​ 

Could you please share your .ioc file to check the issue.

Best regards,

Nesrine

[MVigni]

Here it is

[alister]

This bug's in FW_F0 V1.11.0 too.

It’s declared “void assert_failed(uint8_t* file, uint32_t line);�? in stm32f0xx_hal_conf.h and defined “void assert_failed(char* file, uint32_t line) in main.c.

But the correct definition of this function should be “void assert_failed(const char *file, uint32_t line);�?

Can't know where the uint8_t came from. Perhaps someone’s confused over MISRA and char. It’s const char because __FILE__ is a string literal.

The “const�? is because the function won’t change it. It allows the compiler to generate better code in some circumstances, makes the compiler throw a warning if the coder makes a mistake and tries to change it, and finally, any reader of the code will see the const and immediately understand, in addition and possibly despite of comments, the argument is an input to the function and their understanding will be more complete and faster.

For examples of best practice, check the prototypes in string.h.

[Nesrine.JLASSI]

Hi @alister​  @MVigni​ 

Thanks for your feedback, issue confirmed, it will be internally fixed.

Best Regards,

Nesrine

[MVigni]

Thank you @Nesrine.JLASSI​.

I would also like to report another bug that you can verify with the same .ioc file I have already uploaded.

In that project, I have activated Freertos and I am using TIM7 as the timebase for the HAL Tick.

That generates the file stm32l4xx_hal_timebase_tim.c

The template of this file has a bug: it is missing a line to update the uwTickPrio variable. That triggers an assert later on during the HAL_Init() function.

I would suggest to fix the template adding the missing line I have marked below like this:

HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
  RCC_ClkInitTypeDef    clkconfig;
  uint32_t              uwTimclock = 0;
  uint32_t              uwPrescalerValue = 0;
  uint32_t              pFLatency;
  
  /*Configure the ${instance} IRQ priority */
  HAL_NVIC_SetPriority(${timeBaseInterrupt}, TickPriority ,0); 
  uwTickPrio = TickPriority;          //<--- MISSING LINE!
  
  /* Enable the ${instance} global Interrupt */
  HAL_NVIC_EnableIRQ(${timeBaseInterrupt}); 
  
  /* Enable ${instance} clock */
  __HAL_RCC_${instance}_CLK_ENABLE();
[#if FamilyName=="STM32MP1"]
  __HAL_RCC_${instance}_FORCE_RESET();
  __HAL_RCC_${instance}_RELEASE_RESET();
[/#if]

[Nesrine.JLASSI]

Okay, i'll check it 🙂

Regards,

Nesrine

[Nesrine.JLASSI]

Hi @MVigni​ 

Thanks for the feedback,

Issue confirmed, it will be internally fixed.

Best regards,

Nesrine