Re: STM32H7x5 M4 Core Debug Issues

[Tomas V. <to...@us...>]

Hi Michael,

the fragment of OpenOCD log shows that CPU0 (M7 core) cannot be halted.
What is programmed in M7 startup?

On 11/08/2023 22:34, Banducci, Michael wrote:
>
> I started based on the example OpenOCD configs for the STM32H745 and 
> H747 and attempted to build a configuration file (see below).
>
> source [find interface/stlink-dap.cfg]
>
> transport select "dapdirect_swd"
>
> set DUAL_CORE 1
>
> source [find target/stm32h7x_dual_bank.cfg]
>
> targets stm32h7x.cpu1
>
> # Use connect_assert_srst here to be able to program
>
> # even when core is in sleep mode
>
> reset_config srst_only srst_nogate connect_assert_srst
>
The part of openocd.cfg up to here is +- standard.

The following part is a folklore added by zephyr project, which changes 
OpenOCD
startup behaviour and gdb attach. TBH I see no reason why they need it for.

> $_CHIPNAME.cpu0 configure -event gdb-attach {
>
>         echo "Debugger attaching: halting execution"
>
> gdb_breakpoint_override hard
>
> }
>
> $_CHIPNAME.cpu1 configure -event gdb-attach {
>
>         echo "Debugger attaching: halting execution"
>
> gdb_breakpoint_override hard
>
> }
>
> $_CHIPNAME.cpu0 configure -event gdb-detach {
>
>         echo "Debugger detaching: resuming execution"
>
>         resume
>
> }
>
> $_CHIPNAME.cpu1 configure -event gdb-detach {
>
>         echo "Debugger detaching: resuming execution"
>
>         resume
>
> }
>
> # Due to the use of connect_assert_srst, running gdb requires
>
> # to reset halt just after openocd init.
>
> rename init old_init
>
> proc init {} {
>
>         old_init
>
>         reset halt
>
> }
>
>

Could you please remove the second part of cfg, retry and
send us *FULL* debug log, not just a fragment?

Tom