stm32g491 crashes in HAL_Init when using timer1!

[char_array]

I select tim1 for sys source in STM32CubeMX and generate code.

I use STM32CubeMX V6.4.0.

I added a stripped example of the code that crashes. HAL_NVIC_EnableIRQ crashes.

[TDK]

Probably getting caught on the the invalid priority bug when using a non-systick time source.

https://community.st.com/s/question/0D53W00001Az92mSAB/why-assertfailed-in-halinittick

[char_array]

Code does crash at HAL_NVIC_EnableIRQ or HAL_NVIC_SetPriority if I step over them. But if I step in these functions with F5 it doesn't always crash.

The priority is set to 15. Priority group is set to 3, meaning 3 priority bits and 1 sub priority bit.

I don't know what that means, but even setting priority to 7 or 0 makes it crash.

So how do I fix it?

Confusing is that Eclipse's Open declaration of HAL_InitTick jumps to the weak version, not the overridden function in *tim.c. But the debugger steps into the correct version obviously.

[TDK]

Define “crash�?.

[TDK]

> Break at address "0x1fff4ec0" with no debug information available,

At a glance, sounds like you've been hit with this issue:

https://community.st.com/s/question/0D53W0000181KD7SAM/stm32cubeide-17-mcu-package-l4-series-117-vtor-is-not-initialized

Systick IRQ is firing, but jumping to an invalid location.

In other words, "working as intended" as far as ST is concerned.

If that is the issue, there are many threads like this​.

[char_array]

@TDK​ It works! You are a life saver! This isn't the first time you fixed my issue.

I added this line to the top of main:

int main(void)
{
 /* USER CODE BEGIN 1 */
 SCB->VTOR = FLASH_BASE | 0;
 /* USER CODE END 1 */

This explains why the problem sometimes occured, but not always. The value of this register is probably random at boot and not cleared by the processor's reset circuit or the C-RTL.

[TDK]

Glad to help. I don't like the change as it leads to undefined and unexpected behavior.
SCB->VTOR should be cleared at reset. Could be that the debugger is doing odd things, or not really resetting the chip.
https://www.st.com/resource/en/programming_manual/pm0214-stm32-cortexm4-mcus-and-mpus-programming-manual-stmicroelectronics.pdf
But people keep getting hit by it, so clearly there's something happening I don't quite understand there.

[waclawek.jan]

> SCB->VTOR should be cleared at reset.

It *is* cleared, but as initial boot was probably from system memory (dangling BOOT0) just overriden by the debugger, the system memory is still mapped at 0 instead of the user FLASH.

Reading memory from 0x0000'0000 and/or SYSCFG_MEMRMP.MEM_MODE would tell the truth.

JW