STM32MP157 Debugging method use wrong GDB port when execute command `west debug`

zeyingzheng-linux commented 1 year ago

Describe the bug According to the debuging instructions from official website, I find that wrong gdb port will be use when execute command west debug in STM32MP157 platform. The following is the URL: https://docs.zephyrproject.org/latest/boards/arm/stm32mp157c_dk2/doc/stm32mp157_dk2.html

Please also mention any information which could help others to understand the problem you're facing:

Target platform: STM32MP157 lines hardward
Manual change the GDB port from 3333 to 3334 can fix this issue

To Reproduce Steps to reproduce the behavior: (The firmware must first be loaded by the Cortex®-A7, information obtained from official website)

Start up the sdk environment: source /environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi

Start OpenOCD ${OECORE_NATIVE_SYSROOT}/usr/bin/openocd -s ${OECORE_NATIVE_SYSROOT}/usr/share/openocd/scripts -f board/stm32mp15x_dk2.cfg (It provide gdb port 3334 for user , console output just like below)

  Open On-Chip Debugger 0.10.0+dev-01131-gb5d2b12-dirty (2020-08-11-06:07)
  Licensed under GNU GPL v2
  For bug reports, read
      http://openocd.org/doc/doxygen/bugs.html
  srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

  Info : Listening on port 6666 for tcl connections
  Info : Listening on port 4444 for telnet connections
  Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
  Info : Target voltage: 3.047767
  Info : Unable to match requested speed 5000 kHz, using 4000 kHz
  Info : Unable to match requested speed 5000 kHz, using 4000 kHz
  Info : clock speed 4000 kHz
  Info : stlink_dap_op_connect(connect)
  Info : SWD DPIDR 0x6ba02477
  Info : stlink_dap_op_connect(connect)
  Info : SWD DPIDR 0x6ba02477
  Info : stm32mp15x.cm4: hardware has 6 breakpoints, 4 watchpoints
  Info : stm32mp15x.cpu0: hardware has 6 breakpoints, 4 watchpoints
  Info : stm32mp15x.cpu1: hardware has 6 breakpoints, 4 watchpoints
  Info : starting gdb server for stm32mp15x.cpu0 on 3333
  Info : Listening on port 3333 for gdb connections
  Info : starting gdb server for stm32mp15x.cm4 on 3334
  Info : Listening on port 3334 for gdb connections

Run gdb in Zephyr environment in another terminal west build -p always -b stm32mp157c_dk2 samples/basic/blinky west debug

See error : (The wrong gdb port 3333 will be use )

  -- west debug: rebuilding
  ninja: no work to do.
  -- west debug: using runner openocd
  -- runners.openocd: OpenOCD GDB server running on port 3333; no thread info available
  Open On-Chip Debugger 0.11.0+dev-00725-gc5c47943d-dirty (2022-10-03-06:14)
  Licensed under GNU GPL v2
  For bug reports, read
      http://openocd.org/doc/doxygen/bugs.html
  Error: Debug Adapter has to be specified, see "adapter driver" command

  GNU gdb (Zephyr SDK 0.15.1) 12.1
  Copyright (C) 2022 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://github.com/zephyrproject-rtos/sdk-ng/issues>.
  Find the GDB manual and other documentation resources online at:
      <http://www.gnu.org/software/gdb/documentation/>.

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/build/zephyr/zephyr.elf...
  Remote debugging using :3333
  0xc011b648 in ?? ()
  Loading section rom_start, size 0x298 lma 0x0
  Loading section text, size 0x4928 lma 0x298
  Load failed
  (gdb) q

Expected behavior The right gdb port 3334 will be use . And I check the infomation from west debug --help , I cannot find the way to indicate gdb port what real use .

Impact I can fix this issue via modifying openocd.py manual, but I think it is not a correct way .

diff --git a/scripts/west_commands/runners/openocd.py b/scripts/west_commands/runners/openocd.py
index 6f4db76db2..3123c5cece 100644
--- a/scripts/west_commands/runners/openocd.py
+++ b/scripts/west_commands/runners/openocd.py
@@ -19,7 +19,7 @@ from runners.core import ZephyrBinaryRunner

 DEFAULT_OPENOCD_TCL_PORT = 6333
 DEFAULT_OPENOCD_TELNET_PORT = 4444
-DEFAULT_OPENOCD_GDB_PORT = 3333
+DEFAULT_OPENOCD_GDB_PORT = 3334
 DEFAULT_OPENOCD_RESET_HALT_CMD = 'reset init'
 DEFAULT_OPENOCD_TARGET_HANDLE = "_TARGETNAME"

Environment (please complete the following information):

OS: Ubuntu 18.04.6 LTS (Bionic Beaver)
Toolchain: Zephyr SDK
Commit SHA or Version used: 9cb1ff7fce (HEAD -> main, origin/main, origin/HEAD) Settings: NVS: Add cache for nvs name lookup

arnopo commented 1 year ago

Hi, Could you have a look to this fix, I just pushed: https://github.com/zephyrproject-rtos/zephyr/pull/52164

zeyingzheng-linux commented 1 year ago

Hi, Could you have a look to this fix, I just pushed: #52164

Thanks for your response , I tried your patch and it works for me , but I don't know whether I use the patch in a right way .

I always follow the instructions in boards/arm/stm32mp157c_dk2/doc/stm32mp157_dk2.rst , So I download the stm32mp1 developer package , and here are my steps :

1) start OpenOCD in a dedicated terminal

   - Start up the  sdk environment::
      cd <SDK installation directory>   // The stm32mp1 developer package which I download from stm32 official website
      source environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi

   - Start OpenOCD::

      ./sysroots/x86_64-ostl_sdk-linux/usr/bin/openocd -s ./sysroots/x86_64-ostl_sdk-linux/usr/share/openocd/scripts -f board/stm32mp15x_dk2.cfg

2) run gdb in Zephyr environment

  Principle is to attach to the firmware already loaded by the Linux.

   - build the sample::

      west build -b stm32mp157c_dk2 samples/hello_world

   - copy the firmware on the target filesystem, load it and start it (`stm32mp157c boot Cortex-M4 firmware`_)
   - attach to the target::

      west attach

Then I can get the expected behavior when I add your patch on stm32mp1 developer package :

diff --git a/sysroots/x86_64-ostl_sdk-linux/usr/share/openocd/scripts/board/stm32mp15x_dk2.cfg b/sysroots/x86_64-ostl_sdk-linux/usr/share/openocd/scripts/board/stm32mp15x_dk2.cfg
index 0233c6d75..4040f2d89 100644
--- a/sysroots/x86_64-ostl_sdk-linux/usr/share/openocd/scripts/board/stm32mp15x_dk2.cfg
+++ b/sysroots/x86_64-ostl_sdk-linux/usr/share/openocd/scripts/board/stm32mp15x_dk2.cfg
@@ -7,5 +7,9 @@ source [find interface/stlink-dap.cfg]
 transport select dapdirect_swd

 source [find target/stm32mp15x.cfg]
+# By default the port 3333 is assigned for the Cortex-A debug. Disable them
+stm32mp15x.cpu0 configure -gdb-port disabled
+stm32mp15x.cpu1 configure -gdb-port disabled
+targets stm32mp15x.cm4

 reset_config srst_only

==============================================================================

But I think this may not be your original intention . Could you tell me how to directly use the cfg file(openocd.cfg) in zephyr project and make all things right . By the way , I try that :

1. cd <SDK installation directory>  // The stm32mp1 developer package which I download from stm32 official website
2. source environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi  // I also try without this setp
3. ./sysroots/x86_64-ostl_sdk-linux/usr/bin/openocd -f <zephyr_prj_path>/boards/arm/stm32mp157c_dk2/support/openocd.cfg
4. west build -b stm32mp157c_dk2 samples/hello_world
5. west attach

And I will get the following output information :

Open On-Chip Debugger 0.10.0+dev-01131-gb5d2b12-dirty (2020-08-11-06:07)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.041553
Info : Unable to match requested speed 5000 kHz, using 4000 kHz
Info : Unable to match requested speed 5000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stm32mp15x.cm4: hardware has 6 breakpoints, 4 watchpoints
Info : stm32mp15x.cpu0: hardware has 6 breakpoints, 4 watchpoints
Info : stm32mp15x.cpu1: hardware has 6 breakpoints, 4 watchpoints
Info : stm32mp15x.cm4: external reset detected
Info : gdb port disabled
Info : gdb port disabled
Info : starting gdb server for stm32mp15x.cm4 on 3333
Info : Listening on port 3333 for gdb connections

Info : accepting 'gdb' connection on tcp/3333
Error: timed out while waiting for target halted
Error executing event gdb-attach on target stm32mp15x.cm4:

Info : New GDB Connection: 1, Target stm32mp15x.cm4, state: reset
Info : Halt timed out, wake up GDB.

If I have any misunderstanding , please let me know , Thanks .

arnopo commented 1 year ago

my fault, I didn't clean the doc properly

With PR, you no longer have to use the stm32mp1 SDK for the openocd. west attach will load theopenocd. I also notice an error in my patch that not point to the openocd.cfg. So please reinitialize your environment out of the stm32mp1 SDK and reapply the updated PR. my output information:

Info : Unable to match requested speed 5000 kHz, using 4000 kHz
Info : Unable to match requested speed 5000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [stm32mp15x.cm4] Cortex-M4 r0p1 processor detected
Info : [stm32mp15x.cm4] target has 6 breakpoints, 4 watchpoints
Info : stm32mp15x.cpu0: hardware has 6 breakpoints, 4 watchpoints
Info : [stm32mp15x.cm4] external reset detected
Info : stm32mp15x.cpu1: hardware has 6 breakpoints, 4 watchpoints
Info : gdb port disabled
Info : gdb port disabled
Info : gdb port disabled
Info : gdb port disabled
Info : gdb port disabled
Info : starting gdb server for stm32mp15x.cm4 on 3333
Info : Listening on port 3333 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0  stm32mp15x.ap1     mem_ap     little stm32mp15x.tap     running
 1  stm32mp15x.ap2     mem_ap     little stm32mp15x.tap     running
 2  stm32mp15x.axi     mem_ap     little stm32mp15x.tap     running
 3  stm32mp15x.cpu0    cortex_a   little stm32mp15x.tap     running
 4  stm32mp15x.cpu1    cortex_a   little stm32mp15x.tap     running
 5* stm32mp15x.cm4     cortex_m   little stm32mp15x.tap     running

target halted due to debug-request, current mode: Thread 
xPSR: 0x41000000 pc: 0x00001272 psp: 0x10001070
Info : Listening on port 6333 for tcl connections
Info : Listening on port 4444 for telnet connections
Remote debugging using :3333
Info : accepting 'gdb' connection on tcp/3333
Info : New GDB Connection: 1, Target stm32mp15x.cm4, state: halted
arch_cpu_idle () at /local/home/frq07267/views/zephyrproject/zephyr/arch/arm/core/aarch32/cpu_idle.S:105
105     cpsie   i

zeyingzheng-linux commented 1 year ago

Thanks for your reminder, after patching PR , it works fine with command west attach if I don't use stm32mp1 SDK.

And sometimes, I want to use command west debug, so that I can set up a breakpoint in a boottime function such as “z_arm_prep_c”. But there will be different behaviors whether I using stm32mp1 SDK . pls let me show you :

version use stm32mp1 SDK : 1) Preload firmware 2) Start openocd with stm32mp1 SDK first 3) Use command west debug 4) Everything works fine

-- west debug: rebuilding
ninja: no work to do.
-- west debug: using runner openocd
-- runners.openocd: OpenOCD GDB server running on port 3333; no thread info available
Open On-Chip Debugger 0.11.0+dev-00725-gc5c47943d-dirty (2022-10-03-06:14)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html

GNU gdb (Zephyr SDK 0.15.1) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/zephyrproject-rtos/sdk-ng/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/build/zephyr/zephyr.elf...
Remote debugging using :3333
arch_cpu_idle () at /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/arch/arm/core/aarch32/cpu_idle.S:105
105     cpsie   i
Loading section rom_start, size 0x298 lma 0x0
Loading section text, size 0xb4e4 lma 0x298
Loading section .ARM.exidx, size 0x8 lma 0xb77c
Loading section initlevel, size 0xb8 lma 0xb784
Loading section devices, size 0x180 lma 0xb83c
Loading section sw_isr_table, size 0x4b0 lma 0xb9bc
Loading section device_handles, size 0x98 lma 0xbe6c
Loading section log_const_sections, size 0x48 lma 0xbf04
Loading section log_backend_area, size 0x10 lma 0xbf4c
Loading section shell_area, size 0x30 lma 0xbf5c
Loading section shell_root_cmds_sections, size 0x24 lma 0xbf8c
Loading section shell_subcmds_sections, size 0x14 lma 0xbfb0
Loading section shell_dynamic_subcmds_sections, size 0xc lma 0xbfc4
Loading section rodata, size 0x2358 lma 0xbfd0
Loading section datas, size 0xec lma 0xe328
Loading section device_states, size 0x20 lma 0xe414
Loading section log_mpsc_pbuf_area, size 0x40 lma 0xe434
Loading section log_msg_ptr_area, size 0x4 lma 0xe474
Loading section log_dynamic_sections, size 0x24 lma 0xe478
Loading section k_sem_area, size 0x18 lma 0xe49c
Loading section .last_section, size 0x4 lma 0xe4b4
Start address 0x00004fdc, load size 58552
Transfer rate: 71 KB/sec, 2545 bytes/write.
(gdb) b samples/basic/blinky/src/main.c:40
Breakpoint 1 at 0xa92: file /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/samples/basic/blinky/src/main.c, line 40.
(gdb) n
120     msr BASEPRI, r0
(gdb) c
Continuing.

Breakpoint 1, main () at /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/samples/basic/blinky/src/main.c:40
40      ret = gpio_pin_configure_dt(&led_3, GPIO_OUTPUT_ACTIVE);
(gdb) q

version don't use stm32mp1 SDK : 1) Preload firmware 2) Use west debug command , I don't use stm32mp1 SDK this time .

There are two problems here :

<1> It took quite a while to get to the gdb command line <2> It will show "Invalid hex digit 79" when I first type command until I type `n` command twice , it starts to work fine ``` -- west debug: rebuilding ninja: no work to do. -- west debug: using runner openocd -- runners.openocd: OpenOCD GDB server running on port 3333; no thread info available Open On-Chip Debugger 0.11.0+dev-00725-gc5c47943d-dirty (2022-10-03-06:14) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.038860 GNU gdb (Zephyr SDK 0.15.1) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/build/zephyr/zephyr.elf... Info : Unable to match requested speed 5000 kHz, using 4000 kHz Info : Unable to match requested speed 5000 kHz, using 4000 kHz Info : clock speed 4000 kHz Info : stlink_dap_op_connect(connect) Info : SWD DPIDR 0x6ba02477 Info : stlink_dap_op_connect(connect) Info : SWD DPIDR 0x6ba02477 Info : [stm32mp15x.cm4] Cortex-M4 r0p1 processor detected Info : [stm32mp15x.cm4] target has 6 breakpoints, 4 watchpoints Info : stm32mp15x.cpu0: hardware has 6 breakpoints, 4 watchpoints Info : [stm32mp15x.cm4] external reset detected Info : stm32mp15x.cpu1: hardware has 6 breakpoints, 4 watchpoints Info : gdb port disabled Info : gdb port disabled Info : gdb port disabled Info : gdb port disabled Info : gdb port disabled Info : starting gdb server for stm32mp15x.cm4 on 3333 Info : Listening on port 3333 for gdb connections TargetName Type Endian TapName State -- ------------------ ---------- ------ ------------------ ------------ 0 stm32mp15x.ap1 mem_ap little stm32mp15x.tap running 1 stm32mp15x.ap2 mem_ap little stm32mp15x.tap running 2 stm32mp15x.axi mem_ap little stm32mp15x.tap running 3 stm32mp15x.cpu0 cortex_a little stm32mp15x.tap running 4 stm32mp15x.cpu1 cortex_a little stm32mp15x.tap running 5* stm32mp15x.cm4 cortex_m little stm32mp15x.tap running Remote debugging using :3333 target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x0000466e psp: 0x100025f0 Info : Listening on port 6333 for tcl connections Info : Listening on port 4444 for telnet connections Info : accepting 'gdb' connection on tcp/3333 Info : New GDB Connection: 1, Target stm32mp15x.cm4, state: halted arch_cpu_idle () at /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/arch/arm/core/aarch32/cpu_idle.S:105 105 cpsie i Loading section rom_start, size 0x298 lma 0x0 Loading section text, size 0xb4e4 lma 0x298 Ignoring packet error, continuing... Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (7388 ms). Workaround: increase "set remotetimeout" in GDB Loading section .ARM.exidx, size 0x8 lma 0xb77c Ignoring packet error, continuing... Loading section initlevel, size 0xb8 lma 0xb784 Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (7483 ms). Workaround: increase "set remotetimeout" in GDB Loading section devices, size 0x180 lma 0xb83c Ignoring packet error, continuing... Loading section sw_isr_table, size 0x4b0 lma 0xb9bc Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (6563 ms). Workaround: increase "set remotetimeout" in GDB Loading section device_handles, size 0x98 lma 0xbe6c Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Loading section log_const_sections, size 0x48 lma 0xbf04 Loading section log_backend_area, size 0x10 lma 0xbf4c Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Loading section shell_area, size 0x30 lma 0xbf5c Loading section shell_root_cmds_sections, size 0x24 lma 0xbf8c Loading section shell_subcmds_sections, size 0x14 lma 0xbfb0 Loading section shell_dynamic_subcmds_sections, size 0xc lma 0xbfc4 Loading section rodata, size 0x2358 lma 0xbfd0 Loading section datas, size 0xec lma 0xe328 Loading section device_states, size 0x20 lma 0xe414 Loading section log_mpsc_pbuf_area, size 0x40 lma 0xe434 Loading section log_msg_ptr_area, size 0x4 lma 0xe474 Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (4237 ms). Workaround: increase "set remotetimeout" in GDB Loading section log_dynamic_sections, size 0x24 lma 0xe478 Loading section k_sem_area, size 0x18 lma 0xe49c Loading section .last_section, size 0x4 lma 0xe4b4 Warn : negative acknowledgment, but no packet pending Warn : negative acknowledgment, but no packet pending Start address 0x00004fdc, load size 58552 Transfer rate: 2 KB/sec, 2545 bytes/write. (gdb) b samples/basic/blinky/src/main.c:40 Invalid hex digit 79 (gdb) n Invalid hex digit 79 (gdb) n warning: Invalid remote reply: 102080f3 warning: Invalid remote reply: 1020 warning: Invalid remote reply: vCont;c;C;s;S 120 msr BASEPRI, r0 (gdb) b samples/basic/blinky/src/main.c:40 Breakpoint 1 at 0xa92: file /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/samples/basic/blinky/src/main.c, line 40. (gdb) c Continuing. Breakpoint 1, main () at /home/book/100ask_stm32mp157_pro-sdk/zephyr/zephyrproject/zephyr/samples/basic/blinky/src/main.c:40 40 ret = gpio_pin_configure_dt(&led_3, GPIO_OUTPUT_ACTIVE); (gdb) q ``` Could you give me some advice ?

arnopo commented 1 year ago

I don't reproduce your issue on my board. seems strange that you use same openocd version in both case? I'm using Open On-Chip Debugger 0.11.0+dev-00724-g42b6471c1 (2022-08-17-18:23) provided in the Zephyr zephyr-sdk-0.15.0

zeyingzheng-linux commented 1 year ago

west debug command works fine in your environment, right ?

I used openocd provided in stm32mp1 SDK in first case :

Open On-Chip Debugger 0.10.0+dev-01131-gb5d2b12-dirty (2020-08-11-06:07)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html

And I used openocd provided in the zephyr-sdk-0.15.1 in second case :

Open On-Chip Debugger 0.11.0+dev-00725-gc5c47943d-dirty (2022-10-03-06:14)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html

And I use ST-LINK

Bus 002 Device 005: ID 0483:3748 STMicroelectronics ST-LINK/V2

If I replace the openocd bin file of case 2 with that of case 1 , I found openocd start fail :

0 Z book       3586   3581  0  80   0 -     0 -      22:21 ?        00:00:00 [openocd] <defunct>

I also try zephyr-sdk-0.15.0 and use the same openocd version as yours , But met the same issue in case 2

Open On-Chip Debugger 0.11.0+dev-00724-g42b6471c1 (2022-08-17-18:23)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html

arnopo commented 1 year ago

Did you try to update your stlink firmware? my STLink ( info get from the openocd logs) : STLINK V2J39M27 (API v2) VID:PID 0483:3752

zeyingzheng-linux commented 1 year ago

Did you try to update your stlink firmware? my STLink ( info get from the openocd logs) : STLINK V2J39M27 (API v2) VID:PID 0483:3752

I haven't tried to upgrade the firmware, here are STLink info capture from my openocd logs

Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748

Maybe I'll just change to another board or STLink. But I am confused why west debug works fine when I used openocd version from stm32mp1 SDK in case 1.

zephyrproject-rtos / zephyr

STM32MP157 Debugging method use wrong GDB port when execute command `west debug` #52094