How to run bootloader on bricked STM32H7 Discovery kit?

[Clem1]

I have recently bricked my STM32H7 discovery kit by trying to select the M4-only boot option, but I am no longer able to connect the debugger. I have had a similar problem with the Arduino Giga board but I managed to "unbrick" it by running a bootloader and pressing the "BOOT0" button. According to the STM32H7 manual, the bootloader should is loaded by a combination of a high BOOT0 and the status of certain option bits (over which I obviously do not have any control any longer). For the Discovery board, I have soldered in a button that shorts out R192 and which I then press while powering up / resetting, but neither the STM32CubeProgrammer nor the ST flash loader demo is able to connect through the UART (via the in-built ST link programmer). Do you have any advice on how to start the bootloader? Surely there must be a way to save that board? Do I need to use a different USART port?

Many thanks,

Clem

[Clem1 · Accepted solution]

Hi all. I have found the answer myself. Apparently, the SWD channel needed to be changed to channel 3, which accesses the M4 core directly, see STM32H747I-DISCO bricked after unchecking ECM7 bit on STM32CubeProgrammer

[Tesla DeLorean]

+1 Multiple cores, connecting to the functional core

The BOOT0 HIGH and power cycling trick is primarily for the unbricking in the LDO/SMPS cases

[Clem1]

Thank you for clarifying the point about the BOOT0 input. I have been able to unbrick the platform and run a simple blinky-blink demo (35) Getting started with STM32 Dual Core CPUs || STM32H745 || How to DEBUG - YouTube . Despite the simplicity I could only make this work while debugging, once I disconnected from the debug session the MCU would do nothing after a reset. It was as if the debugger transferred the code into RAM and did not program the flash memory. I will raise this question separately since it is not really related to the bricking.

[Tesla DeLorean]

Make sure BOOT0 is pulled down in the normal case.

Usually code does run, watch for places where it gets hung up in while(1) loops of silent death.. ie Error_Handler(), HardFault_Handler(), etc

Make sure both cores have their own routines which output diagnostic/telemetry data that's actionable.

Minimally have some GPIO which can be brought up in the respective Reset_Handlers, and toggled, adjusted as a means of determining functionality absent the debugger.