Cube Programmer crashing dual core microcontroller when using STLink-V3SET

[DFay.2]

Hey folks,

I'm trying to load firmware onto an STM32H755BI Microcontroller (Dual M4-M7 core). When loading the M7 core with new firmware, I have no issues. However, when I load the M4 core the microcontroller crashes badly. I've tried loading via CubeProgrammer and through a gdb-multiarch instance attached to stlink-gdbserver, but both have the same result: both the M4 and M7 cores crash, and cannot be reset through `run`, `mon reset`, or `mon hardware_reset` commands.

Here is the output when I try loading with GDB:

```

(gdb) load

Loading section .isr_vector, size 0x298 lma 0x8100000

Loading section .text, size 0x7ce0 lma 0x8100298

Loading section .rodata, size 0x9c lma 0x8107f78

Loading section .ARM, size 0x8 lma 0x8108014

Loading section .init_array, size 0x4 lma 0x810801c

Loading section .fini_array, size 0x4 lma 0x8108020

Loading section .data, size 0x20 lma 0x8108024

Loading section .RxDecripSection, size 0x60 lma 0x8108044

Loading section .TxDecripSection, size 0x60 lma 0x81080a4

Start address 0x810170c, load size 33028

Transfer rate: 26 KB/sec, 1738 bytes/write.

(gdb) c

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

0xa05f0000 in ?? ()

```

With CubeProgrammer, the processor shows that it is in the "Halt" state after completing a load. If I try to start running, a popup window says "Error : Unable to run application".

Note that in both instances, the firmware load succeeds. However, I am unable to connect to the microcontroller unless I power cycle it.

I've also tried loading firmware using the Segger J-Link, and it is able to load the M4 core without any notable issues.

Any ideas as to what the issue is here, or if it is fixable on my end? As far as I can tell this is a STLink-V3 firmware problem.

[Tesla DeLorean]

Retopic'd for better/appropriate visibility.

The H7 is one of the processors that needs to be power cycled to reload option bytes, and boot states, and simple reset won't do this.

Similarly if there are expectations on LDO vs SMPS, and VOS settings.

Watch clocking and wait states.

What data patterns would cause a branch off into 0xA05F0000 ?

Issues with GDB, ST-LINK drivers, DLLs, firmware and STM32 Cube Programmer are rather poorly QA Tested, certainly broad scope there, but still a lot of stuff I wouldn't be allowed to released.

[DFay.2]

That's interesting. The JLink probe appears to throw the chip into a constant reset state after loading firmware onto the M4 - continuing out of this has the system run normally from start on both cores, even when execution is shown to be halted in GDB. Is there a way to call for this state on the ST-Link side?

I have no idea what would cause it to branch into `0xA05F0000`, as that's a reserved region of memory. The code I'm loading is 99% vanilla code generated by CubeMX, plus some simple pin toggling and HAL_Delay() calls in the main() loop.

I've also tested the loading behavior on a BlackMagicProbe, and it also hits this same set of issues that I'm seeing on the STLink-V3

[mwb]

Hi @Community member​ . Have you been able to identify the root cause and fix the issue?

[DFay.2]

Unfortunately no. My hunch is that the STLink-V3 does not reset some multi-core debug registers that the JLink does, or that the STLink doesn't use proper delays. I think the STLink-V3 needs a firmware patch to fix the issue.