Hi, we've a new custom-made electronics with two micros STM32H755. The first try connecting a ST-Link V3 via SWD was successful. Before flashing the two target files for CM7 and CM4 my colleague carry out a 'Full chip erase'.

[THerm.1]

After that, both files could be flashed. After a RESET we got the following error message:

Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication

 18:06:27 : UR connection mode is defined with the HWrst reset mode

 18:06:27 : ST-LINK SN : 004700433331510633323639

 18:06:27 : ST-LINK FW : V3J8M3B5S1

 18:06:27 : Board    : STLINK-V3SET

 18:06:27 : Voltage   : 3.37V

We try a lot around to get access to the micro controller again - without any results.

How can such an error occur?

Is there a way to get access?

Thanks in advance!

BR Tom

[Tesla DeLorean]

>>We try a lot around to get access to the micro controller again - without any results.

That really doesn't communicate any specificity, enumerate a little

Did you try the different "Access Port" settings to talk to specific cores?

See here

https://community.st.com/s/question/0D53W00002ERB74SAH/how-to-run-bootloader-on-bricked-stm32h7-discovery-kit

Do you have any secondary access methods, ie via BOOT0 pin and System Loader, USB, UART, per AN2606 ?

[THerm.1]

we use the CubeProgrammer for download the files. The settings for ST-Link configuration are as this:

SWD

8000kHz

Mode normal

Acc.port 0

Res.mode SW reset

speed reliable

shared disabled

After a new power up the target didn't respond - so we try to set the Reset mode to HW reset and the mode to Under reset - without success..

The setting for Access port wasn't change, still 0.

If I try to download the files on a Nucleo-Board it'll work. What are the differences between the controller on Nucleo-Boards and controllers from fab?

[Tesla DeLorean]

>>What are the differences between the controller on Nucleo-Boards and controllers from fab?

They have Unlicensed IP 'U' parts, and have a simple demo program loaded on them.

Your earlier inference is that it did connect properly, at least once. Did it, or has it never connected properly? If the latter, assume the design is not functional, and debug/review circuit

Check VCAP capacitors and voltages.

Check NRST level.

Other signs-of-life methods would be via the UARTs used by the ROM based system loader.

An erased part should go into the System Loader regardless of the BOOT0 pin state. The state is latched at power up, a reset is not the same thing, so once code is programmed the first time since blank, you will likely need to power cycle.

[THerm.1]

we are able to connect via ST-Link without problems until the files for CM4 and CM7 are downloaded.

After a power cycle there is no further access possible.

We only have an alternate communication access via CAN port, either at pins PB6/6 or pins PD0/1. BOOT0 is also accessible.

In some chats I've read that there should be the possibility to get access by pulling BOOT0 and NRST in a defined order H and L - but I guess this doesn't work in this case?

[Tesla DeLorean]

Well, the main headache with the dual-core and DISCO boards is the use of SMPS

If you get the SMPS/LDO setting messed up in the SystemClock_Config() you will basically brick the part. This means you then have to find the Rxxx pad next to BOOT0 pull-down and short it (so BOOT0 is HIGH), you then have to power cycle the board a couple of times until the System Loader fixes the situation, at which point you can reconnect, and then bulk/mass erase the part. Once recovered you fix your software so as not to do that again.

I managed to brick my early H747I-DISCO board very quickly, and did suggest back then that they needed a jumper or switch as soldering around 0402 resistor pads was a PITA.

If you have an issue with one of the CORES, the Access Port method is most appropriate.

[THerm.1]

Hi,

I've tried to get access after pulling BOOT0 to High - several times - but without any success.

It seems that the power setup regarding the LDO was wrong - in the current state of the controller one can measure around 0V at the VCAP pins while the LDO is sourced with 3.3V.

Would it be a solution to cut this 3.3V (or ignore it because the LDO seems to be disabled) and source a 1.2V supply directly to the VCAP pins?

BR Tom