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,

[RKOUSTM]

ST Internal Reference: 116475

[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

[beachmiles]

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

It looks like this is still "In Progress" as of 1/17/2023, it's unfortunate this is the case as I suspect many people across the world will have ripped many hairs out from this bug the past 10+ months.
https://github.com/orgs/STMicroelectronics/projects/2#card-79208657

[beachmiles]

Verified this is still a bug in the stm32L496ZG-P on the Nucleo board.
I'm using stm32cubeide 1.11.2 using stm32cube firmware L4 V1.17.2
Luckily the same fix for the stm32f4 works on the stm32l4.
Can't believe a major bug like this could persist for close to a year spanning at least the stm32F4 and stm32L4 lines.

[beachmiles]

Dear @fpistm @ALABSTM @RKOUSTM , I verified this is still a bug when creating a new project for a stm32L4 (NUCLEO-L496ZG-P) with the original fix still working except the the 2nd step is no longer needed as the #if defined(USER_VECT_TAB_ADDRESS) line is now in both of the latest system_stm32f4xx.c and system_stm32l4xx.c files.
So now I only had to uncomment this line to get the system from freezing on initialization due to a frozen systick.
#define USER_VECT_TAB_ADDRESS

So it looks like ST needs to update these files with this one line fix unless there is a better/different fix in the works. Thanks!
https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c

https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Drivers/CMSIS/Device/ST/STM32L4xx/Source/Templates/system_stm32l4xx.c

[vahidajalluian]

I didn't like to say this like, out of morality, but as it has wasted a lot of time from developers who trusted developers of cube MicroXplorer, it is a pity that til now there had been no workaround for a line to be uncommented, and a line to be added.

[stnigg]

Currently the lates version for L4 seems to be 1.17.2. The issue is present in this library at least for the STM32L431.
I must say it is disapointing to find out that this is known for this long and is still wasting my time.

[fpistm]

Hi @beachmiles
I'm aware of this and fixed this in https://github.com/stm32duino/Arduino_Core_STM32.
From my point of view, VTOR should be unconditionally set but I'm not working on Cube, I'm only use it for stm32duino core.
An internal bugtracker has been submitted and so I hope it will be resolved by concerned team.

[mrpj100]

Can confirm this also affected me on an STM32L432,

[timonburkard]

Issue also exists on STM32L433CBT6 using STM32CubeIDE 1.12.1, STM32CubeMX version 6.8.1

[Ashish-Jog]

Issue still exists on STM32H743IIT6., CubeIDE Version :- 1.11.2

[crnorris]

Issue exists with a fresh project built with STM32CubeIDE 1.13.2, STM32CubeMX 6.9.2, targeting STM32G030J6M6.

[smelting]

Issue persistent with STM32G491RET6, STM32CubeIDE 1.11.0, STM32Cube FW_G4 V1.5.2. Wasted my time checking my board design/soldering because a blank project with a blink and delay was broken.

[beachmiles]

@fpistm @ALABSTM @RKOUSTM We are now close to this being a 2 year old open bug that can be fixed by 1 line!!! How many headaches this has caused during that time is sad to think about. Can we please fix this???

[YocoZuna]

Issue persistent with STM32L051R8T6

[DAflamingFOX]

Can confirm this issue is still persistent on STM32G431KBU6, STM32CubeIDE 1.16.0 & STM32Cube FW_G4 V1.6.0

The solution posted here still works...

It's been over 2 years, this is a joke right?

[augustas534]

Issue still exists with a fresh project built with STM32CubeIDE 1.16.0, STM32Cube FW_U5 V1.6.0, targeting STM32U545RETxQ.

Following fix does not work on this processor...