Missing USER_VECT_TAB_ADDRESS leads to debug issue

[BobbyBeta]

I see it's been a while but I ran into this today. Apparently system_stm32g4xx.c that is automatically generated by STM32MX no longer sets SCB->VTOR unless you define USER_VECT_TAB_ADDRESS in that file. When programming that doesn't cause an issue but it does stop you from debugging if interrupts are enabled.

I wasted half a day of my life on this today. I don't know what benefit ST thought we'd get by changing this but breaking debugging for their customers they probably wasted a lot of the world's time. An awful lot of people were used to being able to generate code and use the debugger without modifying an autogenerated file they'd never needed to modify before.

Edit: moved from HAL_Delay() --> SysTick_Handler never be called to a new thread.

[Tesla DeLorean]

There was some mention of this the other week.

I'm not sure why this can't just be handled by the linker and a symbol, or just put the code in startup.s and the Reset_Handler if the symbol has to be different for different tool chains. That way it would follow the linker script or scatter file, and not require edits in multiple sources.

[BobbyBeta]

Do you happen to understand why my code ran fine when not debugging, as if SCB->VTOR was the correct value upon powerup? That symptom is largely why I wasted a lot of time before looking at that root cause.

I generated a minimal project for the STM32G474 that only used TIM1 and some GPIO. I toggled GPIO in the main loop, the UPDATE ISR, and the CC1 ISR. When debugging I wouldn't see any of the GPIO toggling and halting showed the PC in some random location (around 0x1FFF5064). When I power cycled I found all of the GPIO toggling as expected though!

That lead to me searching through debug configuration settings for half the day. I'm happy to fix the problem by defining USER_VECT_TAB_ADDRESS so I can do real work again, but I don't understand why I didn't need SCB->VTOR to be set at startup upon powerup.