SysTick_Handler not called, STM32G0B1

[Xme]

I am using CubeIde for the first time.

First test - run minimal program with HAL from CubeIDe Configurator, under debugger

Simple program, only SYSTICK and uart , but SysTick_Handler() is not trigged at all .

And function HAL_Delay hangs because uwTick is always 0. Tried with setting brakepoint inside handler - no results

Used HSI, SYSCLK 16MHZ, Cortex System Timer 16MHz,

RCC GPIO and USART1 - HAL configured.

here is main() generated from cubeide (I removed comments):

-----------------------------------------------------------

int main(void)

{

  HAL_Init();

 SystemClock_Config();

 MX_GPIO_Init();

 MX_USART1_UART_Init();

 HAL_Delay(100);

// here program hangs, when reaches HAL_Delay function. uwTick = 0

 while (1)

 {

 }

}

-----------------------------------------------------------

and here is the SysTick_handler from stm32g0xx_it.c

-----------------------------------------------------------

void SysTick_Handler(void)

{

 HAL_IncTick();

}

-----------------------------------------------------------

[Tesla DeLorean]

Or even just using the linker symbol​ so the VTOR just tracks how the project is built.

[Piranha]

For example, on F7 series an address 0 points to ITCM RAM. But on these devices the VTOR defaults to either FLASH on ITCM or System memory. However the user will typically run the firmware from FLASH on AXI and will want to set VTOR to it.

[XR.1]

What the heck with ST? What is his problem? It's november 2024! Thank you to @Xme for the workaround, but really ST? 3 years and the problem persists?

With a NUCLEO-G070RB (with STM32G070CB (64 terminals)) I was able to make some big advances for a project with almost not issues. But now that I got the PCB's (that populate a STM32G070CB (48 terminals)) the SysTick_Handler() function didn't trigger! 

Looking for a solution I found the one given by @Xme:

```

// system_stm32g0xx.c:
void SystemInit(void)
{
/* Configure the Vector Table location -------------------------------------*/
#if defined(USER_VECT_TAB_ADDRESS)
SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET; /* Vector Table Relocation */
#endif /* USER_VECT_TAB_ADDRESS */
SCB->VTOR = FLASH_BASE;  // <---------------- WORKAROUND!
}

```

Now my IamAlive LED is blinking.

[XR.1]

2024 (almost 2025): Problem still not solved in STMCube...

[Tesla DeLorean]

Check what your board is doing with BOOT0 pin or BOOTn option byte settings.

Check it's not a YOU problem.

[Tesla DeLorean]

Perhaps it's a problem with the board or part configuration?

[XR.1]

BOOT0 is shared with SWCLK, and as I'm debugging with a ST-LINK/V2, I didn't populate its associated components in my PCB, as shown:

Which component should I need to place? Maybe I'm thinking in that SWCLK pulls correctly BOOT0 (6.3.1 from the UM say so, but it's unclear), and such assumption might be incorrect.

Boot_Ext is for an external signal that will trigger the boot process.

Boot_Enter is for an internal signal (mcu pin) that will trigger the boot process under the program logic.

In any case, both signals are disconnected and only the SWCLK from ST-LINK is attached.

Any ideas?

Is it safe to place R100 and R101 from the SWCLK side? 

[Tesla DeLorean]

A pull down is probably what you need.

If you place both pay attention to values chosen as now a potential divider.

If shorted to 3.3V resistors not going to make a lot of different.

If left to float BOOT0 will be in indeterminate state and why vector table mapping at zero is broken.

Better approach from ST would have been to set SCB->VTOR = &g_pfnVectors[0];

[PGump.1]

HI,

I've had that issue - you'll find it's because the compiler puts the enable IRQ instruction behind the while(1)...

Try

...
    __enable_irq();
    HAL_Delay(100);
...

Kind regards
Pedro

[XR.1]

UM_6.3.1 says that SWCLK has a pull-down resistor:

However, I've done a discovery: without the workaround the register SBC-VTOR is zero when reaching the main() function:

With the workaround such register takes the value 0x8000000: