Hard fault after flashing.

[murrellr]

I have two projects that I imported from Keil uVision.  They are both STM32H7 projects and use the RTX5 RTOS2 OS.  One uses SEGGER j-Trace for debugging and the other ST-Link V2.  Both exhibit the following problem.  I have debugging configured to only flash the firmware if something changes.  After I make a change and build the firmware, when I start debugging the new firmware is flashed and then starts executing.  The software will generate a Hard Fault in the function “_fp_init”.  When I restart debugging the code works.  No flashing was done on the restart since nothing changed.  Keil uVision does not exhibit this problem.  Is this a known issue and is there a fix?

Microsoft Visual Studio 2022 Version 17.4.5

VisualGDB version 5.6R9 build 4816

STM32 STLink driver version 2.2.0.0 (latest)

SEGGER J-Trace Cortex-M PRO V2 driver version 3.0.0.0

 

[support]

Hi,

We are not aware of any known issues that would be causing it. One other customer mentioned that a recent update of a debugging tool (they didn’t specify which one) broke the logic for setting the initial stack pointer, so instead of pointing to the end of RAM, it would point to a random location. That said, we were never able to reproduce it on our side.

Either way, you can easily narrow it down by following the steps below:

1. Enable GDB logging.
2. Run a debugging session and ensure it crashes.
3. Locate the following lines in the log file:
   • target  remote :<port>
   • load
   • continue
   • any commands starting with ‘mon’ or ‘monitor’ that are forwarded straight to the GDB stub
4. Try running OpenOCD or J-Link manually, then run gdb manually and execute the same commands.
5. If the crash persists, try running “mon reset” (J-Link) or “mon reset halt” (OpenOCD) after the “load” command.
6. If it solves the problem, please try checking the value of sp (print (void *)$sp) before and after the ‘load’ command.

If you can confirm that running “load” with J-Link breaks the value of $sp, please feel free to report it to Segger support. They should be able to fix it on their side.

If the issue is caused by something else, you can use the “reset device after programming” checkbox in VisualGDB Project Properties -> Debug Settings. It will automatically insert the reset command after the load command. You can also customize the exact commands VisualGDB sends to gdb via the Advanced view on the same page.

[murrellr]

At the point of the crash, the stack pointer is correct.  Setting “Reset device: after programming” solves the problem.  Thank you for your assistance.

 

[Author]

Posts