There is something strange happening with STM32N657x0HxQ MCU when HAL tick timer is not using SysTick, but a timer like TIM6, and TIMPRE is changed to 4 or 8 while timer is active. Observed it on DK and custom board.
I created isolated test code with CubeMX v6.17.0 for STM32N6570-DK and STM32CubeIDE v2.1.0 to reproduce the issue. IOC file and code in attachment. Test code is in FSBL and it just blinks LED1 with 1 second period. When TIMPRE is 1 or 2, it blinks correctly. To reproduce:
Change TIMPRE to 4 or 8 in clock tree and generate + build the code:
Power up the board in development mode (BOOT1 = 1). On real application it only happens on cold boot. With this test code it seems to appears all the time.
Launch the FSBL with debugger. Debugger should break at HAL_Init(). Press Run. Nothing happens. LED does not blink. Pause debugger and watch uwTick value:
CPU is busy in TIM6_IRQHandler and with few seconds, the count has reached 489211. CPU is busy serving only the timer interrupt request and can't do anything else - even finish the LED blink delay as seen in call stack.
It seems like MCU hardware does not like TIMPRE change to 4 or 8 when timer (TIM6) is already running. Change to 2 does not break it.
HAL tick is initialized twice - first from HAL_Init() and then at the end of SystemClock_Config(), after TIMPRE is changed. So it appears the re-init of HAL tick timer does not fix it. However in our application, I have few times seen it recover back to normal frequency, because in my system log where I print HAL tick timestamp with log messages, I have seen messages starting up with pretty big numbers (5+ million milliseconds) and then continue increasing normally.
Did not find anything about it from errata and on quick search did not find any cautions from RM either.
