openocd-user Mailing List for OpenOCD - Open On-Chip Debugger

Hi,

I'm the maintainer of fpgacapzero (or fcapz)
https://github.com/lcapossio/fpgacapZero/ an open-source cross-vendor FPGA
JTAG debug cores, including logic analizer (ELA), embedded I/O (EIO), JTAG
to AXI bridge, etc.

I have AMD/Xilinx hw_server backend working and have implemented OpenOCD
basic functionality but I'm not able to test it. There's Python API and
also QT GUI in progress. My goal is to make it the most complete and
versatile FPGA debugging project.

I'm looking for volunteers/debuggers/devs to help if they have different
cables that work with OpenOCD so we can finally have down to the fabric
democratized FPGA-debugging!!!

Cheers,
Leo

Hi 赵俊涛,

in current OpenOCD code cJTAG is only supported by FTDI adapters.
J-Link with cJTAG is still not supported.

Regards,
Antonio

On Tue, 17 Mar 2026, 10:24 赵俊涛, <jun...@re...> wrote:

> Hi OpenOCD users and developers,
>
>
>
> I am trying to debug a RISC-V board using a SEGGER J-Link as the debug
> adapter with the *cJTAG *interface. However, I am encountering connection
> errors.
>
> Could you please clarify if OpenOCD supports cJTAG when using the J-Link
> adapter?
>
>
>
> Below are the error logs and my configuration file.
>
>
>
> *OpenOCD Log:*
>
> xPack Open On-Chip Debugger 0.12.0+dev-02228-ge5888bda3-dirty
> (2025-10-04-22:44)
>
> Licensed under GNU GPL v2
>
> For bug reports, read
>
>         http://openocd.org/doc/doxygen/bugs.html
>
> Info : J-Link V9 compiled May  7 2021 16:26:12
>
> Info : Hardware version: 9.40
>
> Info : VTarget = 1.796 V
>
> Info : clock speed 4000 kHz
>
> Error: JTAG scan chain interrogation failed: all zeroes
>
> Error: Check JTAG interface, timings, target power, etc.
>
> Error: Trying to use configured scan chain anyway...
>
> Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
>
> Warn : Bypassing JTAG setup events due to errors
>
> Error: dtmcontrol is 0. Check JTAG connectivity/board power.
>
> Error: [riscv.cpu] Examination failed
>
> Warn : target riscv.cpu examination failed
>
> Info : [riscv.cpu] starting gdb server on 3333
>
> Info : Listening on port 3333 for gdb connections
>
> Info : Listening on port 6666 for tcl connections
>
> Info : Listening on port 4444 for telnet connections
>
>
>
>
>
> *OpenOCD Configuration (.cfg):*
>
>
> source [find interface/jlink.cfg]
>
> adapter speed 4000
>
> transport select swd
>
> bindto 0.0.0.0
>
>
>
> if { [info exists CHIPNAME] } {
>
>     set _CHIPNAME $CHIPNAME
>
> } else {
>
>     set _CHIPNAME riscv
>
> }
>
>
>
> if { [info exists CPU_JTAG_TAPID] } {
>
>     set _CPU_JTAG_TAPID $CPU_JTAG_TAPID
>
> } else {
>
>     set _CPU_JTAG_TAPID 0x162818f3
>
> }
>
>
>
> if { [info exists ENDIAN] } {
>
>     set _ENDIAN $ENDIAN
>
> } else {
>
>     set _ENDIAN little
>
> }
>
>
>
> set _CPU_TAPID $_CPU_JTAG_TAPID
>
> jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id $_CPU_TAPID
>
>
>
> set _TARGETNAME $_CHIPNAME.cpu
>
> target create $_TARGETNAME riscv -endian $_ENDIAN -chain-position
> $_TARGETNAME
>
>
> Any guidance on whether cJTAG is supported or if there is a specific
> configuration required for this setup would be greatly appreciated.
>
>
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user
>

Hi OpenOCD users and developers,

I am trying to debug a RISC-V board using a SEGGER J-Link as the debug adapter with the cJTAG interface. However, I am encountering connection errors.
Could you please clarify if OpenOCD supports cJTAG when using the J-Link adapter?

Below are the error logs and my configuration file.

OpenOCD Log:

xPack Open On-Chip Debugger 0.12.0+dev-02228-ge5888bda3-dirty (2025-10-04-22:44)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : J-Link V9 compiled May  7 2021 16:26:12
Info : Hardware version: 9.40
Info : VTarget = 1.796 V
Info : clock speed 4000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Error: [riscv.cpu] Examination failed
Warn : target riscv.cpu examination failed
Info : [riscv.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections


OpenOCD Configuration (.cfg):

source [find interface/jlink.cfg]
adapter speed 4000
transport select swd
bindto 0.0.0.0

if { [info exists CHIPNAME] } {
    set _CHIPNAME $CHIPNAME
} else {
    set _CHIPNAME riscv
}

if { [info exists CPU_JTAG_TAPID] } {
    set _CPU_JTAG_TAPID $CPU_JTAG_TAPID
} else {
    set _CPU_JTAG_TAPID 0x162818f3
}

if { [info exists ENDIAN] } {
    set _ENDIAN $ENDIAN
} else {
    set _ENDIAN little
}

set _CPU_TAPID $_CPU_JTAG_TAPID
jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id $_CPU_TAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -endian $_ENDIAN -chain-position $_TARGETNAME

Any guidance on whether cJTAG is supported or if there is a specific configuration required for this setup would be greatly appreciated.

/usr/local/bin/openocd -s /path/to/support -s /path/to/scripts -c 'source
[find interface/cmsis-dap.cfg]' -c 'transport select swd' -c 'source [find
target/nordic/nrf53.cfg]' -c 'init' -c 'targets' -c 'nrf53.cpuapp halt'


در تاریخ سه‌شنبه ۲۴ فوریه ۲۰۲۶، ۲۳:۲۹ Masih Show truth <
mas...@gm...> نوشت:

> Since you have attached the log and configuration files and you have
> determined that the problem is in the nrf52.cfg driver (or the shared files
> used by nrf53.cfg), there are two paths forward: Path 1: Use Recovery
> Commands (a suggested starting point) Sometimes OpenOCD for new chips
> requires running special commands to "unlock" the flash or define new
> partitions. In your reports there were commands like nrf53_cpuapp_recover.
> If your only goal is to download your code and you don't need to work with
> the flash driver right now, try removing the flash commands from your final
> command and focus only on init and halt. If you can connect and halt by
> running the following commands, the problem is definitely related to
> defining the flash banks:
>
> در تاریخ سه‌شنبه ۲۴ فوریه ۲۰۲۶، ۲۲:۲۳ Lawrence K <law...@gm...>
> نوشت:
>
>> Quick followup...
>>
>> I changed the debug hardware to a CMSIS-DAP controller and ran the
>> following command line:
>>
>> /usr/local/bin/openocd -s
>> /home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
>> /usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
>> [find interface/cmsis-dap.cfg]' -c 'transport select swd' -c 'source [find
>> target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c 'flash
>> write_image erase
>> /home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
>> -c 'reset run' -c shutdown -d3 2>cmsis-dap.log
>>
>> Results are similar, with the error at the same point. See attached log.
>>
>> I believe the issue is in the code at
>> openocd-code/tcl/target/nordic/nrf52.cfg but I am not sure exactly what
>> the solution is.
>>
>> -Lawrence-
>>
>> On Mon, Feb 23, 2026 at 1:24 PM Lawrence K <law...@gm...> wrote:
>>
>>> Dear All:
>>>
>>> I am having difficulty connecting a FTDI2232H to a nRF5340.
>>>
>>> Everything is running under 22.04 Ubuntu on a x86 machine. I installed
>>> OpenOCD by git pulling, compiling and installing OpenOCD in the usual
>>> location (master branch as of Feb 2, 2026).
>>>
>>> My hardware is a FTDI2232H board to which I have added a tristate buffer
>>> to TDO to generate SWO on the SWD interface to the nrf5340. This appears to
>>> be working well since I can read the device ID out of the nrf5340. My ftdi
>>> definition file is attached (zed_debug2.cfg).
>>>
>>> I am using Zephyr OS and the west build system. When I ask west to
>>> download my code to the board, west generates the following command:
>>>
>>> /usr/local/bin/openocd -s
>>> /home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
>>> /usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
>>> [find interface/ftdi/zed_debug2.cfg]' -c 'transport select swd' -c 'source
>>> [find target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c
>>> 'flash write_image erase
>>> /home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
>>> -c 'reset run' -c shutdown
>>>
>>> I added '-d 2>ftdi.log' at the end of the command to capture the debug
>>> information (see attached file). It appears everything is working well up
>>> until openocd tries to reset the netcpu (resetting the appcpu works as
>>> expected).
>>>
>>> I read the nrf5340 product specification (datasheet here:
>>> https://docs-be.nordicsemi.com/bundle/ps_nrf5340/page/nRF5340_PS_v1.6.pdf
>>> ) and when I get to section '4.10 RESET — Reset control' it shows that
>>> resetting the appcpu also forces the netcpu into reset and the
>>> netcpu Control-AP is disabled (see section 4.10.5).
>>>
>>> However openocd is attempting to reset the netcpu after resetting the
>>> appcpu, and the control-AP is in-accessible. This throws an error and I
>>> can't continue to loading code and running the system.
>>>
>>> I think the correct response to the netcpu control-AP being inaccessible
>>> is to ignore the error, rather than giving up. The netcpu control-AP is
>>> inaccessible after hard reset, after soft reset, and if the appcpu has
>>> never started the netcpu, it could be in-accessible even in a running
>>> system.
>>>
>>> In an unrelated question, will the nrf54L have the same issue?
>>>
>>> Can someone who understands this a little better than I do take a look
>>> into this? I  can also make changes to scripts and try out anything you
>>> suggest.
>>>
>>> Thanks in advance for your help
>>>
>>> -Lawrence-
>>>
>>>
>>> _______________________________________________
>> OpenOCD-user mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openocd-user
>>
>

Since you have attached the log and configuration files and you have
determined that the problem is in the nrf52.cfg driver (or the shared files
used by nrf53.cfg), there are two paths forward: Path 1: Use Recovery
Commands (a suggested starting point) Sometimes OpenOCD for new chips
requires running special commands to "unlock" the flash or define new
partitions. In your reports there were commands like nrf53_cpuapp_recover.
If your only goal is to download your code and you don't need to work with
the flash driver right now, try removing the flash commands from your final
command and focus only on init and halt. If you can connect and halt by
running the following commands, the problem is definitely related to
defining the flash banks:

در تاریخ سه‌شنبه ۲۴ فوریه ۲۰۲۶، ۲۲:۲۳ Lawrence K <law...@gm...>
نوشت:

> Quick followup...
>
> I changed the debug hardware to a CMSIS-DAP controller and ran the
> following command line:
>
> /usr/local/bin/openocd -s
> /home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
> /usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
> [find interface/cmsis-dap.cfg]' -c 'transport select swd' -c 'source [find
> target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c 'flash
> write_image erase
> /home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
> -c 'reset run' -c shutdown -d3 2>cmsis-dap.log
>
> Results are similar, with the error at the same point. See attached log.
>
> I believe the issue is in the code at
> openocd-code/tcl/target/nordic/nrf52.cfg but I am not sure exactly what
> the solution is.
>
> -Lawrence-
>
> On Mon, Feb 23, 2026 at 1:24 PM Lawrence K <law...@gm...> wrote:
>
>> Dear All:
>>
>> I am having difficulty connecting a FTDI2232H to a nRF5340.
>>
>> Everything is running under 22.04 Ubuntu on a x86 machine. I installed
>> OpenOCD by git pulling, compiling and installing OpenOCD in the usual
>> location (master branch as of Feb 2, 2026).
>>
>> My hardware is a FTDI2232H board to which I have added a tristate buffer
>> to TDO to generate SWO on the SWD interface to the nrf5340. This appears to
>> be working well since I can read the device ID out of the nrf5340. My ftdi
>> definition file is attached (zed_debug2.cfg).
>>
>> I am using Zephyr OS and the west build system. When I ask west to
>> download my code to the board, west generates the following command:
>>
>> /usr/local/bin/openocd -s
>> /home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
>> /usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
>> [find interface/ftdi/zed_debug2.cfg]' -c 'transport select swd' -c 'source
>> [find target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c
>> 'flash write_image erase
>> /home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
>> -c 'reset run' -c shutdown
>>
>> I added '-d 2>ftdi.log' at the end of the command to capture the debug
>> information (see attached file). It appears everything is working well up
>> until openocd tries to reset the netcpu (resetting the appcpu works as
>> expected).
>>
>> I read the nrf5340 product specification (datasheet here:
>> https://docs-be.nordicsemi.com/bundle/ps_nrf5340/page/nRF5340_PS_v1.6.pdf
>> ) and when I get to section '4.10 RESET — Reset control' it shows that
>> resetting the appcpu also forces the netcpu into reset and the
>> netcpu Control-AP is disabled (see section 4.10.5).
>>
>> However openocd is attempting to reset the netcpu after resetting the
>> appcpu, and the control-AP is in-accessible. This throws an error and I
>> can't continue to loading code and running the system.
>>
>> I think the correct response to the netcpu control-AP being inaccessible
>> is to ignore the error, rather than giving up. The netcpu control-AP is
>> inaccessible after hard reset, after soft reset, and if the appcpu has
>> never started the netcpu, it could be in-accessible even in a running
>> system.
>>
>> In an unrelated question, will the nrf54L have the same issue?
>>
>> Can someone who understands this a little better than I do take a look
>> into this? I  can also make changes to scripts and try out anything you
>> suggest.
>>
>> Thanks in advance for your help
>>
>> -Lawrence-
>>
>>
>> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user
>

Quick followup...

I changed the debug hardware to a CMSIS-DAP controller and ran the
following command line:

/usr/local/bin/openocd -s
/home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
/usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
[find interface/cmsis-dap.cfg]' -c 'transport select swd' -c 'source [find
target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c 'flash
write_image erase
/home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
-c 'reset run' -c shutdown -d3 2>cmsis-dap.log

Results are similar, with the error at the same point. See attached log.

I believe the issue is in the code at
openocd-code/tcl/target/nordic/nrf52.cfg but I am not sure exactly what
the solution is.

-Lawrence-

On Mon, Feb 23, 2026 at 1:24 PM Lawrence K <law...@gm...> wrote:

> Dear All:
>
> I am having difficulty connecting a FTDI2232H to a nRF5340.
>
> Everything is running under 22.04 Ubuntu on a x86 machine. I installed
> OpenOCD by git pulling, compiling and installing OpenOCD in the usual
> location (master branch as of Feb 2, 2026).
>
> My hardware is a FTDI2232H board to which I have added a tristate buffer
> to TDO to generate SWO on the SWD interface to the nrf5340. This appears to
> be working well since I can read the device ID out of the nrf5340. My ftdi
> definition file is attached (zed_debug2.cfg).
>
> I am using Zephyr OS and the west build system. When I ask west to
> download my code to the board, west generates the following command:
>
> /usr/local/bin/openocd -s
> /home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
> /usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
> [find interface/ftdi/zed_debug2.cfg]' -c 'transport select swd' -c 'source
> [find target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c
> 'flash write_image erase
> /home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
> -c 'reset run' -c shutdown
>
> I added '-d 2>ftdi.log' at the end of the command to capture the debug
> information (see attached file). It appears everything is working well up
> until openocd tries to reset the netcpu (resetting the appcpu works as
> expected).
>
> I read the nrf5340 product specification (datasheet here:
> https://docs-be.nordicsemi.com/bundle/ps_nrf5340/page/nRF5340_PS_v1.6.pdf
> ) and when I get to section '4.10 RESET — Reset control' it shows that
> resetting the appcpu also forces the netcpu into reset and the
> netcpu Control-AP is disabled (see section 4.10.5).
>
> However openocd is attempting to reset the netcpu after resetting the
> appcpu, and the control-AP is in-accessible. This throws an error and I
> can't continue to loading code and running the system.
>
> I think the correct response to the netcpu control-AP being inaccessible
> is to ignore the error, rather than giving up. The netcpu control-AP is
> inaccessible after hard reset, after soft reset, and if the appcpu has
> never started the netcpu, it could be in-accessible even in a running
> system.
>
> In an unrelated question, will the nrf54L have the same issue?
>
> Can someone who understands this a little better than I do take a look
> into this? I  can also make changes to scripts and try out anything you
> suggest.
>
> Thanks in advance for your help
>
> -Lawrence-
>
>
>

Hi all,

While trying to connect to a Xilinx Kira K26 SoM with OpenOCM v0.12.0 I realized that -rtos configuration is a bit difficult.
Documentation didn’t point out, how target parameters -coreid and -rtos actually interact.
Both seem to be required in this release, as otherwise some gdb interactions won’t work as described.

-coreid … for setting correct gdb-ThreadIDs, if omitted they get all the same ID and gdb just overrides them internally with themselfs
-rtos    … for preparing setting SMP-Threads (there seems to be a LOG difference (… cluster 0 … multicore xyz ), between pre init and post init processing, but final function seems to be the same in the end.)

Target smp <target-cpu0> < target-cpu1> …  for joining cores into a SMP group

One workaround was to split this SMP configuration part into two sections, one before init and one after.
That way all A53 cores where accessible and could then be configured properly.
If one CPU core is deferred-examine state -> all -rtos hwthread and -coreid parts won’t work completely but in parts.

As there seems to be some rework between v0.12.0 and current master branch, there’re likely changes needed to this script.
https://review.openocd.org/c/openocd/+/8471

Is there a good way to still contribute this configuration to OpenOCD?

Changes done here:

  *   Change SMP configuration for A53 cores
  *   Defere -coreid definition to after init-Phase by adding following to custom_board.cfg:
lappend post_init_commands  {
  examine_all_a53
  workaround_hwthread_config
}
  *   Adding R5 core definitions
  *   Stub to add tracing definitions -> Yet no DAP path for it available … maybe in more recent code?

So each SMP group should then appear as it’s own OpenOCD gdbserver port.

Where is the best place to do such rather application specific SMP configurations?
Providing here some helper functions and then call them later from openocd.cfg or a application.cfg?
Or is there a SMP TCL API I just missed so far, which maybe can be reconfigured at runtime from gdb?


# SPDX-License-Identifier: GPL-2.0-or-later

# downloaded: https://github.com/openocd-org/openocd/blob/master/tcl/target/xilinx_zynqmp.cfg

#
# target configuration for
# Xilinx ZynqMP (UltraScale+ / A53)
#

set USE_TRACING 0
set USE_R5 1

if { [info exists CHIPNAME] } {
    set _CHIPNAME $CHIPNAME
} else {
    set _CHIPNAME uscale
}

#
# DAP tap (Quard core A53)
#
if { [info exists DAP_TAPID] } {
    set _DAP_TAPID $DAP_TAPID
} else {
    set _DAP_TAPID 0x5ba00477
}

jtag newtap $_CHIPNAME tap -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_DAP_TAPID
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.tap

#
# PS tap (UltraScale+)
# actually 6 bit PL-TAP and 6 bit PS-TAP
#
if { [info exists PS_TAPID] } {
    set _PS_TAPID $PS_TAPID
    jtag newtap $_CHIPNAME ps -irlen 12 -ircapture 0x1 -irmask 0x03 -expected-id $_PS_TAPID
} else {
    # FPGA Programmable logic. Values take from Table 39-1 in UG1085: and Table 1-2 on page 38
    jtag newtap $_CHIPNAME ps -irlen 12 -ircapture 0x1 -irmask 0x03 -ignore-version \
        -expected-id 0x04711093 \
        -expected-id 0x04710093 \
        -expected-id 0x04721093 \
        -expected-id 0x04720093 \
        -expected-id 0x04739093 \
        -expected-id 0x04730093 \
        -expected-id 0x04738093 \
        -expected-id 0x04740093 \
        -expected-id 0x04750093 \
        -expected-id 0x04759093 \
        -expected-id 0x04758093 \
        -expected-id 0x147E1093 \
        -expected-id 0x147E5093 \
        -expected-id 0x147E4093 \
        -expected-id 0x147E0093 \
        -expected-id 0x147E2093 \
        -expected-id 0x147E6093 \
        -expected-id 0x147FD093 \
        -expected-id 0x147F8093 \
        -expected-id 0x147FF093 \
        -expected-id 0x147FB093 \
        -expected-id 0x147FE093 \
            -expected-id 0x04724093
}

# 0x14711093 is ZU2
# 0x14710093 is ZU3
# 0x14721093 is ZU4
# 0x14720093 is ZU5
# 0x14739093 is ZU6
# 0x14730093 is ZU7
# 0x14738093 is ZU9
# 0x14740093 is ZU11
# 0x14750093 is ZU15
# 0x14759093 is ZU17
# 0x14758093 is ZU19
# 0x147E1093 is ZU21
# 0x147E5093 is ZU25
# 0x147E4093 is ZU27
# 0x147E0093 is ZU28
# 0x147E2093 is ZU29
# 0x147E6093 is ZU39
# 0x147FD093 is ZU43
# 0x147F8093 is ZU46
# 0x147FF093 is ZU47
# 0x147FB093 is ZU48
# 0x147FE093 is ZU49
# 0x04724093 is Kria K26 -> Ultrascale+ MPSoC

set jtag_configured 0

jtag configure $_CHIPNAME.ps -event setup {
    global _CHIPNAME
    global jtag_configured

    if { $jtag_configured == 0 } {
        # add the DAP tap to the chain
        # See https://forums.xilinx.com/t5/UltraScale-Architecture/JTAG-Chain-Configuration-for-Zynq-UltraScale-MPSoC/td-p/758924
        irscan $_CHIPNAME.ps 0x824
        drscan $_CHIPNAME.ps 32 0x00000003
        runtest 100

        # setup event will be re-entered through jtag arp_init
        # break the recursion
        set jtag_configured 1
        # re-initialized the jtag chain
        jtag arp_init
    }
}

set _TARGETNAME $_CHIPNAME.a53
set _CTINAME $_CHIPNAME.cti
set _smp_command ""

# Addressmap from ug1085 page 1200 (Figure 39-8)
# A53 cores (ARM v8-A)
set DBGBASE {0x80410000 0x80510000 0x80610000 0x80710000}
set CTIBASE {0x80420000 0x80520000 0x80620000 0x80720000}
set ETMBASE {0x80440000 0x80540000 0x80640000 0x80740000}
# TCM Base Addresses from DAP
set ETF1_BASE 0x80140000
set ETF2_BASE 0x80150000
set ETR_BASE 0x80170000
set _cores 4
set cfg_coreid 0

for { set _core 0 } { $_core < $_cores } { incr _core } {

    cti create $_CTINAME.$_core -dap $_CHIPNAME.dap -ap-num 1 \
        -baseaddr [lindex $CTIBASE $_core]

    set _command "target create $_TARGETNAME.$_core aarch64 -dap $_CHIPNAME.dap \
        -dbgbase [lindex $DBGBASE $_core] -cti $_CTINAME.$_core"

    if { $_core != 0 } {
        # non-boot core examination may fail
        #after v0.12.0:  set _command "$_command -defer-examine -rtos hwthread -coreid $cfg_coreid"
        set _command "$_command -defer-examine"
        set _smp_command "$_smp_command $_TARGETNAME.$_core"
    } else {
        # uncomment when "hawt" rtos is merged -> not yet in v0.12.0
        #set _command "$_command -rtos hwthread -coreid $cfg_coreid"
        set _smp_command "target smp $_TARGETNAME.$_core"

    set cfg_coreid [expr {$cfg_coreid + 1}]
    }

    eval $_command

    # ETM config part
    # TMC is split into Mode specific registers sets either ETF4K (4k FIFO), ETF8K (8k FIFO) or ETR (router)
    # OpenOCD v12.0.0 does only support JTAG TMC access -> not available at Ultrascale+ -> There DAP access is implemented ... or TPIU
    if { $USE_TRACING } {
      etb config $_TARGETNAME.$_core $ETF1_BASE
      etm config $_TARGETNAME.$_core 64 normal full etb
    }
}

target create uscale.axi mem_ap -dap uscale.dap -ap-num 0

eval $_smp_command

#
# R5 cores (ARM v7)
# for now as similar smp linked cores, but not linked to a53
#
if { $USE_R5 } {
    set _TARGETNAME_R5 $_CHIPNAME.r5
    set _CTINAME_R5 $_CHIPNAME.ctir5

    set DBGBASE_R5 {0x803F0000 0x803F2000}
    set CTIBASE_R5 {0x803F8000 0x803F9000}
    set ETMBASE_R5 {0x803FC000 0x803FD000}
    set R5_cores 2
    set _smp_command ""

    for { set _core 0 } { $_core < $R5_cores } { incr _core } {

        cti create $_CTINAME_R5.$_core -dap $_CHIPNAME.dap -ap-num 1 \
                -baseaddr [lindex $CTIBASE_R5 $_core]

        # -cti ... not yet working for ARM v7-R types (-> cortex_r4)
        set _command "target create $_TARGETNAME_R5.$_core cortex_r4 -dap $_CHIPNAME.dap \
                -dbgbase [lindex $DBGBASE_R5 $_core] -coreid $cfg_coreid"

        if { $_core != 0 } {
                # non-boot core examination may fail
                set _command "$_command -defer-examine"
                set _smp_command "$_smp_command $_TARGETNAME_R5.$_core"
        } else {
                # uncomment when "hawt" rtos is merged
                #set _command "$_command -rtos hwthread"
                set _smp_command "target smp $_TARGETNAME_R5.$_core"
        }

        eval $_command
        set cfg_coreid [expr {$cfg_coreid + 1}]
    }
    eval $_smp_command
}

# select first A53 core es initial current target
targets $_TARGETNAME.0


#
# further Tool functions
#

proc core_up { args } {
    global _TARGETNAME
    foreach core $args {
        $_TARGETNAME.$core arp_examine
    }
}

proc examine_all_a53 {} {
  core_up 1
  core_up 2
  core_up 3
}

proc workaround_hwthread_config {} {
    uscale.a53.0 configure -coreid 0 -rtos hwthread
    uscale.a53.1 configure -coreid 1 -rtos hwthread
    uscale.a53.2 configure -coreid 2 -rtos hwthread
    uscale.a53.3 configure -coreid 3 -rtos hwthread
}


proc BIT {n} {
            return [expr {1 << $n}]
}

set IPI_BASE                           0xff300000
set IPI_PMU_0_TRIG                [expr {$IPI_BASE + 0x30000}]
set IPI_PMU_0_IER                  [expr {$IPI_BASE + 0x30018}]
set IPI_PMU_0                                                 [BIT 16]

set CRF_APB_BASE                0xfd1a0000
set CRF_APB_RST_FPD_APU              [expr {$CRF_APB_BASE + 0x104}]
set CRF_APB_RST_FPD_APU_ACPU0_PWRON_RESET         [BIT 10]
set CRF_APB_RST_FPD_APU_L2_RESET                   [BIT  8]
set CRF_APB_RST_FPD_APU_ACPU0_RESET                        [BIT  0]

set APU_BASE                         0xfd5c0000
set APU_RVBARADDR_BASE              [expr {$APU_BASE + 0x40}]

set PMU_BASE                        0xffd80000
set PMU_GLOBAL                                $PMU_BASE
set PMU_GLOBAL_MB_SLEEP                                                [BIT 16]
set PMU_GLOBAL_FW_IS_PRESENT                          [BIT  4]
set PMU_GLOBAL_DONT_SLEEP                                [BIT  0]

set PMU_RAM_BASE               0xffdc0000

set OCM_RAM_BASE               0xfffc0000

rename BIT {}

add_help_text halt_pmu "Halt the PMU in preparation for loading new firmware.\
            This should be matched with a call to resume_pmu."
proc halt_pmu {} {
            set axi $::_CHIPNAME.axi
            set val [$axi read_memory $::IPI_PMU_0_IER 32 1]
            $axi write_memory $::IPI_PMU_0_IER 32 [expr {$val | $::IPI_PMU_0}]

            set val [$axi read_memory $::IPI_PMU_0_TRIG 32 1]
            $axi write_memory $::IPI_PMU_0_TRIG 32 [expr {$val | $::IPI_PMU_0}]

            set start [ms]
            while {!([$axi read_memory $::PMU_GLOBAL 32 1] & $::PMU_GLOBAL_MB_SLEEP)} {
                        if {[ms] - $start > 1000} {
                                    error "Timed out waiting for PMU to halt"
                        }
            }
}

add_help_text resume_pmu "Resume the PMU after loading new firmware. This\
            should be matched with a call to halt_pmu."
proc resume_pmu {} {
            set axi $::_CHIPNAME.axi
            set val [$axi read_memory $::PMU_GLOBAL 32 1]
            $axi write_memory $::PMU_GLOBAL 32 [expr {$val | $::PMU_GLOBAL_DONT_SLEEP}]

            set start [ms]
            while {!([$axi read_memory $::PMU_GLOBAL 32 1] & $::PMU_GLOBAL_FW_IS_PRESENT)} {
                        if {[ms] - $start > 5000} {
                                    error "Timed out waiting for PMU firmware"
                        }
            }
}

add_usage_text release_apu {apu}
add_help_text release_apu "Release an APU from reset. It will start executing\
            at RVBARADDR. You probably want resume_apu or start_apu instead."
proc release_apu {apu} {
            set axi $::_CHIPNAME.axi
            set val [$axi read_memory $::CRF_APB_RST_FPD_APU 32 1]
            set mask [expr {
                        (($::CRF_APB_RST_FPD_APU_ACPU0_PWRON_RESET | \
                          $::CRF_APB_RST_FPD_APU_ACPU0_RESET) << $apu) | \
                        $::CRF_APB_RST_FPD_APU_L2_RESET
            }]
            $axi write_memory $::CRF_APB_RST_FPD_APU 32 [expr {$val & ~$mask}]

            core_up $apu
            $::_TARGETNAME.$apu aarch64 dbginit
}

proc _rvbaraddr {apu} {
            return [expr {$::APU_RVBARADDR_BASE + 8 * $apu}]
}

add_usage_text resume_apu {apu addr}
add_help_text resume_apu "Resume an APU at a given address."
proc resume_apu {apu addr} {
            set addrl [expr {$addr & 0xffffffff}]
            set addrh [expr {$addr >> 32}]
            $::_CHIPNAME.axi write_memory [_rvbaraddr $apu] 32 [list $addrl $addrh]

            release_apu $apu
}

add_usage_text start_apu {apu}
add_help_text start_apu "Start an APU and put it into an infinite loop at\
            RVBARADDR. This can be convenient if you just want to halt the APU\
            (since it won't execute anything unusual)."
proc start_apu {apu} {
            set axi $::_CHIPNAME.axi
            foreach {addrl addrh} [$axi read_memory [_rvbaraddr $apu] 32 2] {
                        set addr [expr {($addrh << 32) | $addrl}]
            }
            # write the infinite loop instruction
            $axi write_memory $addr 32 0x14000000

            release_apu $apu
}

add_usage_text boot_pmu {image}
add_help_text boot_pmu "Boot the PMU with a given firmware image, loading it\
            to the beginning of PMU RAM. The PMU ROM will jump to this location\
            after we resume it."
proc boot_pmu {image} {
            halt_pmu
            echo "Info : Loading PMU firmware $image to $::PMU_RAM_BASE"
            load_image $image $::PMU_RAM_BASE
            resume_pmu
}

add_usage_text boot_apu "image \[apu=0 \[addr=$OCM_RAM_BASE\]\]"
add_help_text boot_apu "Boot an APU with a given firmware image. The default\
            address is the beginning of OCM RAM. Upon success, the default target\
            will be changed to the (running) apu."
proc boot_apu [list image {apu 0} [list addr $OCM_RAM_BASE]] {
            start_apu $apu
            targets $::_TARGETNAME.$apu
            halt

            echo "Info : Loading APU$apu firmware $image to $addr"
            load_image $image $addr
            resume $addr
}

Kind Regards

Thomas

Dear All:

I am having difficulty connecting a FTDI2232H to a nRF5340.

Everything is running under 22.04 Ubuntu on a x86 machine. I installed
OpenOCD by git pulling, compiling and installing OpenOCD in the usual
location (master branch as of Feb 2, 2026).

My hardware is a FTDI2232H board to which I have added a tristate buffer
to TDO to generate SWO on the SWD interface to the nrf5340. This appears to
be working well since I can read the device ID out of the nrf5340. My ftdi
definition file is attached (zed_debug2.cfg).

I am using Zephyr OS and the west build system. When I ask west to download
my code to the board, west generates the following command:

/usr/local/bin/openocd -s
/home/lawrence/zephyrproject/zephyr/boards/zed-boards/zed_cpu1/support -s
/usr/local/share/openocd/scripts -c 'set WORKAREASIZE 0x4000' -c 'source
[find interface/ftdi/zed_debug2.cfg]' -c 'transport select swd' -c 'source
[find target/nordic/nrf53.cfg]' '-c init' '-c targets' -c 'reset init' -c
'flash write_image erase
/home/lawrence/Documents/zed_cpu1/lps22hb/build/lps22hb/zephyr/zephyr.hex'
-c 'reset run' -c shutdown

I added '-d 2>ftdi.log' at the end of the command to capture the debug
information (see attached file). It appears everything is working well up
until openocd tries to reset the netcpu (resetting the appcpu works as
expected).

I read the nrf5340 product specification (datasheet here:
https://docs-be.nordicsemi.com/bundle/ps_nrf5340/page/nRF5340_PS_v1.6.pdf )
and when I get to section '4.10 RESET — Reset control' it shows that
resetting the appcpu also forces the netcpu into reset and the
netcpu Control-AP is disabled (see section 4.10.5).

However openocd is attempting to reset the netcpu after resetting the
appcpu, and the control-AP is in-accessible. This throws an error and I
can't continue to loading code and running the system.

I think the correct response to the netcpu control-AP being inaccessible is
to ignore the error, rather than giving up. The netcpu control-AP is
inaccessible after hard reset, after soft reset, and if the appcpu has
never started the netcpu, it could be in-accessible even in a running
system.

In an unrelated question, will the nrf54L have the same issue?

Can someone who understands this a little better than I do take a look into
this? I  can also make changes to scripts and try out anything you suggest.

Thanks in advance for your help

-Lawrence-

Hello,

the latest tag OpenOCD v0.12.0 is going to be 2 years old!

I think we should push to tag v1.0.0-rc1 asap, entering in code freeze.
Only bug fixes would be merged between v1.0.0-rc1 and v1.0.0

Do you see any reason for further delaying the new release?
Do you have any new code in Gerrit that should be merged before the
code freeze ?

Thanks,
Antonio

I'm trying to debug stm32h503 with the help of openocd. However, I cannot find stm32h5x.cfg. Is there any plan to support the stm32h5 series chips ?

Hi Antonio:

    I notice these patches, https://review.openocd.org/c/openocd/+/9264/2, I have tested this on my cortex_m core with [-ap-num-gateway], it relly works.

    By the way, how can I use "in-reply-to" in sourceforge mailing list, I cannot find the in-reply-to links

BR,
Weipeng Liang

Hi Antonio:
	
	Thank you very much for your reply, I will continue to follow up on this.

BR,
Weipeng Liang

On Tue, Nov 18, 2025 at 2:36 PM 梁伟鹏 <wei...@xi...> wrote:
>
> Hi Openocd,
>
>
>
>        Does Openocd support the topology like this https://kb.segger.com/DAP#DAP_topology_example_-_Cascaded_APs. In this case, Openocd just scan the first level DP, but the next level APB-AP cannot be scan.
>
> If there is any configurations in Openocd that supports this topology, or openocd just not supports.

Hi 梁伟鹏,

OpenOCD does not support yet the nested AP topology defined by ARM
ADIv6 and CoreSight SoC-600.
We are waiting for a very first implementation from Ampere-Computing;
hopefully in the next weeks.

Regards
Antonio

Hi Openocd,

       Does Openocd support the topology like this https://kb.segger.com/DAP#DAP_topology_example_-_Cascaded_APs. In this case, Openocd just scan the first level DP, but the next level APB-AP cannot be scan.
If there is any configurations in Openocd that supports this topology, or openocd just not supports.

Thanks.

On Tue, Nov 11, 2025 at 8:12 PM Nathan Marshall <npm...@gm...> wrote:
>
> Hello all,
>
> I'm trying to work with a platform targeting the MIMXRT533, and I'm coming up against a perceived limitation of OpenOCD that I wanted to get advice on. I'm trying to enable debug mode which requires writing to the command and status word (CSW, base address 0x4010f000) register with  CSW[RESYNCH_REQ] = 1 and  CSW[CHIP_RESET_REQ] = 1 which I do with mww 0x4010f000 0x21.This causes the device to reset as expected, and then there are other steps in the process that need to be executed according to the datasheet to fully enable debug mode. However, since this first register write causes a reset that OpenOCD does not expect, I get:
>
> "Error: Failed to write memory at 0x4010f004"

Hi,
OpenOCD does not expect the target to become not responsive after a write.
But you can use the Tcl command `catch` to catch the error and handle
it in your script.
Also, to prevent OpenOCD to poll the target until it gets on again,
you can halt polling while write, then wait to let the SoC restart
before reactivating the polling
poll off
catch {mww 0x4010f000 0x21}
sleep 1000
# probably here you need to reconnect the adapter to the target, it
depends on MIMXRT533. You can try with
#       catch {dap init}
#       catch {[dap names] apid 0}
poll on

If you are using SWD, I expect you have no other options, because a
write through SWD should require a following dummy read to get the ACK
status. Probably the address of the error at write+4 is simply due to
the address autoincrement that gets associated with the operation of
reading the ACK.
If you are using JTAG, then OpenOCD allows you to "manually" shift the
command in the JTAG chain. Probably you can inject a write through the
commands irscan/drscan, but it's not trivial. If the Tcl code snippet
above works for you, just use it.

Regards
Antonio

>
> Which indicates that OpenOCD is trying to access some memory beyond what I need (I assume for caching purposes?). This fails since the device is in reset. It seems that OpenOCD needs a special memory write command that expects a subsequent hardware reset to occur for this kind of use case. This isn't the first time I've had this issue. I had a similar problem when trying to define a custom NVIC reset process for a DA1469x platform. Is there a feature already in OpenOCD that I'm missing that could accommodate this use case, or would that require a new feature to be added?
>
> Thanks in advance,
> Nathan
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user

Hello all,

I'm trying to work with a platform targeting the MIMXRT533, and I'm coming
up against a perceived limitation of OpenOCD that I wanted to get advice
on. I'm trying to enable debug mode which requires writing to the command
and status word (CSW, base address 0x4010f000) register with
CSW[RESYNCH_REQ] = 1 and  CSW[CHIP_RESET_REQ] = 1 which I do with mww
0x4010f000 0x21.This causes the device to reset as expected, and then there
are other steps in the process that need to be executed according to the
datasheet to fully enable debug mode. However, since this first register
write causes a reset that OpenOCD does not expect, I get:

"Error: Failed to write memory at 0x4010f004"

Which indicates that OpenOCD is trying to access some memory beyond what I
need (I assume for caching purposes?). This fails since the device is in
reset. It seems that OpenOCD needs a special memory write command that
expects a subsequent hardware reset to occur for this kind of use case.
This isn't the first time I've had this issue. I had a similar problem when
trying to define a custom NVIC reset process for a DA1469x platform. Is
there a feature already in OpenOCD that I'm missing that could accommodate
this use case, or would that require a new feature to be added?

Thanks in advance,
Nathan

On 10/29/25 20:07, Thomas D. Dean wrote:
> My project has two RPi Pico's connected via SPI. The code on each 
> depends on the other.
> 
> I want to connect the two Pico's at the same time:
> 
> PC USB 1 ----> Pico Debugger 1 ----> PIco 1 USB and UART on GPIO0/1
> PC USB 2 ----> Pico Debugger 2 ----> PIco 2 USB and UART on GPIO0/1
> 
> The Pico's have serial=E6614103E73C8B25 and serial=E6632891E33DAF30
> 
I found it - need to read more carefully!

sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
-c "cmsis_dap_serial E6632891E33DAF30" \
-c "adapter speed 5000" \
-c "program <filename>.elf verify; reset halt; resume; shutdown"

Sorry for the noise.

Tom Dean

My project has two RPi Pico's connected via SPI. The code on each 
depends on the other.

I want to connect the two Pico's at the same time:

PC USB 1 ----> Pico Debugger 1 ----> PIco 1 USB and UART on GPIO0/1
PC USB 2 ----> Pico Debugger 2 ----> PIco 2 USB and UART on GPIO0/1

The Pico's have serial=E6614103E73C8B25 and serial=E6632891E33DAF30

I want to program the Pico's with the openocd command

sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
-c "adapter speed 5000" -c "program <filaneme>.elf verify; reset halt; 
resume; shutdown"

How do I specify the serial number? Or other selection criteria?

With one Pico, I see:

Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, 
serial=E6614103E73C8B25
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
...
Info : RP2040 rev 2, QSPI Flash win w25q16jv id = 0x1540ef size = 2048 
KiB in 512 sectors
Info : RP2xxx ROM API function CX @ 2321

Tom Dean

Hi all,

I'm attempting to program a STM32H7A3 using a STLink V3Mods (latest firmware).

It's failing due to the SWD speed being far too high (checked with a DSO).
The initial SWD "magic switch" clock rate is 5Mhz, and the following
SWD coms (stlink_open()?) is at 9Mhz.

When I use a STLink V2 Isol with the exact same openocd scripts, all
SWD clock rates are at 1-2Mhz, and everything works fine.

I've tried a variety of "adapter speed" commands in the script, but it
seems the STLink V3 just ignores it (or it's not being requested by
openocd).

Has anyone come across this before? How do I get it fixed?

Thanks in advance.

https://xpack-dev-tools.github.io/openocd-xpack/blog/2025/10/05/openocd-v0-12-0-7-released/

With a little help from my friends (as the saying goes), I managed to find a functional configuration to run semihosted tests on the Pico:


```
  add_test(
    NAME "rtos-apis-test"

    COMMAND ${pico_openocd}${extension}
    # -d3
    -c "gdb port disabled"
    -c "tcl port disabled"
    -c "telnet port disabled"
    -f interface/cmsis-dap.cfg
    -f target/rp2040.cfg
    -c "adapter speed 5000"
    -c "program rtos-apis-test.elf verify"
    -c "arm semihosting enable"
    -c "arm semihosting_cmdline rtos-apis-test"
    -c "reset halt"
    -c "rp2040.core0 arp_reset assert 0"
  )
```

The `reset halt` asserts the reset on both cores, and the `arp_reset` releases the reset for core 0.

The application then runs until the semihosting SYS_EXIT is executed; openocd returns the test result.

I used the upstream openocd build several months ago, so it looks like there is no need for the raspberry fork of openocd.


Regards,

Liviu

Hi,

I have a test application that I build on various boards and run via openocd.

When I try to run it on the Pico, things are fine up to the moment when I try to run the application:

```
test 1
    Start 1: rtos-apis-test

1: Test command: /Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/raspberrypi-pico-cmake-debug/xpacks/.bin/openocd "-c" "gdb port disabled" "-c" "tcl port disabled" "-c" "telnet port disabled" "-f" "interface/cmsis-dap.cfg" "-f" "target/rp2040.cfg" "-c" "adapter speed 5000" "-c" "program rtos-apis-test.elf verify" "-c" "arm semihosting enable" "-c" "arm semihosting_cmdline rtos-apis-test" "-c" "reset run"
1: Working Directory: /Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/raspberrypi-pico-cmake-debug/platform-bin
1: Test timeout computed to be: 10000000
1: xPack Open On-Chip Debugger 0.12.0+dev-01850-geb6f2745b-dirty (2025-02-07-12:14)
1: Licensed under GNU GPL v2
1: For bug reports, read
1:      http://openocd.org/doc/doxygen/bugs.html
1: Info : Hardware thread awareness created
1: Info : Hardware thread awareness created
1: adapter speed: 5000 kHz
1: Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6616407E339502C
1: Info : CMSIS-DAP: SWD supported
1: Info : CMSIS-DAP: Atomic commands supported
1: Info : CMSIS-DAP: Test domain timer supported
1: Info : CMSIS-DAP: FW Version = 2.0.0
1: Info : CMSIS-DAP: Interface Initialised (SWD)
1: Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
1: Info : CMSIS-DAP: Interface ready
1: Info : clock speed 5000 kHz
1: Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
1: Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
1: Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
1: Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
1: Info : [rp2040.core0] Examination succeed
1: Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
1: Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
1: Info : [rp2040.core1] Examination succeed
1: Info : [rp2040.core0] gdb port disabled
1: Info : [rp2040.core1] gdb port disabled
1: [rp2040.core0] halted due to breakpoint, current mode: Thread 
1: xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
1: [rp2040.core1] halted due to breakpoint, current mode: Thread 
1: xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
1: ** Programming Started **
1: Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
1: Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors
1: 
1: Info : Padding image section 1 at 0x10058934 with 204 bytes (bank write end alignment)
1: Warn : Adding extra erase range, 0x10058a00 .. 0x1005ffff
1: ** Programming Finished **
1: ** Verify Started **
1: ** Verified OK **
1: semihosting is enabled
1: semihosting command line is [rtos-apis-test]
1: Error: [rp2040.core1] not halted
1: Warn : [rp2040.core0] resume of a SMP target failed, trying to resume current one
1: Error: [rp2040.core0] resume failed
1: Error: Failed to resume target
1: Error: [rp2040.core0] Polling failed, trying to reexamine
1: Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
1: Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
1: Info : [rp2040.core0] Examination succeed
1: [rp2040.core0] halted due to debug-request, current mode: Thread 
1: xPSR: 0x01000000 pc: 0x10018416 msp: 0x20041f68, semihosting
1: [rp2040.core1] halted due to debug-request, current mode: Thread 
1: xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
1: Info : tcl server disabled
1: Info : telnet server disabled
```

openocd hangs at this point, and I have to kill it.

Running the same with -d3, I get (only the final part):

```
...
1: Debug: 1444 4923 command.c:153 script_debug(): command - arm semihosting enable
1: User : 1445 4923 options.c:52 configuration_output_handler(): semihosting is enabledUser : 1446 4923 options.c:52 configuration_output_handler(): 
1: Debug: 1447 4923 command.c:153 script_debug(): command - arm semihosting_cmdline rtos-apis-test
1: User : 1448 4923 options.c:52 configuration_output_handler(): semihosting command line is [rtos-apis-test]User : 1449 4923 options.c:52 configuration_output_handler(): 
1: Debug: 1450 4923 command.c:153 script_debug(): command - reset run
1: Debug: 1451 4923 target.c:1794 target_call_reset_callbacks(): target reset 1 (run)
1: Debug: 1452 4923 target.c:1794 target_call_reset_callbacks(): target reset 1 (run)
1: Debug: 1453 4923 command.c:153 script_debug(): command - target names
1: Debug: 1454 4923 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-start
1: Debug: 1455 4923 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-start
1: Debug: 1456 4923 command.c:153 script_debug(): command - transport select
1: Debug: 1457 4923 command.c:153 script_debug(): command - transport select
1: Debug: 1458 4923 command.c:153 script_debug(): command - rp2040.core0 invoke-event examine-start
1: Debug: 1459 4923 command.c:153 script_debug(): command - rp2040.core0 arp_examine allow-defer
1: Debug: 1460 4924 arm_adi_v5.c:935 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
1: Debug: 1461 4924 command.c:153 script_debug(): command - rp2040.core0 invoke-event examine-end
1: Debug: 1462 4924 command.c:153 script_debug(): command - transport select
1: Debug: 1463 4924 command.c:153 script_debug(): command - rp2040.core1 invoke-event examine-start
1: Debug: 1464 4924 command.c:153 script_debug(): command - rp2040.core1 arp_examine allow-defer
1: Debug: 1465 4925 arm_adi_v5.c:935 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
1: Debug: 1466 4925 command.c:153 script_debug(): command - rp2040.core1 invoke-event examine-end
1: Debug: 1467 4925 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-assert-pre
1: Debug: 1468 4925 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-assert-pre
1: Debug: 1469 4925 command.c:153 script_debug(): command - transport select
1: Debug: 1470 4925 command.c:153 script_debug(): command - rp2040.core0 arp_reset assert 0
1: Debug: 1471 4925 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1472 4925 target.c:1902 print_wa_layout():    0x20010000-0x2001ffff (65536 bytes)
1: Debug: 1473 4925 cortex_m.c:1692 cortex_m_assert_reset(): [rp2040.core0] target->state: halted, examined
1: Debug: 1474 4927 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core0] NVIC_DFSR 0x1
1: Debug: 1475 4927 cortex_m.c:1806 cortex_m_assert_reset(): [rp2040.core0] Using Cortex-M SYSRESETREQ
1: Debug: 1476 4928 arm_adi_v5.c:859 dap_dp_init_or_reconnect(): rp2040.dap0
1: Debug: 1477 4928 arm_adi_v5.c:783 dap_dp_init(): rp2040.dap0
1: Debug: 1478 4928 arm_adi_v5.c:816 dap_dp_init(): DAP: wait CDBGPWRUPACK
1: Debug: 1479 4928 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
1: Debug: 1480 4928 arm_adi_v5.c:824 dap_dp_init(): DAP: wait CSYSPWRUPACK
1: Debug: 1481 4928 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
1: Debug: 1482 4928 cmsis_dap.c:839 cmsis_dap_swd_write_from_queue(): refusing to enable sticky overrun detection
1: Debug: 1483 4988 command.c:153 script_debug(): command - transport select
1: Debug: 1484 4988 command.c:153 script_debug(): command - rp2040.core1 arp_reset assert 0
1: Debug: 1485 4988 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1486 4988 cortex_m.c:1692 cortex_m_assert_reset(): [rp2040.core1] target->state: halted, examined
1: Debug: 1487 4990 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core1] NVIC_DFSR 0x1
1: Debug: 1488 4990 cortex_m.c:1806 cortex_m_assert_reset(): [rp2040.core1] Using Cortex-M SYSRESETREQ
1: Debug: 1489 4990 arm_adi_v5.c:859 dap_dp_init_or_reconnect(): rp2040.dap1
1: Debug: 1490 4991 arm_adi_v5.c:783 dap_dp_init(): rp2040.dap1
1: Debug: 1491 4991 arm_adi_v5.c:816 dap_dp_init(): DAP: wait CDBGPWRUPACK
1: Debug: 1492 4991 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
1: Debug: 1493 4991 arm_adi_v5.c:824 dap_dp_init(): DAP: wait CSYSPWRUPACK
1: Debug: 1494 4991 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
1: Debug: 1495 4991 cmsis_dap.c:839 cmsis_dap_swd_write_from_queue(): refusing to enable sticky overrun detection
1: Debug: 1496 5048 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-assert-post
1: Debug: 1497 5048 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-assert-post
1: Debug: 1498 5048 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-deassert-pre
1: Debug: 1499 5048 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-deassert-pre
1: Debug: 1500 5048 command.c:153 script_debug(): command - transport select
1: Debug: 1501 5048 command.c:153 script_debug(): command - rp2040.core0 arp_reset deassert 0
1: Debug: 1502 5048 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1503 5048 target.c:1902 print_wa_layout():    0x20010000-0x2001ffff (65536 bytes)
1: Debug: 1504 5048 cortex_m.c:1850 cortex_m_deassert_reset(): [rp2040.core0] target->state: reset, examined
1: Debug: 1505 5049 command.c:153 script_debug(): command - transport select
1: Debug: 1506 5049 command.c:153 script_debug(): command - rp2040.core1 arp_reset deassert 0
1: Debug: 1507 5049 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1508 5049 cortex_m.c:1850 cortex_m_deassert_reset(): [rp2040.core1] target->state: reset, examined
1: Debug: 1509 5049 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-deassert-post
1: Debug: 1510 5049 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-deassert-post
1: Debug: 1511 5049 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-end
1: Debug: 1512 5049 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-end
1: Debug: 1513 5050 cortex_m.c:1013 cortex_m_poll_one(): [rp2040.core0] Exit from reset with dcb_dhcsr 0x30003
1: Debug: 1514 5050 cortex_m.c:619 cortex_m_endreset_event(): [rp2040.core0] DCB_DEMCR = 0x01000000
1: Debug: 1515 5051 target.c:2652 target_write_u32(): address: 0xe0002000, value: 0x00000003
1: Debug: 1516 5051 target.c:2564 target_read_u32(): address: 0xe0002000, value: 0x00000041
1: Debug: 1517 5051 target.c:2652 target_write_u32(): address: 0xe0002008, value: 0x00000000
1: Debug: 1518 5052 target.c:2652 target_write_u32(): address: 0xe000200c, value: 0x00000000
1: Debug: 1519 5052 target.c:2652 target_write_u32(): address: 0xe0002010, value: 0x00000000
1: Debug: 1520 5052 target.c:2652 target_write_u32(): address: 0xe0002014, value: 0x00000000
1: Debug: 1521 5052 target.c:2652 target_write_u32(): address: 0xe0001020, value: 0x00000000
1: Debug: 1522 5053 target.c:2652 target_write_u32(): address: 0xe0001024, value: 0x00000000
1: Debug: 1523 5053 target.c:2652 target_write_u32(): address: 0xe0001028, value: 0x00000000
1: Debug: 1524 5053 target.c:2652 target_write_u32(): address: 0xe0001030, value: 0x00000000
1: Debug: 1525 5053 target.c:2652 target_write_u32(): address: 0xe0001034, value: 0x00000000
1: Debug: 1526 5053 target.c:2652 target_write_u32(): address: 0xe0001038, value: 0x00000000
1: Debug: 1527 5054 cortex_m.c:852 cortex_m_debug_entry(): [rp2040.core0]  
1: Debug: 1528 5055 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core0] NVIC_DFSR 0x3
1: Debug: 1529 5057 cortex_m.c:359 cortex_m_fast_read_all_regs(): [rp2040.core0] read 20 32-bit registers
1: Debug: 1530 5057 cortex_m.c:927 cortex_m_debug_entry(): [rp2040.core0] entered debug state in core mode: Thread at PC 0x100183d2, cpu in Non-Secure state, target->state: halted
1: Debug: 1531 5057 arm_adi_v5.c:401 mem_ap_setup_transfer_verify_size_packing(): AP#0x0 probed size 2: supported
1: Debug: 1532 5057 target.c:2588 target_read_u16(): address: 0x100183d2, value: 0xbeab
1: Debug: 1533 5057 semihosting_common.c:399 semihosting_common(): op=0x1 (OPEN), param=0x20041f70
1: Debug: 1534 5058 arm_adi_v5.c:401 mem_ap_setup_transfer_verify_size_packing(): AP#0x0 probed size 1: supported
1: Debug: 1535 5058 semihosting_common.c:977 semihosting_common(): dup(STDOUT)=5
1: Debug: 1536 5058 target.c:1776 target_call_event_callbacks(): target event 3 (resume-start) for core rp2040.core0
1: Debug: 1537 5058 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1538 5058 target.c:1902 print_wa_layout():    0x20010000-0x2001ffff (65536 bytes)
1: Debug: 1539 5058 target.c:2588 target_read_u16(): address: 0x100183d2, value: 0xbeab
1: Debug: 1540 5058 armv7m.c:1122 armv7m_maybe_skip_bkpt_inst(): [rp2040.core0] Skipping over BKPT instruction
1: Debug: 1541 5058 armv7m.c:199 armv7m_restore_context(): [rp2040.core0]  
1: Debug: 1542 5059 armv7m.c:469 armv7m_write_core_reg(): [rp2040.core0] write pc value 0x100183d4
1: Debug: 1543 5059 armv7m.c:469 armv7m_write_core_reg(): [rp2040.core0] write r0 value 0x00000005
1: Error: 1544 5059 cortex_m.c:1323 cortex_m_restore_one(): [rp2040.core1] not halted
1: Warn : 1545 5059 cortex_m.c:1472 cortex_m_resume(): [rp2040.core0] resume of a SMP target failed, trying to resume current one
1: Debug: 1546 5059 target.c:1776 target_call_event_callbacks(): target event 2 (resumed) for core rp2040.core0
1: Error: 1547 5059 cortex_m.c:1477 cortex_m_resume(): [rp2040.core0] resume failed
1: Error: 1548 5059 arm_semihosting.c:63 arm_semihosting_resume(): Failed to resume target
1: Debug: 1549 5059 cortex_m.c:1056 cortex_m_poll_one(): [rp2040.core0] postpone target event 'halted'
1: Debug: 1550 5059 target.c:1776 target_call_event_callbacks(): target event 0 (gdb-halt) for core rp2040.core0
1: Error: 1551 5059 target.c:3000 handle_target(): [rp2040.core0] Polling failed, trying to reexamine
1: Debug: 1552 5059 target.c:674 target_examine_one(): [rp2040.core0] Examination started
1: Debug: 1553 5059 target.c:1776 target_call_event_callbacks(): target event 19 (examine-start) for core rp2040.core0
1: Debug: 1554 5059 arm_adi_v5.c:935 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
1: Debug: 1555 5060 target.c:2564 target_read_u32(): address: 0xe000ed00, value: 0x410cc601
1: Info : 1556 5060 cortex_m.c:2646 cortex_m_examine(): [rp2040.core0] Cortex-M0+ r0p1 processor detected
1: Debug: 1557 5060 cortex_m.c:2666 cortex_m_examine(): [rp2040.core0] cpuid: 0x410cc601
1: Debug: 1558 5060 target.c:2564 target_read_u32(): address: 0xe000edf0, value: 0x01030003
1: Debug: 1559 5060 target.c:2652 target_write_u32(): address: 0xe000edfc, value: 0x01000000
1: Debug: 1560 5060 target.c:2652 target_write_u32(): address: 0xe0000fb0, value: 0xc5acce55
1: Debug: 1561 5061 target.c:2564 target_read_u32(): address: 0xe0000e80, value: 0x00000000
1: Debug: 1562 5061 target.c:2652 target_write_u32(): address: 0xe0000e80, value: 0x00000000
1: Debug: 1563 5061 target.c:2564 target_read_u32(): address: 0xe0000e80, value: 0x00000000
1: Debug: 1564 5061 target.c:2652 target_write_u32(): address: 0xe0000e80, value: 0x00010009
1: Debug: 1565 5061 target.c:2652 target_write_u32(): address: 0xe0000e00, value: 0x00000001
1: Debug: 1566 5062 target.c:2652 target_write_u32(): address: 0xe0000e04, value: 0x00000000
1: Debug: 1567 5062 target.c:2652 target_write_u32(): address: 0xe0000e08, value: 0x00000000
1: Debug: 1568 5062 target.c:2652 target_write_u32(): address: 0xe0000e0c, value: 0x00000000
1: Debug: 1569 5062 target.c:2652 target_write_u32(): address: 0xe0000e10, value: 0x00000000
1: Debug: 1570 5062 target.c:2652 target_write_u32(): address: 0xe0000e14, value: 0x00000000
1: Debug: 1571 5063 target.c:2652 target_write_u32(): address: 0xe0000e18, value: 0x00000000
1: Debug: 1572 5063 target.c:2652 target_write_u32(): address: 0xe0000e1c, value: 0x00000000
1: Debug: 1573 5063 target.c:2564 target_read_u32(): address: 0xe0002000, value: 0x00000041
1: Debug: 1574 5063 target.c:2652 target_write_u32(): address: 0xe0002008, value: 0x00000000
1: Debug: 1575 5064 target.c:2652 target_write_u32(): address: 0xe000200c, value: 0x00000000
1: Debug: 1576 5064 target.c:2652 target_write_u32(): address: 0xe0002010, value: 0x00000000
1: Debug: 1577 5064 target.c:2652 target_write_u32(): address: 0xe0002014, value: 0x00000000
1: Debug: 1578 5064 cortex_m.c:2789 cortex_m_examine(): [rp2040.core0] FPB fpcr 0x41, numcode 4, numlit 0
1: Debug: 1579 5064 target.c:2564 target_read_u32(): address: 0xe0001000, value: 0x20000000
1: Debug: 1580 5064 cortex_m.c:2460 cortex_m_dwt_setup(): [rp2040.core0] DWT_CTRL: 0x20000000
1: Debug: 1581 5065 target.c:2564 target_read_u32(): address: 0xe0001fbc, value: 0x00000000
1: Debug: 1582 5065 cortex_m.c:2467 cortex_m_dwt_setup(): [rp2040.core0] DWT_DEVARCH: 0x0
1: Debug: 1583 5065 target.c:2652 target_write_u32(): address: 0xe0001028, value: 0x00000000
1: Debug: 1584 5065 target.c:2652 target_write_u32(): address: 0xe0001038, value: 0x00000000
1: Debug: 1585 5065 cortex_m.c:2516 cortex_m_dwt_setup(): [rp2040.core0] DWT dwtcr 0x20000000, comp 2, watch/trigger
1: Info : 1586 5065 cortex_m.c:2798 cortex_m_examine(): [rp2040.core0] target has 4 breakpoints, 2 watchpoints
1: Debug: 1587 5065 target.c:1776 target_call_event_callbacks(): target event 21 (examine-end) for core rp2040.core0
1: Info : 1588 5065 target.c:690 target_examine_one(): [rp2040.core0] Examination succeed
1: Debug: 1589 5066 cortex_m.c:1013 cortex_m_poll_one(): [rp2040.core1] Exit from reset with dcb_dhcsr 0x40001
1: Debug: 1590 5066 cortex_m.c:619 cortex_m_endreset_event(): [rp2040.core1] DCB_DEMCR = 0x01000000
1: Debug: 1591 5067 target.c:2652 target_write_u32(): address: 0xe0002000, value: 0x00000003
1: Debug: 1592 5067 target.c:2564 target_read_u32(): address: 0xe0002000, value: 0x00000041
1: Debug: 1593 5067 target.c:2652 target_write_u32(): address: 0xe0002008, value: 0x00000000
1: Debug: 1594 5067 target.c:2652 target_write_u32(): address: 0xe000200c, value: 0x00000000
1: Debug: 1595 5068 target.c:2652 target_write_u32(): address: 0xe0002010, value: 0x00000000
1: Debug: 1596 5068 target.c:2652 target_write_u32(): address: 0xe0002014, value: 0x00000000
1: Debug: 1597 5068 target.c:2652 target_write_u32(): address: 0xe0001020, value: 0x00000000
1: Debug: 1598 5068 target.c:2652 target_write_u32(): address: 0xe0001024, value: 0x00000000
1: Debug: 1599 5068 target.c:2652 target_write_u32(): address: 0xe0001028, value: 0x00000000
1: Debug: 1600 5069 target.c:2652 target_write_u32(): address: 0xe0001030, value: 0x00000000
1: Debug: 1601 5069 target.c:2652 target_write_u32(): address: 0xe0001034, value: 0x00000000
1: Debug: 1602 5069 target.c:2652 target_write_u32(): address: 0xe0001038, value: 0x00000000
1: Debug: 1603 5070 cortex_m.c:1202 cortex_m_halt_one(): [rp2040.core0] target->state: running
1: Debug: 1604 5071 cortex_m.c:1202 cortex_m_halt_one(): [rp2040.core1] target->state: running
1: Debug: 1605 5073 cortex_m.c:852 cortex_m_debug_entry(): [rp2040.core0]  
1: Debug: 1606 5073 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core0] NVIC_DFSR 0x3
1: Debug: 1607 5076 cortex_m.c:359 cortex_m_fast_read_all_regs(): [rp2040.core0] read 20 32-bit registers
1: Debug: 1608 5076 cortex_m.c:927 cortex_m_debug_entry(): [rp2040.core0] entered debug state in core mode: Thread at PC 0x10018416, cpu in Non-Secure state, target->state: halted
1: Debug: 1609 5076 cortex_m.c:1056 cortex_m_poll_one(): [rp2040.core0] postpone target event 'halted'
1: Debug: 1610 5077 cortex_m.c:852 cortex_m_debug_entry(): [rp2040.core1]  
1: Debug: 1611 5077 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core1] NVIC_DFSR 0x1
1: Debug: 1612 5080 cortex_m.c:359 cortex_m_fast_read_all_regs(): [rp2040.core1] read 20 32-bit registers
1: Debug: 1613 5080 cortex_m.c:927 cortex_m_debug_entry(): [rp2040.core1] entered debug state in core mode: Thread at PC 0x178, cpu in Non-Secure state, target->state: halted
1: Debug: 1614 5080 cortex_m.c:1056 cortex_m_poll_one(): [rp2040.core1] postpone target event 'halted'
1: Debug: 1615 5080 cortex_m.c:1171 cortex_m_poll_smp(): [rp2040.core0] sending postponed target event 'halted'
1: Debug: 1616 5080 target.c:1776 target_call_event_callbacks(): target event 0 (gdb-halt) for core rp2040.core0
1: Debug: 1617 5080 target.c:1776 target_call_event_callbacks(): target event 1 (halted) for core rp2040.core0
1: User : 1618 5080 armv7m.c:781 armv7m_arch_state(): [rp2040.core0] halted due to debug-request, current mode: Thread 
1: xPSR: 0x01000000 pc: 0x10018416 msp: 0x20041f68, semihosting
1: Debug: 1619 5080 cortex_m.c:1171 cortex_m_poll_smp(): [rp2040.core1] sending postponed target event 'halted'
1: Debug: 1620 5080 target.c:1776 target_call_event_callbacks(): target event 0 (gdb-halt) for core rp2040.core1
1: Debug: 1621 5080 target.c:1776 target_call_event_callbacks(): target event 1 (halted) for core rp2040.core1
1: User : 1622 5080 armv7m.c:781 armv7m_arch_state(): [rp2040.core1] halted due to debug-request, current mode: Thread 
1: xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
1: Info : 1623 5080 tcl_server.c:280 tcl_init(): tcl server disabled
1: Info : 1624 5080 telnet_server.c:945 telnet_init(): telnet server disabled
1: Debug: 1625 5080 command.c:153 script_debug(): command - init
```


The same ELF runs fine on the same board, when programmed with J-Link and Ozone

```
1.382 829 SEGGER Ozone - The J-Link Debugger V3.40b
1.605 091 J-Link software found at: /Applications/SEGGER/Ozone_V340b/Ozone.app/Contents/MacOS/Lib/libjlinkarm.dylib
8.423 831 File.NewProject();
31.200 443 File.Open: completed in 233 ms
31.200 755 Program segments:
31.200 777   Address         Size         Code      RO Data      RW Data      ZI Data    Flg
31.200 798 ---------    ---------    ---------    ---------    ---------    ---------    ---
31.200 806  10048148            0            0            0            0            0    R
31.200 814  10000000      295 164      275 952       19 212            0            0    RWE
31.200 822  20000000       54 716            0            0       54 716            0    RW
31.200 829  2000D5C0       13 560            0            0            0       13 560    RW
31.200 836 ---------    ---------    ---------    ---------    ---------    ---------    ---
31.200 842    Total:      363 440      275 952       19 212       54 716       13 560
31.200 847 ---------    ---------    ---------    ---------    ---------    ---------    ---
31.200 854 For further information on ELF file data sections, execute command Elf.PrintSectionInfo(0).
31.271 708 Debug.ReadIntoInstCache: updated instruction information within 2 code ranges (0x10000000-0x1004363C)
31.604 002 File.Open ("/Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/raspberrypi-pico-cmake-debug/platform-bin/rtos-apis-test.elf");
36.182 476 Tools.DebugSettings();
01:16.697 191 J-Link settings were written to the project file.
01:16.713 477 Target core support plugin loaded.: /Applications/SEGGER/Ozone_V340b/Ozone.app/Contents/MacOS/Plugins/Core/CorePluginARM.dylib
01:16.751 314 Debug.ReadIntoInstCache: updated instruction information within 2 code ranges (0x10000000-0x1004363C)
01:16.969 723 Project.SetDevice ("RP2040_M0_0");
01:16.969 804 Project.SetTargetIF ("SWD");
01:16.970 091 Project.SetTIFSpeed ("4 MHz");
01:30.901 712 Debug.Start();
01:31.559 160 Device "RP2040_M0_0" selected.
01:31.595 029 ConfigTargetSettings() start
01:31.595 078 J-Link script: ConfigTargetSettings()
01:31.595 090 ConfigTargetSettings() end - Took 487us
01:31.595 098 Found SW-DP with ID 0x0BC12477
01:31.595 106 DPIDR: 0x0BC12477
01:31.595 112 CoreSight SoC-400 or earlier
01:31.595 121 Scanning AP map to find all available APs
01:31.595 129 AP[1]: Stopped AP scan as end of AP map has been reached
01:31.595 137 AP[0]: AHB-AP (IDR: 0x04770031, ADDR: 0x00000000)
01:31.595 146 Iterating through AP map to find AHB-AP to use
01:31.598 546 AP[0]: Core found
01:31.598 569 AP[0]: AHB-AP ROM base: 0xE00FF000
01:31.598 577 CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
01:31.598 584 Found Cortex-M0 r0p1, Little endian.
01:31.598 591 FPUnit: 4 code (BP) slots and 0 literal slots
01:31.598 597 CoreSight components:
01:31.598 604 ROMTbl[0] @ E00FF000
01:31.598 609 [0][0]: E000E000 CID B105E00D PID 000BB008 SCS
01:31.598 615 [0][1]: E0001000 CID B105E00D PID 000BB00A DWT
01:31.598 620 [0][2]: E0002000 CID B105E00D PID 000BB00B FPB
01:31.611 005 Connected to target device.
01:31.611 032 J-Link/J-Trace serial number: 174300531
01:31.655 079 Reset type: NORMAL (https://wiki.segger.com/J-Link_Reset_Strategies)
01:31.655 148 Reset: Halt core after reset via DEMCR.VC_CORERESET.
01:31.655 156 Reset: Reset device via AIRCR.SYSRESETREQ.
01:31.818 141 AfterResetTarget() start
01:31.818 174 AfterResetTarget() end - Took 2.81ms
01:32.718 737 J-Link: Flash download: Bank 0 @ 0x10000000: Skipped. Contents already match
01:32.726 600 Memory map 'after startup completion point' is active
01:32.813 757 Performing semihosting operation SysOpen.
01:32.814 884 Semihosting operation SysOpen completed with result code 4294967040.
01:32.853 144 Performing semihosting operation SysWrite.
01:32.854 220 Semihosting operation SysWrite completed with result code 0.
01:32.901 204 Performing semihosting operation SysWrite.
...
02:59.563 672 Semihosting operation SysWrite completed with result code 0.
02:59.611 834 Performing semihosting operation SysWrite.
02:59.612 876 Semihosting operation SysWrite completed with result code 0.
02:59.667 317 Performing semihosting operation SysWrite.
02:59.668 322 Semihosting operation SysWrite completed with result code 0.
02:59.716 675 Performing semihosting operation SysExit.
02:59.716 708 Target application exited with exit code (0x20026).
02:59.716 717 Semihosting operation SysExit completed with result code 131110.
02:59.716 774 Debug.Stop();
02:59.809 437 Disconnected from target device.
```


My experience with openocd is limited, and with multi-core devices even more limited, so I have difficulties to understand the debug log.

However I guess that the issue is somehow caused by the lack of specificity when reseting the target, probably it should mention explicitly that I want only the rp2040.core0 to run, and keep rp2040.core1 halted.


Any suggestions how to fix this?

Thank you,

Liviu

Thanks. My fault. 

> Am 17.09.2025 um 12:51 schrieb Paul Fertser <fer...@gm...>:
> 
> On Wed, Sep 17, 2025 at 12:47:16PM +0200, Christoph Kukulies wrote:
>> I'm not using the Nucleo F411 target. I wrote "Target is a WeAct Studio
> 
> You are using nucleo F411 _target config_ though and that's why you're
> seeing the error.
> 
> -- 
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fer...@gm...

Sorry, I was a bit hasty. So, step by step:

I added
 -c "arm semihosting enable" -c "arm semihosting_fileio enable"
to the OpenOCD Command line options field in STM32CubeIDE Debugger launch panel:
Show command line gives:
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd "-f" "SEMI Debug.cfg" "-s" "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" "-s" "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-c" "arm semihosting enable" "-c" "arm semihosting_fileio enable" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"

Started and got the following error message:

Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD <https://github.com/STMicroelectronics/OpenOCD>]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html <http://openocd.org/doc/doxygen/bugs.html>
Error: The 'arm semihosting' command must be used after 'init'.



So I thought, I'd add a -c "init" in front of that, which make the two options (arm semihosting enable and arm semihosting_fileio enable" obviously understood by
OpenOCD since it writes them out:

Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD <https://github.com/STMicroelectronics/OpenOCD>]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html <http://openocd.org/doc/doxygen/bugs.html>
Info : STLINK V2J46M33 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.229804
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [STM32H503CBTx.ap0] Examination succeed
Info : [STM32H503CBTx.cpu] Cortex-M33 r0p4 processor detected
Info : [STM32H503CBTx.cpu] target has 8 breakpoints, 4 watchpoints
STM32H503CBTx.cpu in Non-Secure state
STM32H503CBTx TrustZone disabled
STM32H503CBTx.cpu work-area address is set to 0x20000000
STM32H503CBTx.cpu work-area is enabled
Info : [STM32H503CBTx.cpu] Examination succeed
Info : gdb port disabled
Info : starting gdb server for STM32H503CBTx.cpu on 3333
Info : Listening on port 3333 for gdb connections
semihosting is enabled
semihosting fileio is enabled
Error: The 'gdb_report_data_abort' command must be used before 'init'.


But then this last line?

And as a control you can see the command line now:

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd "-f" "SEMI Debug.cfg" "-s" "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" "-s" "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-c" "init" "-c" "arm semihosting enable" "-c" "arm semihosting_fileio enable" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"

> Am 16.09.2025 um 23:33 schrieb Tommy Murphy <tom...@ho...>:
> 
> With applied, I'm told that these commands have occur after an "init" command.
> So I added
> 
> -c "init" in front of the above two flags.
> 
> Result is this:
> Error: The 'gdb_report_data_abort' command must be used before 'init'.
> This is the complete command line of OpenOCD:
> 
> /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd "-f" "SEMI Debug.cfg" "-s" "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" "-s" "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-c" "arm semihosting enable" "-c" "arm semihosting_fileio enable" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"
> 
> There's no -c "init" in that command line.

On Wed, Sep 17, 2025 at 12:47:16PM +0200, Christoph Kukulies wrote:
> I'm not using the Nucleo F411 target. I wrote "Target is a WeAct Studio

You are using nucleo F411 _target config_ though and that's why you're
seeing the error.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...