HardFault_Handler() after MxCube project regeneration by using ST Example project

[bureau]

Hello

Currently I am working with NUCLEO-N657X0-Q by using 

• STM32CubeIDE_2.1.1 
• STM32Cube_FW_N6_V1.3.0
• MxCube v6.17.0

Trying to investigate and migrate CDC ACM feature in to the my own project. As basis I am using Ux_Device_CDC_ACM Example provided by ST as reference.

It was discovered that Ux_Device_CDC_ACM example would not work properly after MxCube project regeneration -- it goes to the HardFault_Handler() at some point (not defined currently at which point)

The investigation showed that the issue is connected with the Optimization level (MxCube updated STM32CubeIDE project files) just only for the one single source file: "stm32n6xx_hal_rcc_ex.c". If optimization level is set to "-O0" for the mentioned file -- HardFault_Handler() is observed. By changing it to the "-O3" -- the application works successfully.

Could you please explain this "hidden" dependency, and what is the reason of this?

[Pavel A.]

>  it goes to the HardFault_Handler() at some point (not defined currently at which point)

Can you tell more how to reproduce this? What does the program do when the HardFault occurs? Do you have the register values? Change in the optimization level in one .c file can just move code & data of other modules to other addresses, it may not be the root cause at all.

[bureau]

The simplest way to reproduce it:

1. Open (import) the Ux_Device_CDC_ACM example into the STM32CubeIDE
   The example project could be found in  the folder:
   STM32Cube_FW_N6_V1.3.0\Projects\NUCLEO-N657X0-Q\Applications\USBX\Ux_Device_CDC_ACM
2. In the project Explorer find the file: stm32n6xx_hal_rcc_ex.c
   Drivers/STM32N6xx_HAL_Driver/stm32n6xx_hal_rcc_ex.c
3. Press Properties on the file
   
4. Go to the C/C++ Build --> Settings -- > Optimization
5. Observe that it was selected O3 (when for the other files it is set O0)
6. Change Optimization level for the stm32n6xx_hal_rcc_ex.c to O0
7. Compile --> Debug/Run

 

[Saket_Om]

Hello @bureau 

Since -O0 generally produces larger stack frames than -O3, the HardFault may be caused by an insufficient stack allocation rather than by the RCC source file itself. For this reason, we recommend increasing the stack size as a first diagnostic step.

[Andrew Neil]

Debugging Cortex-M Hard Faults:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/tac-p/708193/highlight/true#M51