How to recover a bricked Flash STM32H743XI after accidentally pulled the RESET line while flashing a FW

[_JJ_]

Hello Community

For some reason, my post from yesterday did not go through and was marked as spam. I'm not interested in moaning about it right now, as I have managed to brick my custom board, designed with STM32H743XI and would be more interested in finding a way to unbrick it.

Before jumping to any conclusion, please read the post as it contains crucial info and things I have already tried, which you would like to suggest.

Some info about my setup, as mentioned earlier, it's a custom board with BOOT0 and RESET pins exposed using a switch, and there is a JTAG interface for debugging purposes, along with a SEGGER JLink. The way I managed to brick is that I accidentally pulled the RESET line while flashing a FW using Jlink, and since then, it seems memory is in locked mode, and neither Jlink nor ST-vLink is helpful in the rescue mission.

Things I have already tried and did not work... maybe I am missing something.

1. I have been in this situation before, and was able to recover from it using JLInk STM32 Unlock tool, but surprisingly, this time, that too is unable to reset the Option Bytes and fails to recover.
2. Tried using the JLink Commander tool too, which was also not able to erase the memory, returned error code -5.
3. Tried to use STM32CubeProgrammer with Jlink, and tried to gain control of the MCU in reset mode, and tried to mass erase and reset option bytes, but it did not work.
4. Tried to use STM32CubeProgrammer with Jlink, and tried to gain control of the MCU in reset mode using DFU by pulling BOOT0, then RESET and releasing RESET while still holding BOOT0 high and later releasing it, but that too failed to mass erase and reset option bytes.
5. Steps 3 and 4 were also repeated using ST-vLink, but failed in the same manner.

Right now, it feels like I am running out of options to recover from this situation. If someone can point me to any other solution or point out a mistake in what I have tried out so far, I would really appreciate the help!

PS: My other post on the same point, which is marked down as spam, had all the screenshots for reference to what I have tried so far, and I will try to upload them here if I can.

[_JJ_]

Merged threads.

Hello

I have been stuck with a bricked STM32H743XI. I was flashing a new FW and accidentally hit reset at the same time, and since then, I have been unable to talk to the MCU. I use Segger JLink for programming the device; it's a custom board built around STM32H743XI.

I have been stuck in the same issue in past, but back then, Segger Jlink STM32 Unlock utility came to the rescue, and the MCU was back on track. But this time, it seems not to be able to set option bytes, hence I can not flash the FW, and my board is unusable at this moment.

Also, tried using JLink Commander, if it can erase MCU banks, but did not help either.

As this didn't turn out to be quite helpful this time, I turned to different available options. First, tried using ST-vLink and ST Cube Programmer, but that too didn't work out well. I was able to connect to MCU but was not able to perform anything using the tool. Every single time I connected, a "Read Memory Error" popped up.

Option byte using ST-vLink:

In one of the forums, someone mentioned updating FW of ST-vLink to get over the issue, not sure how it would have helped, but was desperately looking for a solution, so I tried it, but it did not help either.

Tried ST Cube Programmer with Jlink as well, but same result. I guess no surprise there, if ST-vLink was not able to talk to ST MCU, how a 3rd party could...

Option byte using Segger JLink:

Any sort of help to resolve this issue would be really appreciated.

Thanks in adavance!

[Andrew Neil]

https://community.st.com/t5/stm32-mcus/how-can-i-recover-my-stm32h7-stm32h7rs-board-after-facing-a/ta-p/49579

https://community.st.com/t5/forums/searchpage/tab/message?advanced=false&allow_punctuation=false&q=recover%20stm32h7

[AScha.3]

Hi,

so clear , fast and simple solution:

- put a new H743 on your board

- remove the reset   switch

(anyway you should never need it: if your program has a lot of problems/errors , you still in debug state and have the debug probe connected, that does reset, if needed; and if program is not crashing and "ready to use" , you need no hardware for reset at any time. )

[_JJ_]

@AScha.3, thanks for taking the time to respond, but it's not the solution I'm looking for.

I believe in solving problems, not replacing them. 

[_JJ_]

This could be used as an extension to How to recover a bricked STM32H743XI?.

This is my original question and was marked as SPAM by the system, so I had to post another question(the linked question) to find a solution.

Not sure if I can mark this as a duplicate or something.

[mƎALLEm]

Hello,

Did you try the power down mode in CubeProgrammer?

[AScha.3]

@_JJ_  ... i do also >solving problems, not replacing them.

But here : 8$ cpu in unknown state, possibly set to rdp2 , by strange action on flash process.

->  if your time is cheap or free, can play around with this some hours; maybe lucky and can be recovered - or not.

Then have to replace anyway.

So the question is : if no connect/under reset or bootloader start (boot0) possible - its "dead" for any connection/tool.

How much time to invest in this - or replace cpu and remove the "killswitch" reset button ?

[Andrew Neil]

---

@_JJ_ wrote:

Not sure if I can mark this as a duplicate or something.

---

You can use 'Report Inappropriate Content':

Then choose 'Something else' as the reason:

and provide details - including a link to the other post:

A moderator will then be able to delete or merge, as appropriate.

---

A moderator has now merged the threads.

[_JJ_]

@mƎALLEm not yet. I have tried to grab hold of the MCU under RESET.

Okay, so back to your suggestion, I have trialled it just now.

This is what I followed...

1. Kept hold of the BOOT0 button, so it stays high.
2. Pulled the RESET line.
3. CubeProgrammer was setup as you suggested
4. 

5. Did mass erase while BOOT0 was pulled high, it was successful erase and when Memory was read back it was all 0xffffffff

But still no luck, do you think I may be missing something here..? 

UPDATE: Just connected SEGGER JLink and connected normally, even though ST-vLink said it was successful erasing memory, JLink data read back shows ST-vLink was not successful.

JLink Commander Output if it helps...