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�?.

[char_array]

"Break at address "0x1fff4ec0" with no debug information available, or outside of program code."

Program doesn't run further. Cannot break, or sometimes cannot even stop the debugger and I have to physically disconnect USB. Even without debugger connected the program doesn't run.

I added an example in my starting post.

[TDK · Accepted solution]

> 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.

[char_array]

I just tested. SCB->VTOR is cleared when I enter main. It is set to 0. But that cause a crash. It needs to be set to FLASH_BASE, which is 0x8000000 in my case. If I manually set the value to 0x8000000 in the watch it works too. Now I wonder why it sometimes works...

.

[char_array]

I had more stability issues after this. Crashes and often not booting. Every time I thought I found something that fixed it I discovered later that the issue returned. A cleaner way to set the VTOR is to define USER_VECT_TAB_ADDRESS in the preprocessor area of project settings. While that did reduce the number of crashes it did not stop it.

Pulling down the boot pin also helped to some extend. There were some issues with the power supply too, but that didn't fix it either.

But the one thing that seems to really have fixed it is the BOOT_LOCK byte and the nSWBOOT byte. When comparing the Option Nytes from the devboard to our MCU I found out it has different settings. Setting BOOT_LOCK to true and nSWBOOT to false with STM32CubeProgrammer prevents crashing and will guarantee booting in my case.