2024-11-12 10:31 PM
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.
2024-11-13 02:52 AM
Hello,
@SORei.1 wrote:
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
But you configured the watchdog here:
MX_IWDG_Init();
while (1)
{
app();
}
How do you ensure there is no Watchdog reset during your pause on the breakpoint?
2024-11-13 03:10 AM
Also, check what SystemInit() is doing to VTOR. You may get surprised sometimes. SystemInit() is in system_stm32xxx.c and is called from Reset_Handler before main();
2024-11-13 03:20 AM
Hello SofLit,
When the WDT goes off when I am debugging, it takes me back to the reset vector. That is not happening in this instance....BUT it does raise a good question, my WDT should be going off every two seconds...but it isn't when I hit the breakpoint at app()....why? I'll need to investigate that a bit further.
Thanks
2024-11-13 03:20 AM
will do, thanks for the input
2024-11-13 03:21 AM
If you disable the watchdog, you still getting the same behavior?
2024-11-13 09:06 PM
Well, this wasn't the response i was expecting to come back with but
No, I dont.
It appears that the WDT was triggering while I was debugging.
So, @SofLit , when I have had the WDT trigger while I have been debugging before, I have very quickly found myself back at the reset vector BUT in this instance, my debugging session just continued on as though nothing had happened.
Do you have any idea why this would happen?
(I am using VisualGDB for debugging and I have been using both the STLink and the Segger debugger)
Thanks
Stuart