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!

 

[_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.

[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.

[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. 

[mƎALLEm]

Hello,

Did you try the power down mode in CubeProgrammer?

 

[_JJ_]

@mƎALLEm yes, the flash content was all 0xFFFF.

But I think the system is still bricked.

PS: This is using IAR & JLink. I could not flash.

[_JJ_]

I was going through the very first response by @Andrew Neil and found https://community.st.com/t5/stm32-mcus-security/unable-to-erase-stm32h743-device-how-to-recover-the-device/m-p/115706 with no accepted answer.

which is the same problem I am currently facing.

[_JJ_]

@Jocelyn RICARD, any suggestions?

[Jocelyn RICARD]

Hello @_JJ_ ,

Could you please provide the output of command

STM32_Programmer_Cli.exe -c port=SWD mode=UR -ob displ

Thank you

Best regards

Jocelyn

 

[_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.

[_JJ_]

@mjuels, I think I have tried that too, but it's been quite a while, so I will try what you've suggested and share the outcome.

@Pavel A., this is not the first time a ST32H743 has been bricked for me, as I have mentioned, usually it's easy to recover from this situation using one of the suggestions or using the 'SEGGER STM32 Unlock' utility. In my case, this usually happens when trying to flash a FW using a SEGGER JLink device, and the RESET line is pulled by accident.

@AScha.3 yes, your feeling was right in my case, unfortunately. I believe in trying until the last hope dies. In my experience with STM32H743, it has been easy to recover in most cases. Will dig deeper in case I can find what exactly caused this, will share the knowledge if I find something concrete.

 

Thank you guys for coming up with different options and helping me in this matter, much appreciated.

 

PS: @AScha.3 & @Pavel A. in my case, ESD can not be the root cause, as I use an ESD (yes, grounded!) mat and wrist band while handling the device, the only thing making contact with the board was JTAG and UART cables.

[AScha.3]

@_JJ_ 

So in this case, sure its not damaged by ESD , last chance :

Before you give up - maybe last action:  to reset the pcrop...whatever its now....

 

Connect to cpu , maybe using hot-plug or hardware reset, whatever works better, or at all.

So try set : 

on L4xx: Uncheck PCROP_RDP + set RDP to level1 (protected) , 01  (or whatever, but NOT 0xCC !);

on H7xx: Check DMEP1 + 2 ,  + set RDP to level1 (protected) , 01  (or whatever, but NOT 0xCC !);

 

then restart/ power cycle

and then : 

on L4xx: set Uncheck PCROP_RDP + RDP to 0xAA , to do regression;

on H7xx: Check DMEP1 + 2 , + RDP to 0xAA , to do regression;

L4:

H7: 

 

then apply....

 

 

restart/ power cycle....and we know.

ed...for 'H7.

[_JJ_]

Yes, @AScha.3, you read my mind. I did read that in the manual, and definitely want to give it a try. Thanks for bringing it up.