HAL_Delay() --> SysTick_Handler never be called

[bibah]

Hi all,

Version: 1.15.1

MCU : g473

Before investigate deeply on my own I wonder whether if anyone have faced the same problem with Interrupt table in general ...

I placed a breakpoint there :

void SysTick_Handler(void)

{

/* USER CODE BEGIN SysTick_IRQn 0 */

/* USER CODE END SysTick_IRQn 0 */

HAL_IncTick();

/* USER CODE BEGIN SysTick_IRQn 1 */

/* USER CODE END SysTick_IRQn 1 */

}

and surprisingly the code is never executed !

Best regards,

[Sarra.S]

Hello @bibah, 

Have you used CubeMX to generate the code? if yes, what's the version? 

Also, maybe provide some context, are you using a bootloader, or have remapped the vector table?

The SysTick timer needs to be initialized before it can trigger interrupts, I assume you did that

Maybe verify systick interrupt priority? and ensure that global interrupt is enabled

[bibah]

Hi Sarra,

STM32CubeMX - STM32 Device Configuration Tool

Version: 6.11.1-RC2

Build: 20240411-0753 (UTC)

No BootLoader and no remapped the Vector Table

Early in the code generated by CubeMX

• HAL_Init();
• SystemClock_Config();
• MX_NVIC_Init()
• ....

And finally I found a solution detailed here :

 I uncommented /*#define USER_VECT_TAB_ADDRESS*/ in system_stm32g4xx.c so it lay on Flash now

/************************* Miscellaneous Configuration ************************/

/* Note: Following vector table addresses must be defined in line with linker

configuration. */

/*!< Uncomment the following line if you need to relocate the vector table

anywhere in Flash or Sram, else the vector table is kept at the automatic

remap of boot address selected */

#define USER_VECT_TAB_ADDRESS

#if defined(USER_VECT_TAB_ADDRESS)

/*!< Uncomment the following line if you need to relocate your vector Table

in Sram else user remap will be done in Flash. */

/* #define VECT_TAB_SRAM */

#if defined(VECT_TAB_SRAM)

#define VECT_TAB_BASE_ADDRESS SRAM_BASE /*!< Vector Table base address field.

This value must be a multiple of 0x200. */

#define VECT_TAB_OFFSET 0x00000000U /*!< Vector Table base offset field.

This value must be a multiple of 0x200. */

#else

#define VECT_TAB_BASE_ADDRESS FLASH_BASE /*!< Vector Table base address field.

This value must be a multiple of 0x200. */

#define VECT_TAB_OFFSET 0x00000000U /*!< Vector Table base offset field.

This value must be a multiple of 0x200. */

#endif /* VECT_TAB_SRAM */

#endif /* USER_VECT_TAB_ADDRESS */

/******************************************************************************/

My question :

Is it a normal situation the Vector Table will not be generated by default ?

Best Regards, H

[Sarra.S · Accepted solution]

Hello @bibah, 

Uncommenting the "define USER_VECT_TAB_ADDRESS" allows for the relocation of the vector table, which can be necessary for certain applications (that's why I asked about the bootloader) or when the application needs to be located at a specific address in memory, that's why maybe some details are required on your application...

In previous STM32CubeMX versions, the line #define USER_VECT_TAB_ADDRESS was uncommented by default, which would automatically relocate the vector table, but in later versions, for more flexibility,  you have the choice to uncomment it if you need to.

[bibah]

Ok Sarra,

Got it ! Thanks. May be you should include this feature in CubeMX ... no ?

Habib

[lanwailan]

Hi Sarra.S , I have met same problem while my project has a bootloader and a application, the application has correct configured VECT OFFSET , but SysTicK_Handler is not called when jump to application,  do you know how to fix this?

[Sarra.S]

Hello @lanwailan, welcome to the ST Community! 

Could you please ask your question with a detailed description in a separate thread? This will help keep this thread clear and organized. I would be more than happy to support you with your query.

Thank you!

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

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