SysTick_Handler not called, STM32G070 (and 2024 release)

[XR.1]

SysTick_Handler() function isn't called in a project based upon the STM32G070CB mcu (48 terminals). However, with the STM32G070RB (64 terminals (NUCLEO-G070RB)) there aren't any issues.

I found this workaround from 3 years ago (almost 4):

https://community.st.com/t5/stm32cubemx-mcus/systick-handler-not-called-stm32g0b1/m-p/204754/highlight/true#M9378

This post goal is to help others naive programmers like me (that trusted in ST) in case they ever face the same problem:

// 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!
}

[Tesla DeLorean]

Why is the mapping wrong in the first place? Issue with BOOT0 floating or BOOTx option bytes?

[liaifat85]

Modify the SystemInit function in system_stm32g0xx.c to include the workaround

void SystemInit(void)
{
    #if defined(USER_VECT_TAB_ADDRESS)
    SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET; /* Vector Table Relocation */
    #else
    SCB->VTOR = FLASH_BASE;  // Ensure the vector table is set to the flash base
    #endif
}

[SofLit]

Hello,

I didn't understood the issue.

The system_stm32g0xx.c file is common to STM32G070CB  and STM32G070RB (NUCLEO board).

Why you did suppose it's working on STM32G070RB (Nucleo) but not on STM32G070CB? 

Just activate the definition:

#define USER_VECT_TAB_ADDRESS

VECT_TAB_BASE_ADDRESS is by default in the Flash (if you didn't activate VECT_TAB_SRAM definition):

/* #define VECT_TAB_SRAM */
#if defined(VECT_TAB_SRAM)
#define VECT_TAB_BASE_ADDRESS   SRAM_BASE       /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x200. */
#else
#define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x200. */
#endif /* VECT_TAB_SRAM */
#endif /* USER_VECT_TAB_ADDRESS */

[XR.1]

"Why is the mapping wrong in the first place? Issue with BOOT0 floating or BOOTx option bytes?"

I have no idea. This is a fresh project ("Hello world") created completely in the CubeIDE, featuring the STM32G070CB mcu (48 terminals); the Systick interrupt just didn't trigger until I applied the workaround.

When before I created a previous HelloWorld project for the NUCLEO-G070RB (64 terminals) there weren't any issues.

[XR.1]

Hi,

I didn't understood the issue.

A fresh HelloWorld project created with the CubeIDE for the STM32G070CB mcu don't trigger the SysTick interrupt.

The system_stm32g0xx.c file is common to STM32G070CB  and STM32G070RB (NUCLEO board).

It seems to be for me also.

Why you did suppose it's working on STM32G070RB (Nucleo) but not on STM32G070CB? 

I have no idea, but applying the workaround the SysTick interrupt triggers as expected and my LED is blinking now.

According with the Eclipse IDE the code isn't active:

The USER_VECT_TAB_ADDRESS constant is neither defined for the CB nor the RB variants. However, it worked as a charm for the RB one.

BTW, I'm using the 1.12.1 IDE release (from 20230420). Latest releases need a constant Internet connection and they ask me to login in order to do my job (Really, ST?), and I don't want to login (neither I want the IDE to be retrieving data from the Internet constantly).

For the sake of completness let me show you my schematic:

UM_6.3.1 says that SWCLK has a pull-down resistor, so I guess that, for debugging purposes, I don't need neither R100 nor R101:

Greetings!