Skip to main content
CCook.1
CCook.1
Associate
July 3, 2021
Question

MEM_MODE SRAM not relocating interrupt vector table on the STM32G03

  • July 3, 2021
  • 3 replies
  • 1797 views

I am porting some STM32F03 code to a STM32G03.

The project uses a bootloader and an application.

Bootloader works, does its thing and jumps to the application code at a different address.

The application will first fill SRAM with it's vector table and then use the __HAL_SYSCFG_REMAPMEMORY_SRAM(); function to map sram at 0 and then continue.

All this works perfectly on the STM32F03, but fails on the STM32G03.

Using the debugger I was able to confirm the following.

The table is getting loaded into sram at 0x20000000.

When I use the debugger to read address 0 after the MEM_MODE change, it's contents does now reflect the SRAM. The M0 vector table address is still 8 (It should be).

However, if I set break points at the sys_tick ISR for both the bootloader and the app, only the ISR for the bootloader is getting called. So interrupts continue to run. But the system is still using the old vector table even though I have remapped the correct table into address 0.

It's acting like the vector table was cached after boot and will not reload from memory.

I have tried everything I can think of to get this working and it will not.

Again, this code works on the STM32F03 and does not work on the SRM32G03

Help!

This topic has been closed for replies.

3 replies

SBEN .2
SBEN .2
Visitor II
July 3, 2021

Hello @CCook.1​ 

In system_stm32g0xx.c, uncomment the definition of VECT_TAB_SRAM:

/************************* Miscellaneous Configuration ************************/
/*!< Uncomment the following line if you need to relocate your vector Table in
 Internal SRAM. */
#define VECT_TAB_SRAM

Best regards,

​@SBEN .2​  

waclawek.jan
waclawek.jan
Super User
July 3, 2021

> When I use the debugger to read address 0 after the MEM_MODE change, it's contents does now reflect the SRAM.

Read out and check content of SYSCFG_CFGR1.MEM_MODE.

> The M0 vector table address is still 8 (It should be).

I don't understand. What is "M0 vector table address"?

The 'G0xx have a Cortex-M0+ processor core, which - in contrast with the Cortex-M0 (without the plus) core of 'F0xx - does incorporate the SCB_VTOR register allowing to remap the vector table address, without the need to remap any7 memory onto 0x0000'0000 address. The macro SBEN.2 is talking about later in the same file causes exactly this, if you call SystemInit() from the startup file (see https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Drivers/CMSIS/Device/ST/STM32G0xx/Source/Templates/system_stm32g0xx.c )

void SystemInit(void)
{
 /* 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
}

JW

Tesla DeLorean
Tesla DeLorean
Guru
July 6, 2021

The vector table defaults to zero (and uses whatever is mapped there), should be set to 0x20000000 for SRAM

Needs to be at some multiple of 128 or 256 bytes based on the size, so make sure it is suitable aligned.

For SYSCFG to work it's clock must be enabled. Lot of ST's early code they used the RESET and not the ENABLE register.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
CCook.1
CCook.1Author
Associate
July 6, 2021

Changing VTOR sure fixed something. But I still have issues, I need to debug some more.

Thanks.

Terms & ConditionsAccessibility statement