cancel
Showing results for 
Search instead for 
Did you mean: 

SysTick_Handler not called, STM32G0B1

Xme
Associate II

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

}

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

20 REPLIES 20

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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.

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.

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

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

Check it's not a YOU problem.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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:

Captura de pantalla de 2024-11-19 01-28-14.png

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? 

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];

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

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

Captura de pantalla de 2024-10-29 16-47-51.png

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

Captura de pantalla de 2024-11-19 14-42-35.pngWith the workaround such register takes the value 0x8000000:

Captura de pantalla de 2024-11-19 14-52-11.png