How do I regain ST-Link connectivity with Nucleo-H745ZI-Q with BOOT_CM7 = 0 and BOOT_CM4 = 1

[Yoichi Shinoda]

While fiddling with H745 board to investigate how dual core works, after modifying option byte to BOOT_CM7 = 0 and BOOT_CM4, STM32CubeProgrammer (nor STLINK-gdbserver) refuses to connect to the board with "Error: No STM32 target found". The ST-Link itself is okay. Here is a log from the programmer.

22:31:39 : ST-LINK SN : 002F003D3137510E39383538
22:31:39 : ST-LINK FW : V3J5M2
22:31:39 : Voltage : 3.30V
22:31:39 : No STM32 target found!
22:31:39 : ST-LINK SN : 002F003D3137510E39383538
22:31:39 : ST-LINK FW : V3J5M2
22:31:39 : Voltage : 3.30V
22:31:39 : Error: No STM32 target found!

How do I regain access to the board?

[Uwe Bonnes]

Did you try to connect under reset (Reset Mode -> Hardware reset)

[Yoichi Shinoda]

How does the "connect under reset" supposed to work?

I configured the ST-LINK as follows and pressed "Connect" while reset button is held down, but it gives the same error, regardless of the reset button state.

[TDK]

The BOOT_CM7 bit shouldn't have an effect on st-link being able to connect. Reboot. Double check that everything is connected and powered correctly.

[Yoichi Shinoda]

Thanks for the suggestion.

Here I have two NUCLEO-H745ZI-Q boards, from the same order, and one of these (call it BOARD1) can be connected:

12:22:35 : ST-LINK SN : 0044002D3137511239383538
12:22:35 : ST-LINK FW : V3J5M2
12:22:35 : Voltage : 3.27V
12:22:35 : SWD freq : 24000 KHz
12:22:35 : Connect mode: Normal
12:22:35 : Reset mode : Software reset
12:22:36 : Device ID : 0x450
12:22:36 : UPLOADING OPTION BYTES DATA ...
12:22:36 : Bank : 0x00
12:22:36 : Address : 0x5200201c
12:22:36 : Size : 308 Bytes
12:22:36 : UPLOADING ...
12:22:36 : Size : 1024 Bytes
12:22:36 : Address : 0x8000000
12:22:36 : Read progress:
12:22:36 : Data read successfully
12:22:36 : Time elapsed during the read operation is: 00:00:00.001

However, when switching board to the problematic one (call it BOARD2), then it fails to find a target.

This started to happen when I tried to write BOOT_CM7 = 0 and BOOT_CM4 = 1 instead of previously working BOOT_CM7 = 1 and BOOT_CM4 = 0 pair. This write to OB in fact failed with a message from the programmer (something like "Option byte write failed").

If the BOOT_CM7/BOOT_CM4 bit actually has nothing to do with the connectivity problem, then I have to find why the target is not responding on BOARD2 and how to recover it.

Thoughts?

Btw, physical connection is just a USB cable for both BOARD1 and BOARD2. Please note that ST-LINK itself is responding, so the problem lies behind ST-LINK.

[JJOSE.0]

This procedure worked for me by bridging the BOOT0 and +3.3V pin and erasing memory with STM32 ST-LINK Utility

[Yoichi Shinoda]

Thanks for your reply.

Was the board in BOOT_CM7 = 0 and BOOT_CM4 = 1, and you were using USB DFU? The problematic board here doesn't even go into DFU (not detectable with STM32CubeProgrammer and one other DFU flashing utility).

[Yoichi Shinoda]

My theory about this issue is

1. Boot loader for this device is only written/configured to run with CM7.

2. Since BOOT_*** gates clock supplies to corresponding CPU, disabling CM7 also disables the boot loader facility completely.

3. STM32CubeProgrammer only talks to CPU0, the CM7 which is not clocked, it will fail to detect the CPU0 hence the device.

I think we really need to hear from ST, as this is a very serious situation that hard bricks the entire device, which has never been the case with existing ST MCUs with builtin boot loader.

[TDK]

It seemed like such a big oversight that having BOOT_CM7=0 would cause the ST-Link to be unable to connect AT ALL that I tested it with one of my H7 boards. Sure enough, after setting BOOT_CM7=1, can no longer connect to it. Not even under reset. Jokes on me. It's not like ST to have a hardware bug like that.

I can't easily connect BOOT0 to 3V3 to start the bootloader but I will try that eventually.

@Imen DAHMEN​ Any chance we could get this looked at? Seems like a note in the RM mentioning this behavior would be prudent given that it semi-bricks the device. Or even disallowing users from setting BOOT_CM7=1 in the STM32CubeProgrammer given that it irreversibly prevents it from connecting.

[Houda GHABRI · Accepted solution]

Hi @Yoichi Shinoda​ ,

Sorry for late response.

Issue is confirmed and it will be fixed in next STM32CubeProgrammer release scheduled for june.

Meanwhile I sent you a patch fixing this issue , you can now reactivate the CM7 core using CM4 (access port 3) , please test and tell me if it is OK.

Anyone who is facing same issue I can share with him the patch.

best regards,

Houda