cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G0B0 VTOR gets reset to zero for no obvious reason. Video provided

SORei.1
Associate II

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.

 

6 REPLIES 6
SofLit
ST Employee

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?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
gbm
Lead III

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();

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

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

will do, thanks for the input

If you disable the watchdog, you still getting the same behavior?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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