Problem Downloading to STM32H750B-DK

ksale.1 · ‎2026-02-05

Got a message: " Break at address "0x8001c50" with no debug information available, or outside of program code." and exited. Please help. If you need more info please advise.

ksale.1 · ‎2026-02-09

Successfully Recovered a Locked STM32H750B-DK (DK32H750B$AT1) - Step-by-Step Guide: After an intense debugging session that left my STM32H750B-DK board in a hard lockup (ARM core in lockup state), I managed to fully recover it. Since this process involved several non-obvious steps, I'm documenting my journey here to help others who might face a similar "bricked" board. My Board: STM32H750B-DK, Product ID DK32H750B$AT1 (MB1381-H750XB-B01). Summary of the Problem The board became completely unresponsive after a failed attempt to run code from external QSPI flash. The debugger reported a "lockup" state, and the chip would not execute any code or connect properly. The Step-by-Step Recovery Process 1. Initial Assessment and Tool Setup Tool Used: STM32CubeProgrammer (Version 2.21.0). Key Insight: Normal connection methods failed. The critical feature to use was "Connect Under Reset" to halt the core before any faulty code could run. 2. Critical Connection Method In STM32CubeProgrammer's ST-LINK configuration: Set "Reset Mode" to Hardware reset. The sequence is timing-sensitive: Physically press and hold the black NRST button on the board. In the software, click "Connect". Only release the NRST button after the connection is established and the "Target information" panel populates. 3. Performing a Clean Full Erase Once connected, I did not program a new file immediately. Went to the "Erasing & Programming" tab. Under "Automatic Mode", clicked the text link for Full chip erase. This erased both internal and potentially corrupted external flash, giving a clean slate. 4. Programming a Known-Good Test Firmware I created a simple LED blink project configured for internal flash (0x08000000) in STM32CubeIDE. Back in CubeProgrammer, I programmed this .elf file using the same "Connect Under Reset" method. Verification passed successfully. 5. Board-Specific Quirks and Verification LED Confusion: On my board revision, the user LED is the bicolor LD2. The pin PG3 controls its red segment. Don't be alarmed if LD4 (green) stays on—it's a power indicator. Power Port Matters: For the final autonomous boot test, powering the board via the dedicated CN15 (PWR) USB port provided a clean power-on reset. Using only the CN1 (STLK) port for this test could be unreliable. Success Test: After programming, a full power cycle (unplug USB, wait 10 seconds, replug into CN15) made the LED blink automatically, confirming a full recovery. Conclusion The key was using ST32CubeProgrammer's "Hardware reset" mode to gain access, followed by a full chip erase to remove any corrupted code. The board's power delivery via the correct USB port was also essential for testing standalone boot. I hope this log helps someone else recover their board. I will address the separate challenges of configuring the QSPI external flash for TouchGFX in a future post.

View solution in original post

Andrew Neil · ‎2026-02-05

Solved: Break at address "0x8000B2C" with no debug information

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

ksale.1 · ‎2026-02-05

Thank you Andrew. Here is mpre info may help troubleshooting:

Build:
19:55:43 **** Incremental Build of configuration Debug for project test0 ****
make -j12 all
arm-none-eabi-size test0.elf
text data bss dec hex filename
51612 208 11584 63404 f7ac test0.elf
Finished building: default.size.stdout

19:55:44 Build Finished. 0 errors, 0 warnings. (took 523ms)

Debug 1:

Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled

Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
-------------------------------------------------------------------
STM32CubeProgrammer v2.21.0
-------------------------------------------------------------------

Log output file: C:\Users\asus\AppData\Local\Temp\STM32CubeProgrammer_a13944.log
ST-LINK SN : 004D00213137510C33333639
ST-LINK FW : V3J16M9
Board : STM32H750B-DK
Voltage : 3.28V
SWD freq : 8000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size : 128 KBytes
Device type : MCU
Device CPU : Cortex-M7
BL Version : 0x90

Opening and parsing file: ST-LINK_GDB_server_a13944.srec

Memory Programming ...
File : ST-LINK_GDB_server_a13944.srec
Size : 438.46 KB
Address : 0x90000000

Erasing memory corresponding to segment 0:
Erasing external memory sectors [0 1]
Erasing memory corresponding to segment 1:
Erasing external memory sectors [16 17]
Download in Progress:

File download complete
Time elapsed during download operation: 00:00:02.733

Verifying...

Time elapsed during verifying operation: 00:00:02.078

Download verified successfully

Shutting down...
Exit.

Imen.D · ‎2026-02-09

Hello @ksale.1 ,

Try to erase the flash memory again with STM32CubeProgrammer and reprogram the device. Disconnect STM32CubeProgrammer from the target and debug again.

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

ksale.1 · ‎2026-02-09

Successfully Recovered a Locked STM32H750B-DK (DK32H750B$AT1) - Step-by-Step Guide: After an intense debugging session that left my STM32H750B-DK board in a hard lockup (ARM core in lockup state), I managed to fully recover it. Since this process involved several non-obvious steps, I'm documenting my journey here to help others who might face a similar "bricked" board. My Board: STM32H750B-DK, Product ID DK32H750B$AT1 (MB1381-H750XB-B01). Summary of the Problem The board became completely unresponsive after a failed attempt to run code from external QSPI flash. The debugger reported a "lockup" state, and the chip would not execute any code or connect properly. The Step-by-Step Recovery Process 1. Initial Assessment and Tool Setup Tool Used: STM32CubeProgrammer (Version 2.21.0). Key Insight: Normal connection methods failed. The critical feature to use was "Connect Under Reset" to halt the core before any faulty code could run. 2. Critical Connection Method In STM32CubeProgrammer's ST-LINK configuration: Set "Reset Mode" to Hardware reset. The sequence is timing-sensitive: Physically press and hold the black NRST button on the board. In the software, click "Connect". Only release the NRST button after the connection is established and the "Target information" panel populates. 3. Performing a Clean Full Erase Once connected, I did not program a new file immediately. Went to the "Erasing & Programming" tab. Under "Automatic Mode", clicked the text link for Full chip erase. This erased both internal and potentially corrupted external flash, giving a clean slate. 4. Programming a Known-Good Test Firmware I created a simple LED blink project configured for internal flash (0x08000000) in STM32CubeIDE. Back in CubeProgrammer, I programmed this .elf file using the same "Connect Under Reset" method. Verification passed successfully. 5. Board-Specific Quirks and Verification LED Confusion: On my board revision, the user LED is the bicolor LD2. The pin PG3 controls its red segment. Don't be alarmed if LD4 (green) stays on—it's a power indicator. Power Port Matters: For the final autonomous boot test, powering the board via the dedicated CN15 (PWR) USB port provided a clean power-on reset. Using only the CN1 (STLK) port for this test could be unreliable. Success Test: After programming, a full power cycle (unplug USB, wait 10 seconds, replug into CN15) made the LED blink automatically, confirming a full recovery. Conclusion The key was using ST32CubeProgrammer's "Hardware reset" mode to gain access, followed by a full chip erase to remove any corrupted code. The board's power delivery via the correct USB port was also essential for testing standalone boot. I hope this log helps someone else recover their board. I will address the separate challenges of configuring the QSPI external flash for TouchGFX in a future post.