STM32G0B0 VTOR gets reset to zero for no obvious reason. Video provided
Hello,
I am using an STM32G0B0 and am debugging the process of the bootloader handing over control to the application.
The bootloader goes through its handover process without an issue.
The final part of the bootloader handover looks like this.
{
pFunction appEntry;
uint32_t appStack;
Cpu_WDT_Kick(); // kick the watchdog
HAL_DeInit(); //test to see if this disablles all the peripherals, so we don't have to do it individually like below with the USB and the timers
//disable all interupts while we are jumping to the app.
//this is because our interrupt vector table is changed during this jump
//and we dont want to jump to the wrong memory region
__disable_irq();
// Get the application stack pointer (First entry in the application vector table)
appStack = (uint32_t) * ((__IO uint32_t *)CONFIG__APPLICATION_BASE_ADDRESS);
// Get the application entry point (Second entry in the application vector table)
appEntry = (pFunction) * (__IO uint32_t *)(CONFIG__APPLICATION_BASE_ADDRESS + 4);
// Reconfigure vector table offset register to match the application location
SCB->VTOR = CONFIG__APPLICATION_BASE_ADDRESS;
__DSB();
// Set the application stack pointer
__set_MSP(appStack);
// Start the application
appEntry();
}When it goes into appEntry(), it goes through the normal system init and enters main();
main looks like this
int main(void)
{
disableRamCrcChecking();
#if RELEASE_BUILD
SCB->VTOR = CONFIG__APPLICATION_BASE_ADDRESS;
__DSB();
__enable_irq();
#endif
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_DMA_Init();
MX_SPI1_Init();
MX_ADC1_Init();
MX_I2C1_Init();
MX_I2C2_Init();
MX_USART1_UART_Init();
MX_USART2_UART_Init();
MX_CRC_Init();
MX_USB_Device_Init();
MX_TIM6_Init();
MX_SPI3_Init();
MX_TIM7_Init();
MX_IWDG_Init();
while (1)
{
app();
}
}If we set a breakpoint at app() and we check the SCB->VTOR register, the value shows 0x08012800
When we step a single step into app(), SCB->VTOR register changes to 0x00000000
The final part of this process can be observed in the attached video.
I have spent quite a while on this and I cannot explain why it is happening.
I have this same code working on other STM32 processors without an issue (STM32F4,F0,L100 etc), so I suspect it may have something to do with it being a CortexM0+ (maybe).
All suggestions are welcome.
Thanks for your help.