NUCLEO-H755ZI-Q deadlock

[RTira.1]

We have been testing a NUCLEO-H755ZI-Q by creating example projects using STM32CubeMx, which work fine. However, given the microcontroller is dual core, we felt the need to investigate the different boot options it offers in order to make it compatible with our final application and here is where the problem comes.

As explained in the reference manual, the two cores can boot alone or at the same time according to the option bytes shown in the table below:

In the example project created by default with STM32CubeMx, both cores (M7 and M4) are booting in a way where the M7 core runs first, wait for the M4 to enter the stop mode, configures the system clock and all the necessary things, and finally releases a hardware semaphore. On the other hand, before going to the stop mode, the M4 activates the notification for the semaphore, so when it receives the notification from the M7 it wakes up from the stop mode, and the rest of the code starts working as usual.

 

In our final application, the M4 core should be the master in charge of the system initialization, while the M7 core will adopt the role of slave, whose booting will be controlled by the master. Thus (by mistake) having downloaded the default program to the microcontroller, we proceeded to disable the booting of the M7 using the STM32CubeProgrammer software as shown in the image below. 

After that, we have not been able to reconnect with the microcontroller (the debug probe can't connect to the target any more); which is reasonable because the M7 is halted by user option bytes, and the M4 is in stop mode by the example code loaded into the memory.

Therefore, is there any method with which we can recover communication with the board?

We have tried to boot from the bootloader with the procedure explained in the development kit user manual (using BOOT0 pin), but without success.

We think this is also reasonable because, from the reference manual, once the BOOT0 pin is driven high, the bootloader should run on the M7 core but, in our case, this core is halted by user option bytes.

Thanks!

[Tesla DeLorean]

Don't know.

Do however watch that complete power removal is require to properly reset.

The BOOT0 mechanics are good for LDO/SMPS bricking, not sure it remediates other problems related to OB latched at power-up.

[TDK]

Use access port 3 to connect to the chip, which accesses the M4 core, rather than access port 0 which accesses the M7 core.

[FBL]

Hello @RTira.1​,

I was wondering if your board is unlocked. If not, as mentioned by @TDK​, you can access to the debug in the CM4 via internal AHB-AP bus. You can find details in section 63.4.2 Access ports of RM0399.