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_]

Hello @Jocelyn RICARD 

Thank you for looking into this issue.

Option Byte info you asked for...

[_JJ_]

Okay, so to understand the situation further, I tried flashing a known working firmware code using JLink and ST-vLink, and both worked well using CubeProgrammer, but the STM32H743XI still refused to boot.

At one point, I saw MCU fussing about something along the lines of "RAMCode execution failure" or "RAMCode can not execute"; I don't remember the exact wording. I think this was in the IAR Workbench when I tried to deploy a known working FW code in order to see if I could start debugging again.

Any thoughts on what could be wrong? @Jocelyn RICARD @mƎALLEm

[mƎALLEm]

As you are able to connect to the device and to flash it , I propose this stage to unzip the attached file that contains a working option bytes. Try to upload them to your device. Please read this article on how to do it: Restoring the STM32 option bytes to their factory settings using STM32CubeProgrammer / section: 1.2 Option bytes factory reset (import option)

[_JJ_]

Thank you @mƎALLEm. I tried what you have suggested, CubeProgrammer has come back with the following error.

As per the article used, 'Under Reset' Mode with 'Hardware Reset' to perform this operation.

[mƎALLEm]

I think, and unfortunately for you, the flash is corrupted and couldn't be recovered. I suggest to replace the device.

[mjuels]

Have you tried setting Reset mode to "Hardware reset" in cubeProgrammer, when connecting with ST-link?

In your screenshots, it appears that you have tried "Software reset" and "Core reset", but please make sure to try "Hardware reset" as well - It has previously resolved a similar issue for me, when not being able to connect to the MCU.

[Pavel A.]

How the flash can become corrupted? Just curious: can this occur due to ESD or something like that?

Or could the CubeProgrammer someway write RDP2 in the option bytes?

[AScha.3]

So after some time...we here again:

https://community.st.com/t5/stm32-mcus-products/how-to-recover-a-bricked-flash-stm32h743xi-after-accidentally/m-p/838719/highlight/true#M285658

But i also try sometimes to repair or recover some "problem" cpu's at work , but just from experience:

 only 1...2 out of 10 successful.  Therefore more of an activity driven by curiosity .

But i always try to find out the reason for the defective state and reduce (if EMI) or avoid it (if circuit can be improved) for the next/future design or revision.

Then its not just wasted time, something learned or improved as the result.

[Pavel A.]

@AScha.3 So have you seen similar "corruption" of H743 often? Have you figured out why it (mis)happened?

[AScha.3]

@Pavel A.  Well, in production or testing you can see everything, you could imagine;

mostly curious defects by ESD,  chips can get every state, from dead as a doornail to almost all working.

Or even can really see the chip....blown up. (Possibly very creative dude connected mains voltage on 5V rail).

Also (very seldom) something broke the flash/update , giving some possible strange settings, or trigger RDP protection. But these usually ok after some "unprotect", set option, restart...again.