cancel
Showing results for 
Search instead for 
Did you mean: 

Why assert_failed in HAL_InitTick()?

CKugl.1
Senior II

After spending some time debugging my project, I was able to narrow my problem down to this and reproduce it as follows:

  1. File, New, STM32 Project
  2. Select NUCLEO-L412KB
  3. In Pinout & Configuration, SYS, choose Timebase Source TIM16
  4. In Project Manager, Code Generator, select Enable Full Assert
  5. Debug...

assert_failed() at main.c:197 0x80002a0 HAL_NVIC_SetPriority() at stm32l4xx_hal_cortex.c:192 0x80006fe HAL_InitTick() at stm32l4xx_hal_timebase_tim.c:49 0x800030e HAL_RCC_OscConfig() at stm32l4xx_hal_rcc.c:482 0x8000a7a SystemClock_Config() at main.c:124 0x800022c main() at main.c:79 0x80001d8

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @CKugl.1​ , @TDK​ , @Pavel A.​ 

Thanks for your feedbacks.

Actually you're right, tick priority handling in HAL_Init_Tick() is wrong in case timer source is not SysTick.

With the default time base everything works fine. However when using another time base (e.g. TIM16), the generated stm32g4xx_hal_timebase_tim.c > HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority) is not correct (the priority will not be stored).

This issue was already detected and reported internally to be fixed. I'll keep you posted with the updates.

Sorry for any inconvenience that this may cause.

Internal ticket number: 116854 (This is an internal tracking number and is not accessible or usable by customers).

Khouloud.

View solution in original post

13 REPLIES 13
TDK
Guru

I couldn't reproduce. Can you include your main.c file?

If you feel a post has answered your question, please click "Accept as Solution".

I couldn't reproduce. Can you include your main.c file?

Edit: my code generates differently than yours, as the line numbers don't match up, however, the issue is the tick priority is set to 16, which is invalid. Oddly, the code comments indicate this priority is invalid (so why did it generate it??).

#define IS_NVIC_PREEMPTION_PRIORITY(PRIORITY)  ((PRIORITY) < 0x10)
 
  assert_param(IS_NVIC_PREEMPTION_PRIORITY(PreemptPriority));
 
  HAL_NVIC_SetPriority(TIM1_UP_TIM16_IRQn, TickPriority ,0);
 
  status = HAL_InitTick(uwTickPrio);
 
#define __NVIC_PRIO_BITS          4       /*!< STM32L4XX uses 4 Bits for the Priority Levels */
 
uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS); /* Invalid priority */
 

I don't see a way of changing this within CubeMX, but you can set its value in the user code before SystemClock_Config().

/* USER CODE BEGIN Init */
  uwTickPrio = (1UL << __NVIC_PRIO_BITS) - 1;
  /* USER CODE END Init */

 Although, if the timebase is a timer, then SysTick shouldn't be getting enabled at all. Maybe I'm missing something here.

Edit: I was missing something. The weak definition for HAL_InitTick is overridden in the user code, so the problem is just the tick priority is incorrectly set.

If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

TICK_INT_PRIORITY should be defined in stm32l4xx_hal_conf.h so this should be

uwTickPrio = TICK_INT_PRIORITY

CKugl.1
Senior II

Here is main.c and stm32l4xx_hal_conf.h:

CKugl.1
Senior II

Hmm, that didn't work...

@TDK​  wrote:

> I don't see a way of changing this within CubeMX, but you can set its value in the user code before SystemClock_Config().

Thanks. This fix does work, but it was not obvious to me as someone new to STM32. Maybe the user guide should mention it.

It’s just a bug in CubeMX code generation. Not something that you should have needed to fix. Understandable that it would trip you up, new or not.
If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

It's not clear why uwTickPrio is initialized to a bad value in ...hal.c

If this is to check that the NVIC interrupt priority is (not) already set, the bug is in HAL code.

Hello @CKugl.1​ , @TDK​ , @Pavel A.​ 

Thanks for your feedbacks.

Actually you're right, tick priority handling in HAL_Init_Tick() is wrong in case timer source is not SysTick.

With the default time base everything works fine. However when using another time base (e.g. TIM16), the generated stm32g4xx_hal_timebase_tim.c > HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority) is not correct (the priority will not be stored).

This issue was already detected and reported internally to be fixed. I'll keep you posted with the updates.

Sorry for any inconvenience that this may cause.

Internal ticket number: 116854 (This is an internal tracking number and is not accessible or usable by customers).

Khouloud.