Skip to main content
MFred.2
Associate III
October 11, 2021
Solved

STM32CubeIDE 1.7, MCU package L4 Series 1.17 : VTOR is not initialized

  • October 11, 2021
  • 9 replies
  • 9909 views

In file generated by CubeMx when creating a new project, the SystemInit function does not set the register of the interrupt vector table (SCB-> VTOR) !!!

The default value is zero, which causes a crash on the first interrupt trigger, i.e. the code loops to an address 0x1FFFxxxx (system memory)

  1. freshly generated code

/**

 * @brief Setup the microcontroller system.

 * @retval None

 */

void SystemInit(void)

{

#if defined(USER_VECT_TAB_ADDRESS)

 /* Configure the Vector Table location -------------------------------------*/

 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;

#endif

 /* FPU settings ------------------------------------------------------------*/

#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)

 SCB->CPACR |= ((3UL << 20U)|(3UL << 22U)); /* set CP10 and CP11 Full Access */

#endif

 /* Reset the RCC clock configuration to the default reset state ------------*/

...

code of the previous version of the package

/**

 * @brief Setup the microcontroller system.

 * @param None

 * @retval None

 */

void SystemInit(void)

{

 /* FPU settings ------------------------------------------------------------*/

 #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)

   SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */

 #endif

 /* Reset the RCC clock configuration to the default reset state ------------*/

 /* Set MSION bit */

 RCC->CR |= RCC_CR_MSION;

 /* Reset CFGR register */

 RCC->CFGR = 0x00000000U;

 /* Reset HSEON, CSSON , HSION, and PLLON bits */

 RCC->CR &= 0xEAF6FFFFU;

 /* Reset PLLCFGR register */

 RCC->PLLCFGR = 0x00001000U;

 /* Reset HSEBYP bit */

 RCC->CR &= 0xFFFBFFFFU;

 /* Disable all interrupts */

 RCC->CIER = 0x00000000U;

 /* Configure the Vector Table location add offset address ------------------*/

#ifdef VECT_TAB_SRAM

 SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */

#else

 SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */

#endif

}

why this register is no longer set with the default flash memory address ?

Thanks for your help

Best answer by Imen.D

Hello @MFred.2​ ,

There is a change request which is deployed on all STM32 series:

the purpose is to set SCB->VTOR only when requested by user application. This is for protect Vector table modification following SRAM or FLASH preprocessor directive by a generic preprocessor directive : USER_VECT_TAB_ADDRESS

So, the following lines from the previous version of the package:

/* Configure the Vector Table location add offset address ------------------*/
#ifdef VECT_TAB_SRAM
 SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */
#else
 SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
#endif
 

are updated as follow:

#if defined(USER_VECT_TAB_ADDRESS)
 /* Configure the Vector Table location -------------------------------------*/
 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
#endif

If user want to force SCB-> VTOR configuration at start-up level, he shall just uncomment this line (Line 127) in system_stm32l4xx.c file:

/*!< 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 */

Note that the system_stm32l4xx.c available in CMSIS file is provided as template file and user shall copy/past this file in his application and customize it as he wants.

I hope that is clear now :).

Thanks for your contribution and do not hesitate to raise any issue/ feedback.

If you issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly :)

Imen

9 replies

Tesla DeLorean
Guru
October 11, 2021

Trying to understand why, and why this wasn't done with symbols the linker could fix-up, will give anyone migraines..

Little appears to get tested, or scrutinized by QA

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
MM..1
Chief III
October 11, 2021

Your code have other issue, because this

#if defined(USER_VECT_TAB_ADDRESS)
 /* Configure the Vector Table location -------------------------------------*/
 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
#endif

isnt used, and VTOR is initialized ok by HW. I have project with same SystemInit and works without problems.

But yes this defines seems as bug migraines

MFred.2
MFred.2Author
Associate III
October 12, 2021

Indeed, without setting VTOR, the code sometimes works depending on the configuration of the peripherals in CubeMx. I have encountered this same problem with the default NUCLEO L4XX board projects. Really very strange.

I do not understand the purpose of this modification !!!

Imen.DBest answer
Technical Moderator
October 14, 2021

Hello @MFred.2​ ,

There is a change request which is deployed on all STM32 series:

the purpose is to set SCB->VTOR only when requested by user application. This is for protect Vector table modification following SRAM or FLASH preprocessor directive by a generic preprocessor directive : USER_VECT_TAB_ADDRESS

So, the following lines from the previous version of the package:

/* Configure the Vector Table location add offset address ------------------*/
#ifdef VECT_TAB_SRAM
 SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */
#else
 SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
#endif
 

are updated as follow:

#if defined(USER_VECT_TAB_ADDRESS)
 /* Configure the Vector Table location -------------------------------------*/
 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
#endif

If user want to force SCB-> VTOR configuration at start-up level, he shall just uncomment this line (Line 127) in system_stm32l4xx.c file:

/*!< 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 */

Note that the system_stm32l4xx.c available in CMSIS file is provided as template file and user shall copy/past this file in his application and customize it as he wants.

I hope that is clear now :).

Thanks for your contribution and do not hesitate to raise any issue/ feedback.

If you issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly :)

Imen

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"
MFred.2
MFred.2Author
Associate III
October 14, 2021

Thank you for this feedback

I understood this possibility of customizing the vector table, but I am not convinced by this new code. It breaks compatibility with all previous versions. In 98% of cases, the vector table is defined at the beginning of flash memory.

The interest of CubeMX is to generate a code template for people who are not necessarily micro-controller experts and which works without asking too much questions.

I have been using the Cube environment since the acquisition of Attolic Truestudio, and I was tricked by this code change. And it is not the innocuous sentence in the "CMSIS release note" file (Update VTOR configuration to be modified by user) which helped me.

Otherwise, I think the code below would have been better

#if defined(USER_VECT_TAB_ADDRESS)
 /* Configure the Vector Table location -------------------------------------*/
 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
#else
 /* Vector Table Relocation in Internal FLASH */
 SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;
#endif
 
 

best regards

Frederic

MFred.2
MFred.2Author
Associate III
October 14, 2021

Maybe it would be good to show this vector table configuration in the Project Manager tab of CubeMx?

best regards

Frederic

Technical Moderator
October 14, 2021

Thanks Frederic for taking the time to post your feedback. I will escalate this internally to the appropriate team.

Hi @Khouloud OTHMAN​ , @Khouloud ZEMMELI​ ,

Can you please take Frederic's request regarding the CubeMX part ?

Thanks

Imen

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"
VBess.1
Associate II
October 24, 2023

I just spent 2 weeks of nightmare because of this. I have 2 old projects with a STM32L476 that were written with AC6 System Workbench. I needed a little modification on one of these and converted it to use CubeIDE and ... the bank switching didn't work anymore...I checked compiler options and ioc file many times, created a new simple blink led project that didn't work.

If there had been something in CubeMX I wouldn't have lost that much time figuring out what went wrong. I understand this change, but pleeeaase try to preserve backward compatibility by default when introducing such things.

OSpil.1
Associate II
January 24, 2024

Same on STM32L051. Weird change which makes vanilla CubeMX projects not working.
Spent few hours until found this thread.

Associate II
November 14, 2024

I too (running CubeIDE v1.16.1 and FW_F1 v1.8.6 with a STM32F103C6T6A BluePill-like board from Amazon making a simple Blink test) just wasted a few hours trying to diagnose why HAL_Delay() wasn't working and why SysTick interrupt was jumping to a strange address with meaningless disassembly code until I fortunately found this thread. When creating a new project in CubeIDE, I wish the project configuration defaulted to the common case of having the interrupt table at the start of flash, and if user wanted something more intricate then there could be special options in the Project Manager tab.

Associate
January 12, 2025

I came across this issue in Jan. 2025 when testing a custom board with a

STM32G071KBT6

The LED is now blinking but it does feel a bit odd that this issue is still a thing years after it has been raised.

Best wishes

Olaf

Explorer II
March 14, 2025

Just ran into this issue with an STM32l431CCT6. On what planet should *default configuration* in ST's first party IDE crash out when any interrupt is fired. That's just not acceptable.