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
