openocd-user — User support list for OpenOCD

[OpenOCD-user] help

[Elias P. <eli...@bs...>]

Hi,
I have a design with a custom RISC-V CPU in a Xilinx Alveo u280. With 
the AMD/Xilinx tool XSCT I can recognize the whole JTAG chain:
xsct% connect
tcfchan#0
xsct%
targets
   1  xcu280_u55c
      2  BSCAN JTAG
      3  00000000
   4  b1aaa07d

Nevertheless, with OpenOCD I can only see the FPGA device:
These are the different commands I have used and the error I am getting 
is always the same. I don´t know what else to try, any help will be 
appreciated.

Commands:
./src/openocd -c "debug_level 4" -c "adapter driver ftdi" -c "ftdi 
vid_pid 0x0403 0x6011" -c "transport select jtag" -c "ftdi layout_init 
0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" -c 
"jtag newtap auto0 tap -irlen 2 -expected-id 0x14b7d093" -c "jtag newtap 
op cpu -irlen 18 -expected-id 0xb1aaa07d"

./src/openocd -c "debug_level 4" -c "adapter driver ftdi" -c "ftdi 
vid_pid 0x0403 0x6011" -c "transport select jtag" -c "ftdi layout_init 
0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" -c 
"jtag newtap auto0 unknown0 -irlen 2 -expected-id 0x14b7d093" -c "jtag 
newtap op unknown1 -irlen 18 -expected-id 0xb1aaa07d"

./src/openocd -c "debug_level 4" -c "adapter driver ftdi" -c "ftdi 
vid_pid 0x0403 0x6011" -c "transport select jtag" -c "ftdi layout_init 
0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" -c 
"jtag newtap auto0 bs -irlen 2 -expected-id 0x14b7d093" -c "jtag newtap 
op bs -irlen 18 -expected-id 0xb1aaa07d"

Error:
ebug: 157 22 core.c:960 default_interface_jtag_execute_queue(): JTAG DR 
SCAN to DRPAUSE
Debug: 158 22 core.c:967 default_interface_jtag_execute_queue(): 96b 
out: ffffffffffffffffffffffff
Debug: 159 22 core.c:972 default_interface_jtag_execute_queue(): 96b  
in: ffffffffffffffff14b7d093
Debug: 160 22 core.c:978 default_interface_jtag_execute_queue(): JTAG 
TLR RESET to RESET
Info : 161 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
auto0.tap tap/device found: 0x14b7d093 (mfg: 0x049 (Xilinx), part: 
0x4b7d, ver: 0x1)
Debug: 162 22 jep106.c:22 jep106_table_manufacturer(): BUG: Caller 
passed out-of-range JEP106 ID!
Info : 163 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
op.unknown0 tap/device found: 0xffffffff (mfg: 0x7ff (<invalid>), part: 
0xffff, ver: 0xf)
Debug: 164 22 jep106.c:22 jep106_table_manufacturer(): BUG: Caller 
passed out-of-range JEP106 ID!
Warn : 165 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
op.unknown0       UNEXPECTED: 0xffffffff (mfg: 0x7ff (<invalid>), part: 
0xffff, ver: 0xf)
Error: 166 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
op.unknown0  expected 1 of 1: 0x01aaa07d (mfg: 0x03e (Oracle 
Corporation), part: 0x1aaa, ver: 0x0)


-- 
===================================================================
Elias A. Perdomo Hourné             | E-mail: eli...@bs...
Research Engineer                   |
Barcelona Supercomputing Center     | URL: http://www.bsc.es
Plaça Eusebi Güell, 1-3             |
08034 Barcelona, Spain              | Phone:  +34 93 4117373
===================================================================

cid:par...@bs...

WARNING / LEGAL TEXT: This message is intended only for the use of the 
individual or entity to which it is addressed and may contain 
information which is privileged, confidential, proprietary, or exempt 
from disclosure under applicable law. If you are not the intended 
recipient or the person responsible for delivering the message to the 
intended recipient, you are strictly prohibited from disclosing, 
distributing, copying, or in any way using this message. If you have 
received this communication in error, please notify the sender and 
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

Re: [OpenOCD-user] J-LINK problem

[Wojciech P. <wo...@pu...>]

sorry i simply got some eval board from ST to have ST-LINK, which works 
perfect.

On Tue, 26 Mar 2024, Tommy Murphy wrote:

> Oops - my reply crossed with Paul's but we're obviously thinking along similar lines... :⁠-⁠)
> 
>

Re: [OpenOCD-user] STLink problem

[Paul F. <fer...@gm...>]

Hi,

On Tue, Mar 26, 2024 at 03:40:19PM +0100, s.f...@bm... wrote:
> Tried to connect STlink V3PWR with CC26x2 from TI with the following command:

ST-LINK v3 firmware has some nasty anti-user features meant to inhibit
innovations by making it not work with non-ST targets. You can
consider trying to find an alternative firmware (CMSIS-DAP/DAPLink)
for that hardware.

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

Re: [OpenOCD-user] STLink problem

[<s.f...@bm...>]

Thanks. I’ll check them.

 

The -d3 output:

 

Open On-Chip Debugger 0.12.0 (2023-10-02) [https://github.com/sysprogs/openocd]

Licensed under GNU GPL v2

libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3

For bug reports, read

        http://openocd.org/doc/doxygen/bugs.html

User : 4 7 options.c:53 configuration_output_handler(): debug_level: 3User : 5 20 options.c:53 configuration_output_handler():

Debug: 6 30 options.c:234 add_default_dirs(): bindir=../../bin

Debug: 7 37 options.c:235 add_default_dirs(): pkgdatadir=../../share/openocd

Debug: 8 46 options.c:236 add_default_dirs(): exepath=C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin

Debug: 9 57 options.c:237 add_default_dirs(): bin2data=../share/openocd

Debug: 10 67 configuration.c:33 add_script_search_dir(): adding C:/Users/fisch/AppData/Roaming/OpenOCD

Debug: 11 78 configuration.c:33 add_script_search_dir(): adding C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/site

Debug: 12 94 configuration.c:33 add_script_search_dir(): adding C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/scripts

Debug: 13 113 command.c:152 script_debug(): command - ocd_find interface/stlink-dap.cfg

Debug: 14 131 configuration.c:88 find_file(): found C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/scripts/interface/stlink-dap.cfg

Debug: 15 156 command.c:152 script_debug(): command - adapter driver st-link

Debug: 16 168 command.c:152 script_debug(): command - st-link vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754 0x0483 0x3755 0x0483 0x3757

Debug: 17 199 command.c:152 script_debug(): command - transport select dapdirect_jtag

Debug: 18 212 adi_v5_dapdirect.c:177 dapdirect_jtag_select(): dapdirect_jtag_select()

User : 19 226 options.c:53 configuration_output_handler(): dapdirect_jtagUser : 20 238 options.c:53 configuration_output_handler():

Debug: 21 248 command.c:152 script_debug(): command - adapter speed 8000

Debug: 22 256 adapter.c:249 adapter_config_khz(): handle adapter khz

Debug: 23 267 adapter.c:213 adapter_khz_to_speed(): convert khz to adapter specific speed value

Debug: 24 278 adapter.c:213 adapter_khz_to_speed(): convert khz to adapter specific speed value

User : 25 290 options.c:53 configuration_output_handler(): adapter speed: 8000 kHzUser : 26 303 options.c:53 configuration_output_handler():

Debug: 27 313 command.c:152 script_debug(): command - ocd_find target/ti_cc26x2.cfg

Debug: 28 322 configuration.c:88 find_file(): found C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/scripts/target/ti_cc26x2.cfg

Debug: 29 339 command.c:152 script_debug(): command - ocd_find target/ti_cc26x0.cfg

Debug: 30 352 configuration.c:88 find_file(): found C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/scripts/target/ti_cc26x0.cfg

Debug: 31 373 command.c:152 script_debug(): command - ocd_find target/icepick.cfg

Debug: 32 387 configuration.c:88 find_file(): found C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/scripts/target/icepick.cfg

Debug: 33 408 command.c:152 script_debug(): command - ocd_find target/ti-cjtag.cfg

Debug: 34 422 configuration.c:88 find_file(): found C:/Xojo/VT1/VT1_TestStation1/OpenOCD-0.12.0/bin/../share/openocd/scripts/target/ti-cjtag.cfg

Debug: 35 446 command.c:152 script_debug(): command - jtag newtap cc26x2 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x4BA00477 -disable

Debug: 36 465 tcl.c:418 handle_jtag_newtap_args(): Creating New Tap, Chip: cc26x2, Tap: cpu, Dotted: cc26x2.cpu, 9 params

Debug: 37 481 core.c:1474 jtag_tap_init(): Created Tap: cc26x2.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf

Debug: 38 498 command.c:152 script_debug(): command - jtag configure cc26x2.cpu -event tap-enable icepick_c_tapenable cc26x2.jrc 0

Debug: 39 517 adi_v5_dapdirect.c:33 dapdirect_jtag_empty_command(): dapdirect_jtag_empty_command("configure")

Debug: 40 532 command.c:152 script_debug(): command - jtag newtap cc26x2 jrc -irlen 6 -ircapture 0x1 -irmask 0x3f -expected-id 0x0BB4102F -ignore-version

Debug: 41 552 tcl.c:418 handle_jtag_newtap_args(): Creating New Tap, Chip: cc26x2, Tap: jrc, Dotted: cc26x2.jrc, 9 params

Debug: 42 570 core.c:1474 jtag_tap_init(): Created Tap: cc26x2.jrc @ abs position 1, irlen 6, capture: 0x1 mask: 0x3f

Debug: 43 589 command.c:152 script_debug(): command - jtag configure cc26x2.jrc -event setup jtag tapenable cc26x2.cpu

Debug: 44 612 adi_v5_dapdirect.c:33 dapdirect_jtag_empty_command(): dapdirect_jtag_empty_command("configure")

Debug: 45 628 command.c:152 script_debug(): command - jtag configure cc26x2.jrc -event post-reset ti_cjtag_to_4pin_jtag cc26x2.jrc

Debug: 46 647 adi_v5_dapdirect.c:33 dapdirect_jtag_empty_command(): dapdirect_jtag_empty_command("configure")

Debug: 47 663 command.c:152 script_debug(): command - dap create cc26x2.dap -chain-position cc26x2.cpu

Debug: 48 678 command.c:152 script_debug(): command - target create cc26x2.cpu cortex_m -dap cc26x2.dap

Debug: 49 693 command.c:286 register_command(): command 'tpiu' is already registered

Debug: 50 701 command.c:286 register_command(): command 'rtt' is already registered

Debug: 51 713 command.c:152 script_debug(): command - cc26x2.cpu configure -work-area-phys 0x20000000 -work-area-size 0x7000 -work-area-backup 0

Debug: 52 731 target.c:2171 target_free_all_working_areas_restore(): freeing all working areas

Debug: 53 745 target.c:2171 target_free_all_working_areas_restore(): freeing all working areas

Debug: 54 755 target.c:2171 target_free_all_working_areas_restore(): freeing all working areas

Debug: 55 770 command.c:152 script_debug(): command - flash bank cc26x2.flash cc26xx 0 0 0 0 cc26x2.cpu

Debug: 56 788 tcl.c:1306 handle_flash_bank_command(): 'cc26xx' driver usage field missing

Debug: 57 804 command.c:152 script_debug(): command - cortex_m reset_config vectreset

User : 58 818 options.c:53 configuration_output_handler(): cortex_m reset_config vectresetUser : 59 831 options.c:53 configuration_output_handler():

Info : 60 839 server.c:297 add_service(): Listening on port 6666 for tcl connections

Info : 61 854 server.c:297 add_service(): Listening on port 4444 for telnet connections

Debug: 62 869 command.c:152 script_debug(): command - init

Debug: 63 881 command.c:152 script_debug(): command - target init

Debug: 64 889 command.c:152 script_debug(): command - target names

Debug: 65 903 command.c:152 script_debug(): command - cc26x2.cpu cget -event gdb-flash-erase-start

Debug: 66 920 command.c:152 script_debug(): command - cc26x2.cpu configure -event gdb-flash-erase-start reset init

Debug: 67 942 command.c:152 script_debug(): command - cc26x2.cpu cget -event gdb-flash-write-end

Debug: 68 953 command.c:152 script_debug(): command - cc26x2.cpu configure -event gdb-flash-write-end reset halt

Debug: 69 967 command.c:152 script_debug(): command - cc26x2.cpu cget -event gdb-attach

Debug: 70 979 command.c:152 script_debug(): command - cc26x2.cpu configure -event gdb-attach halt 1000

Debug: 71 995 target.c:1629 handle_target_init_command(): Initializing targets...

Debug: 72 1006 semihosting_common.c:107 semihosting_common_init():

Debug: 73 1019 stlink_usb.c:5120 stlink_dap_init(): stlink_dap_init()

Debug: 74 1029 stlink_usb.c:3732 stlink_open(): stlink_open

Debug: 75 1037 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3744 serial:

Debug: 76 1050 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3748 serial:

Debug: 77 1063 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374b serial:

Debug: 78 1073 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374d serial:

Debug: 79 1086 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374e serial:

Debug: 80 1099 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374f serial:

Debug: 81 1113 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3752 serial:

Debug: 82 1129 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3753 serial:

Debug: 83 1138 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3754 serial:

Debug: 84 1153 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3755 serial:

Debug: 85 1169 stlink_usb.c:3744 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3757 serial:

Info : 86 1226 stlink_usb.c:1471 stlink_usb_version(): STLINK V4J2B1S0 (API v3) VID:PID 0483:3757

Debug: 87 1238 stlink_usb.c:1696 stlink_usb_exit_mode(): MODE: 0x01

Info : 88 1246 stlink_usb.c:1507 stlink_usb_check_voltage(): Target voltage: 3.263297

Debug: 89 1258 stlink_usb.c:1764 stlink_usb_init_mode(): MODE: 0x01

Debug: 90 1269 stlink_usb.c:3130 stlink_dump_speed_map(): Supported clock speeds are:

Debug: 91 1280 stlink_usb.c:3133 stlink_dump_speed_map(): 28571 kHz

Debug: 92 1291 stlink_usb.c:3133 stlink_dump_speed_map(): 20000 kHz

Debug: 93 1303 stlink_usb.c:3133 stlink_dump_speed_map(): 16666 kHz

Debug: 94 1312 stlink_usb.c:3133 stlink_dump_speed_map(): 12500 kHz

Debug: 95 1322 stlink_usb.c:3133 stlink_dump_speed_map(): 8000 kHz

Debug: 96 1333 stlink_usb.c:3133 stlink_dump_speed_map(): 2000 kHz

Debug: 97 1341 stlink_usb.c:3133 stlink_dump_speed_map(): 800 kHz

Debug: 98 1354 stlink_usb.c:1132 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x5

Error: 99 1368 stlink_usb.c:3787 stlink_open(): init mode failed (unable to connect to the target)

Debug: 100 1383 stlink_usb.c:1696 stlink_usb_exit_mode(): MODE: 0x01

Debug: 101 1396 command.c:541 run_command(): Command 'init' failed with error code -4

User : 102 1405 command.c:613 command_run_line():

Debug: 103 1415 target.c:2171 target_free_all_working_areas_restore(): freeing all working areas

 

BR Sebastian

 

From: Tommy Murphy <tom...@ho...> 
Sent: Tuesday, 26 March 2024 16:33
To: s.f...@bm...; ope...@li...
Subject: Re: [OpenOCD-user] STLink problem

 

Anything useful here?

 

* https://stackoverflow.com/questions/57628401/eclipse-error-init-mode-failed-unable-to-connect-to-the-target

* https://community.st.com/t5/stm32-mcus-wireless/getting-quot-error-init-mode-failed-unable-to-connect-to-the/td-p/109264

* https://community.platformio.org/t/stmf4discovery-board-init-mode-failed-unable-to-connect-to-the-target/22709

* https://github.com/platformio/platform-ststm32/issues/641 

 

If not, then the next step is most likely to provide a verbose `openocd -d3` log for your attempted debug session as it may shed more light on what's going on/wrong.

Re: [OpenOCD-user] STLink problem

[Tommy M. <tom...@ho...>]

Anything useful here?

* https://stackoverflow.com/questions/57628401/eclipse-error-init-mode-failed-unable-to-connect-to-the-target
* https://community.st.com/t5/stm32-mcus-wireless/getting-quot-error-init-mode-failed-unable-to-connect-to-the/td-p/109264
* https://community.platformio.org/t/stmf4discovery-board-init-mode-failed-unable-to-connect-to-the-target/22709
* https://github.com/platformio/platform-ststm32/issues/641

If not, then the next step is most likely to provide a verbose `openocd -d3` log for your attempted debug session as it may shed more light on what's going on/wrong.

[OpenOCD-user] STLink problem

[<s.f...@bm...>]

Tried to connect STlink V3PWR with CC26x2 from TI with the following command:

openocd.exe -f interface/stlink-dap.cfg -c "transport select dapdirect_jtag" -c "adapter speed 1000" -f target/ti_cc26x2.cfg

Open On-Chip Debugger 0.12.0 (2023-10-02) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
dapdirect_jtag
adapter speed: 1000 kHz
cortex_m reset_config vectreset
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V4J2B1S0 (API v3) VID:PID 0483:3757
Info : Target voltage: 3.261539
Error: init mode failed (unable to connect to the target)

Any idea whats wrong? Or is it not possible?

Re: [OpenOCD-user] J-LINK problem

[Tommy M. <tom...@ho...>]

Oops - my reply crossed with Paul's but we're obviously thinking along similar lines... :⁠-⁠)

Re: [OpenOCD-user] J-LINK problem

[Tommy M. <tom...@ho...>]

> tried a script
> #!/bin/sh program=openocd
> config=/usr/local/share/openocd/scripts/interface/jlink.cfg
> target=/usr/local/share/openocd/scripts/target/stm32g0x.cfg
> $program -f $config -f $target -c "init" -c "reset" -c "exit"
>
> got:
>
> Open On-Chip Debugger 0.12.0
> Licensed under GNU GPL v2
> For bug reports, read
>          http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag".  To override use 'transport select <transport>'.
> Error: No J-Link device found

Does a verbose `openocd -d3` provide any additional details?
Does `sudo openocd...` behave any differently?
What does `lsusb` show for the J-Link?
If you build OpenOCD from the latest source repository does it behave any differently?

Re: [OpenOCD-user] J-LINK problem

[Paul F. <fer...@gm...>]

Hi,

On Tue, Mar 26, 2024 at 11:41:28AM +0100, Wojciech Puchar wrote:
> Open On-Chip Debugger 0.12.0
> Licensed under GNU GPL v2
> For bug reports, read
> 	http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> Error: No J-Link device found

Hm, can you provide output from "lsusb -v" (or similar) and also full
OpenOCD log with -d3 ?

Feel free to join the IRC channel for a more interactive
troubleshooting.

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

[OpenOCD-user] J-LINK problem

[Wojciech P. <wo...@pu...>]

i have J-LINK (chinese copy, but works fine under J-LINK software under 
windows).
But i really don't want to use separate computer to program my 
microcontroller.
With ST-LINK openocd works fine. But i don't have ST-LINK at the moment.


Under FreeBSD J-LINK shows as:

Mar 26 11:37:55 laptop kernel: ugen0.8: <SEGGER J-Link> at usbus0
Mar 26 11:37:55 laptop kernel: umodem0 on uhub1
Mar 26 11:37:55 laptop kernel: umodem0: <CDC> on usbus0
Mar 26 11:37:55 laptop kernel: umodem0: data interface 1, has CM over data, has break

tried a script
#!/bin/sh program=openocd 
config=/usr/local/share/openocd/scripts/interface/jlink.cfg 
target=/usr/local/share/openocd/scripts/target/stm32g0x.cfg
$program -f $config -f $target -c "init" -c "reset" -c "exit"

got:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
 	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: No J-Link device found


any ideas?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

> I presume that other projects using VSCode to launch OpenOCD 0.12.0 debugging sessions use a `serverStarted` string/pattern that would suit your needs?

When I configured my vscode project with openocd 0.10.0, I took an example from the Internet which used the parameter
"serverStarted": "Info\ :\[\w\\.]*:\\\ hardware"

There are still some examples on various websites that use this parameter.I'm going to make one or two posts on these sites to point out the problem this causes when using openocd 0.12.0.

Re: [OpenOCD-user] problem with openocd 0.12.0

[Tommy M. <tom...@ho...>]

Great, glad you got it working Laurent.
It's a pity that VSCode doesn't seem to provide more useful/intelligible logging info helping to diagnose such issues.
I presume that other projects using VSCode to launch OpenOCD 0.12.0 debugging sessions use a `serverStarted` string/pattern that would suit your needs?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

by modifying serverStarted, everything works with openocd 0.12.0 !!
I'm lucky to have been able to get your help
Thank you all very much for your help.

On Wednesday, March 20th, 2024 at 17:59, Tommy Murphy <tom...@ho...> wrote:

> Thanks for clarifying the details, Paul.
> So, the VSCode `serverStarted` string/pattern would be changed or maybe generalised so that it works with different versions of OpenOCD.
> Or just changed to something that works with 0.12.0 onwards.

Re: [OpenOCD-user] problem with openocd 0.12.0

[Tommy M. <tom...@ho...>]

Thanks for clarifying the details, Paul.
So, the VSCode `serverStarted` string/pattern would be changed or maybe generalised so that it works with different versions of OpenOCD.
Or just changed to something that works with 0.12.0 onwards.

Re: [OpenOCD-user] problem with openocd 0.12.0

[Paul F. <fer...@gm...>]

Hey Tommy,

Your guess was spot-on, thank you!

On Wed, Mar 20, 2024 at 04:49:22PM +0000, Tommy Murphy wrote:
> I really meant the OpenOCD logs from running it standalone from the command
> line. Not the VSCode (?) log that seems to have other stuff interspersed. My
> hypothesis is that maybe whatever string/pattern that the VSCode debug
> configuration uses to detect that OpenOCD has started successfully is detected
> for 0.10.0 but not for 0.12.0 due to changes in between these two releases? 

>From v0.11.0-412-gba1061fe1 commit message:

Giving the example of STM32WL55x the examine log is the following:

Info : stm32wlx.cpu0: hardware has 6 breakpoints, 4 watchpoints
Info : stm32wlx.cpu1: hardware has 4 breakpoints, 2 watchpoints

After this change the examine log becomes:

Info : stm32wlx.cpu0: Cortex-M4 r0p1 processor detected
Info : stm32wlx.cpu0: target has 6 breakpoints, 4 watchpoints
Info : stm32wlx.cpu1: Cortex-M0+ r0p1 processor detected
Info : stm32wlx.cpu1: target has 4 breakpoints, 2 watchpoints


Found this by doing
$ git log -S ": hardware"

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

Re: [OpenOCD-user] problem with openocd 0.12.0

[Tommy M. <tom...@ho...>]

I really meant the OpenOCD logs from running it standalone from the command line. Not the VSCode (?) log that seems to have other stuff interspersed. My hypothesis is that maybe whatever string/pattern that the VSCode debug configuration uses to detect that OpenOCD has started successfully is detected for 0.10.0 but not for 0.12.0 due to changes in between these two releases?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

for openocd 0.10.0:

openocd: xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-20:30)
openocd: Licensed under GNU GPL v2
openocd: For bug reports, read
openocd: http://openocd.org/doc/doxygen/bugs.html
openocd: Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
openocd: srst_only separate srst_nogate srst_open_drain connect_deassert_srst
openocd:
openocd: Info : Listening on port 6666 for tcl connections
openocd: Info : Listening on port 4444 for telnet connections
openocd: Info : clock speed 2000 kHz
openocd: Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
openocd: Info : Target voltage: 2.897638
=thread-group-added,id="i1"
GNU gdb (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.1.90.20221210-git
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-apple-darwin19.6.0 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
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".g
openocd: Info : STM32F417IGH6.cpu: hardware has 6 breakpoints, 4 watchpoints
openocd: Info : starting gdb server for STM32F417IGH6.cpu on 3333
openocd: Info : Listening on port 3333 for gdb connections
openocd: Info : accepting 'gdb' connection on tcp/3333
openocd: Info : device id = 0x10076413
openocd: Info : flash size = 1024 kbytes
openocd: Info : flash size = 512 bytes
openocd: Warn : Prefer GDB command "target extended-remote 3333" instead of "target remote 3333"
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: target halted due to debug-request, current mode: Thread
openocd: xPSR: 0x01000000 pc: 0x080e01d8 msp: 0x20020000
=cmd-param-changed,param="pagination",value="off"
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: target halted due to debug-request, current mode: Thread
openocd: xPSR: 0x01000000 pc: 0x080e01d8 msp: 0x20020000
openocd: Info : Unable to match requested speed 8000 kHz, using 4000 kHzopenocd: Info : Unable to match requested speed 8000 kHz, using 4000 kHz

for openocd 0.12.0, the logs are in the previous mail

On Wednesday, March 20th, 2024 at 17:33, Tommy Murphy <tom...@ho...> wrote:

> What is the (non-verbose - i.e. no need for `-d3`) output from your OpenOCD 0.10.0 and 0.12.0?
>
> I wonder if the `serverStarted` pattern isn't being matched in the latter case and so VSCode doesn't detect that it's running? Perhaps the startup output changed between 0.10.0 and 0.12.0?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

> Perhaps one of these settings needs tweaking for 0.12.0?
>
>> "serverStarted": "Info\\ :\\ [\\w\\d\\.]*:\\ hardware",

Ok I remove this, and I have the log for openocd:

openocd: Open On-Chip Debugger 0.12.0
openocd: Licensed under GNU GPL v2
openocd: For bug reports, read
openocd: http://openocd.org/doc/doxygen/bugs.html
openocd: Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
openocd: srst_only separate srst_nogate srst_open_drain connect_deassert_srst
openocd:
openocd: Info : Listening on port 6666 for tcl connections
openocd: Info : Listening on port 4444 for telnet connections
openocd: Info : clock speed 2000 kHz
openocd: Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
openocd: Info : Target voltage: 2.896063
openocd: Info : [STM32F417IGH6.cpu] Cortex-M4 r0p1 processor detected
openocd: Info : [STM32F417IGH6.cpu] target has 6 breakpoints, 4 watchpoints
openocd: Info : starting gdb server for STM32F417IGH6.cpu on 3333
openocd: Info : Listening on port 3333 for gdb connections
=thread-group-added,id="i1"
GNU gdb (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.1.90.20221210-git
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-apple-darwin19.6.0 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
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".
openocd: Info : accepting 'gdb' connection on tcp/3333
openocd: [STM32F417IGH6.cpu] halted due to debug-request, current mode: Thread
openocd: xPSR: 0x41000000 pc: 0x080688ea msp: 0x2001ffe0
openocd: Info : device id = 0x10076413
openocd: Info : flash size = 1024 KiB
openocd: Info : flash size = 512 bytes
openocd: Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: [STM32F417IGH6.cpu] halted due to debug-request, current mode: Thread
openocd: xPSR: 0x01000000 pc: 0x080e01d8 msp: 0x20020000
=cmd-param-changed,param="pagination",value="off"
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: Info : Unable to match requested speed 2000 kHz, using 1800 kHz
openocd: [STM32F417IGH6.cpu] halted due to debug-request, current mode: Thread
openocd: xPSR: 0x01000000 pc: 0x080e01d8 msp: 0x20020000
openocd: Info : Unable to match requested speed 8000 kHz, using 4000 kHzopenocd: Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Re: [OpenOCD-user] problem with openocd 0.12.0

[Tommy M. <tom...@ho...>]

What is the (non-verbose - i.e. no need for `-d3`) output from your OpenOCD 0.10.0 and 0.12.0?

I wonder if the `serverStarted` pattern isn't being matched in the latter case and so VSCode doesn't detect that it's running? Perhaps the startup output changed between 0.10.0 and 0.12.0?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

> That suggests that the issue is one of misconfiguration of the VSCode debug launcher rather than any issue with OpenOCD (0.12.0 versus 0.10.0) per se? What is the JSON for your 0.10.0 and 0.12.0 configurations?

You're probably right, but I'm using the same configuration for openocd 10 and openocd 12. I've only changed the path, and I check the path, the path is good.

Here is the json used in vscode:

{
"version": "0.2.0",
"configurations": [
{
"name": "DEBUG-MCU",
"type": "cppdbg",
"request": "launch",
"program": "/path/to/executable.elf",
"setupCommands": [
{
"text": "target remote localhost:3333",
},
{
"text": "file /path/to/executable.elf",
},
{
"text": "monitor reset halt",
}
],
"customLaunchSetupCommands": [
{
"text": "monitor reset init",
}
],
"launchCompleteCommand": "exec-continue",
"MIMode": "gdb",
"targetArchitecture": "ARM",
"cwd": "${workspaceRoot}",
"miDebuggerServerAddress": "127.0.0.1:3333",
"debugServerArgs": "-f board/stm3241g_eval_stlink.cfg",
"serverLaunchTimeout": 20000,
"serverStarted": "Info\\ :\\ [\\w\\d\\.]*:\\ hardware",
"filterStderr": true,
"filterStdout": true,
"externalConsole": true,
"logging": {
"natvisDiagnostics": true,
"traceResponse": true,
"moduleLoad": true,
"trace": true,
"engineLogging": true,
"programOutput": true,
"exceptions": true
},
"stopAtEntry": true,
"miDebuggerPath": "/usr/local/bin/arm-none-eabi-gdb",
"debugServerPath": "/usr/local/Cellar/open-ocd/0.12.0_1/bin/openocd"
}
]}

>

Re: [OpenOCD-user] problem with openocd 0.12.0

[Tommy M. <tom...@ho...>]

Perhaps one of these settings needs tweaking for 0.12.0?

> "serverLaunchTimeout": 20000,
> "serverStarted": "Info\\ :\\ [\\w\\d\\.]*:\\ hardware",

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

Hi Paul,

Thanks for your answers.

> > Starting: "/path/to/openocd" -f board/stm3241g_eval_stlink.cfg
> 
> 
> This doesn't look like a real path, do you really have OpenOCD binary there?

Yes, it was me who changed the path to avoid giving a too long path. The path is good, I checked when I use openocd 10 and when I use openocd 12.

> That's not something OpenOCD can print, so that's not a log from OpenOCD.
Yes but it's the log printing by vscode. I don't known where to find the log of openocd in vscode. Do you know how to get it back?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Tommy M. <tom...@ho...>]

> You're right, by executing openocd via a terminal and disabling the launch of openocd in vscode, I was able to debug my executable.

That suggests that the issue is one of misconfiguration of the VSCode debug launcher rather than any issue with OpenOCD (0.12.0 versus 0.10.0) per se? What is the JSON for your 0.10.0 and 0.12.0 configurations?

Re: [OpenOCD-user] problem with openocd 0.12.0

[Paul F. <fer...@gm...>]

Hi Laurent,

On Wed, Mar 20, 2024 at 02:25:29PM +0000, Laurent wrote:
> here are the logs to which vscode gives me access:
> Starting: "/path/to/openocd" -f board/stm3241g_eval_stlink.cfg

This doesn't look like a real path, do you really have OpenOCD binary there?

> --> E (output):
> {"type":"event","event":"output","body":{"category":"console","output":"1:
> (20316) <-logout\n"},"seq":8}
> --> E (output):
> {"type":"event","event":"output","body":{"category":"console","output":"1:
> (20383) Send Event AD7MessageEvent\n"},"seq":10}
> 1: (20383) Send Event AD7MessageEvent

That's not something OpenOCD can print, so that's not a log from OpenOCD.

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

Re: [OpenOCD-user] problem with openocd 0.12.0

[Laurent <lau...@pr...>]

Thank you for your prompt reply. I've put the logs displayed by vscode at the end of the message.

What happens if you try running OpenOCD 0.12.0 standalone from the command line using `openocd -f board/stm3241g_eval_stlink.cfg`?

You're right, by executing openocd via a terminal and disabling the launch of openocd in vscode, I was able to debug my executable.

However, I can't understand why it works with version 10 of openocd and not version 12... do you have any ideas?

here are the logs to which vscode gives me access:
Starting: "/path/to/openocd" -f board/stm3241g_eval_stlink.cfg
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (20316) <-logout\n"},"seq":8}
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (20383) Send Event AD7MessageEvent\n"},"seq":10}
1: (20383) Send Event AD7MessageEvent
--> E (output): {"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/Launch","data":{"VS.Diagnostics.Debugger.ImplementationName":"Microsoft.MIDebugEngine","VS.Diagnostics.Debugger.EngineVersion":"17.8.20302.1","VS.Diagnostics.Debugger.HostVersion":"17.8.20302.1","VS.Diagnostics.Debugger.AdapterId":"cppdbg","VS.Diagnostics.Debugger.Launch.ErrorCode":1005,"VS.Diagnostics.Debugger.Launch.IsError":true}},"seq":12}--> R (launch-2): {"type":"response","request_seq":2,"success":false,"command":"launch","message":"Unable to start debugging. Debug server process failed to initialize.","body":{"error":{"id":1005,"format":"Unable to start debugging. Debug server process failed to initialize."}},"seq":14}
On Wednesday, March 20th, 2024 at 12:40, Tommy Murphy <tom...@ho...> wrote:

> Sounds like the VSCode attempt to run OpenOCD 0.12.0 fails for some reason. Does VSC provide any further logging or the option to get more details?
>
> What happens if you try running OpenOCD 0.12.0 standalone from the command line using `openocd -f board/stm3241g_eval_stlink.cfg`?