HAL_Delay() causes infinite loop because systick not incrementing on stm32F4 and stm32L4 and stm32G4 boards due to bugs in system_stm32f4xx.c / system_stm32l4xx.c when making new default project running from flash

[beachmiles]

Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• The board (either ST RPN reference or your custom board).
• IDE or at least the compiler and its version.
  stm32f469VI and stm32f479AI custom board stm32cubeide IDE version 1.8.0 running on windows 10 and stm32cubemx 6.4.0

Describe the bug
A clear and concise description of what the bug is.
Creating a new stm32cubemx project for either of the stm32F4 chips using the stm32cube 1.26.0-1.26.2 drivers causes HAL_Delay to enter infinite loop because the systick timer to not increment and the default systick priority set to 15 instead of 0. Setting systick priority to 0 does not help.

How To Reproduce

1. Indicate the global behavior of your application project.
   Create a new stm32cube project for the stm32f469VI or stm32f479AI (suspect same issue on all stm32F4 chips) using stm32cube 1.26.0-1.26.2 drivers. Insert a HAL_Delay(5) in the while loop.

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).
   system_stm32f4xx.c

3. The use case that generates the problem.
   Trying to make a stm32cube project.

4. How we can reproduce the problem.
   Make a new stm32cube project for the stm32f469VI or stm32f479AI (suspect same issue on all stm32F4 chips)

Additional context
If you have a first analysis or patch correction, thank you to share your proposal.

Edit this section in system_stm32f4xx.c by doing the following 2 things. Full updated code snippet below
  1) uncommenting the "#define USER_VECT_TAB_ADDRESS" 
  2) adding the line #if defined(USER_VECT_TAB_ADDRESS)	

/* Note: Following vector table addresses must be defined in line with linker
         configuration. */
/*!< Uncomment the following line if you need to relocate the vector table
     anywhere in Flash or Sram, else the vector table is kept at the automatic
     remap of boot address selected */
#define USER_VECT_TAB_ADDRESS					//This needs to be uncommented out by default! -MILES

/*!< Uncomment the following line if you need to relocate your vector Table in
     Internal SRAM. */
/* #define VECT_TAB_SRAM */
#if defined(USER_VECT_TAB_ADDRESS)				// THIS LINE WAS PREVIOUSLY MISSING! -MILES

Screenshots
If applicable, add screenshots to help explain your problem.

[fpistm]

Hi @beachmiles,

Are you flashing using Serial? (Thanks bootloader)?
If yes then this issue is probably the same than this one: stm32duino/Arduino_Core_STM32#1653

By default the system_stm32f4xx.c template file does not restore the VTOR. In that case systick could not be incremented.
Moreover you should ensure clock config is properly reset to not use the PLL else if your system clock config try to reconfigure it then it will failed as PLL is already used.

[beachmiles]

I am flashing / debugging using a stlink v3 usb programmer.
I just updated to stm32cubeide 1.9 with this version of the firmware STM32Cube FW_F4 V1.27.0

Creating a new project still had this line commented out #define USER_VECT_TAB_ADDRESS
which still keeps the systick from incrementing. Uncommenting it fixes the problem.
/* Note: Following vector table addresses must be defined in line with linker
configuration. /
/!< Uncomment the following line if you need to relocate the vector table
anywhere in Flash or Sram, else the vector table is kept at the automatic
remap of boot address selected */
#define USER_VECT_TAB_ADDRESS

[vahidajalluian]

Dear @beachmiles
Your solution worked also for me with F429.

[RKOUSTM]

Hi @beachmiles,

Thank you your contribution. Actually, the point you raised has already been dealt and fixed internally. The fix will be made available in the frame of a future release.

Thank you once more for your contribution. We are looking forward to reading from you again.

With regards,

[wilgaced]

I am flashing / debugging using a stlink v3 usb programmer. I just updated to stm32cubeide 1.9 with this version of the firmware STM32Cube FW_F4 V1.27.0

Creating a new project still had this line commented out #define USER_VECT_TAB_ADDRESS which still keeps the systick from incrementing. Uncommenting it fixes the problem. /* Note: Following vector table addresses must be defined in line with linker configuration. / /!< Uncomment the following line if you need to relocate the vector table anywhere in Flash or Sram, else the vector table is kept at the automatic remap of boot address selected */ #define USER_VECT_TAB_ADDRESS

[wilgaced]

It Work for STM32L496