TICK_INT_PRIORITY changes from 0 to 15 and vice-versa

[ARaid.1]

STM32CubeIDE - Version: 2.0.200.202301271415
STM32CubeMX - Version: 6.8.1-RC4  Build: 20230419-1431 (UTC)

I just added two DMA channels to UART1 and noticed a change in stm32h7xx_hal_conf.h The project uses LwIP and FreeRTOS. FreeRTOS relies on TIM6 as a system timer. I can understand when SysTick has the highest priority. But I can't understand why set it to the lowest in the system? Further, it is not clear why the priority changed again to the maximum?

[Pavel A.]

FreeRTOS uses the systick as the tick timer, and other timer (TIM6) is used by HAL  By the FreeRTOS convention, its tick timer has low (or lowest) priority. For the HAL timer you can assign any suitable priority.

LwIP in RTOS aware mode likely uses the former, but can use the HAL timer too.

Note that higher value (15) is the lowest priority and 0 is the highest.

[ARaid.1]

Pavel A., thank you for your helping support. Good answer, but this is not answered my question.
1. In my current STM32Cube project FreeRTOS uses TIM6 as 1kHz task switching timer. STM32Cube proposed and then set TIM6 as system tick base, leaving ARM SysTick free.

2. The TICK_INT_PRIORITY spontaneously changed in the middle, FreeRTOS was already set long time ago. I do not added/changed anything related to RTOS/System, etc.. I just added two DMA channels to UART1. Why this caused to change TICK_INT_PRIORITY?

3. This is not first time I have noticed TICK_INT_PRIORITY change. I had working STM32F407VG project . When I created new clean STM32F427 project (without FreeRTOS), I compared old and new projects and noticed that TICK_INT_PRIORITY in new fresh project was set to 15 (instead of 0).
Let ST team/employee explain, what is sane rationale/idea to manipulating with SystemTick priority, setting SystemTick to lowest value?

[Pavel A.]

#1: FreeRTOS will initialize the systick and handle its interrupt. its default tick period is 1 ms as well.

For #2: should not happen. Set a watch on this variable in the debugger to catch when it changes. FreeRTOS should not touch it.

[ARaid.1]

For #2: should not happen. Set a watch on this variable in the debugger to catch when it changes.

---

Thank you for support, Pavel A.
TICK_INT_PRIORITY is  textual constant, #define in HAL header   stm32h7xx_hal_conf.h   (look at first post picture).    STM32Cube determines and completely overwrites its textual value during code generation (or refresh, keeping user code) phase.  Indeed, should not happen or at least need explanation 😀

[JPerr.2]

It seems I'm facing the same kind of issue when enabling the trace outputs. See https://community.st.com/t5/stm32cubeide-mcus/tick-int-priority-affected-by-enabling-trace-outputs/m-p/588892/highlight/true#M20524. 

[Pavel A.]

>It seems I'm facing the same kind of issue when enabling the trace outputs.

This is caused by a wrong change of TICK_INT_PRIORITY in  stm32..._conf. h by CubeMX/IDE, when it regenerates a project, if I remember correctly. This may happen after any modification of the .ioc (not just trace).  This is a known bug. Stay calm, revert the bad change.