When you create a new STM32G0 project in STM32CubeIDE, the debugger initially seems to work correctly. Code execution runs normally until the first interrupt occurs (in my case, the SysTick interrupt). At that moment the program counter suddenly jumps outside of the Flash memory space, so the debugger can no longer show valid source code corresponding to the PC value.
At first this is very confusing — nothing seems obviously wrong.
If you found this explanation after spending time trying to understand the issue: congratulations, you’re not alone, and thanks to ST’s silicon/initial configuration quirks, many people have run into the same problem.
Root Cause
The STM32G030/G031 devices ship from the factory with Boot Pins/Bootloader/Option Bytes configuration making the Vector Table Offset Register (VTOR) incorrectly pointing to the System Memory bootloader instead of the user Flash at first debug run.
Specifically, instead of:
SCB->VTOR = 0x08000000; // Start of user Flash
the chip powers up with:
SCB->VTOR = 0x1FFF0000; // Address of the System Memory bootloader region
As a result, when the first interrupt fires (SysTick, TIM, EXTI, etc.), the CPU loads the interrupt handler address from the bootloader’s vector table, jumping execution into the system memory bootloader. Since this area does not match the application’s ELF file, the debugger appears “lost,” showing no valid source for the current PC.
This explains why debugging works only until the first interrupt.
The incorrect VTOR setting occurs only on factory-new microcontrollers (verified on STM32G030 and STM32G031 small-pin packages such as TSSOP-20 and QFN-28).
Solution / Workaround
Just make microcontroller power cycle and the vector table address during debug issues will be resolved permanently, or without power cycle just assign the Vector Table Offset Register to the start of Flash at the beginning of main():
SCB->VTOR = FLASH_BASE; // To ensure that the vector table points to user Flash
After any of above: Debugging or application run works normally.
Expected Vector Table Mapping
Correct FLASH program space vector table mapping:
The vector table at address 0x00000000 is correctly remapped to the Flash region at 0x08000000, and both appear identical.
Address 0 content:
And the address 0x08000000 content:
Address 0x1FFF0000 content (System bootloader):
Option bytes of a new microcontroller without FLASH programming (first run):
Looks the same as after loading FLASH with program and power cycle:
Links to the same issue:
