Solved
Problem Downloading to STM32H750B-DK
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.
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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.