Unable to launch second GDB debug session with "chainedConfigurations"

[Nekspire]

Hello, I'm trying to debug multicore microcontroller STM32H745ZIT6. What i would like to achive is to have a separate windows for simultaneously debugging core M7 and core M4. Right now i'm only able to flash corectlly both of the cores and debug core M7, but unfortunately i have an issue with debug core M4.

The debug console says that:

Failed to launch GDB: localhost:50001: Connection timed out. (from target-select extended-remote localhost:50001)

launch.json

"version": "0.2.0",
"configurations": [
    {
        "type": "cortex-debug",
        "request": "launch",
        "name": "Debug OpenOCD CM7",
        "servertype": "openocd",
        "gdbPath": "arm-none-eabi-gdb.exe",
        "cwd": "${workspaceRoot}",
        "executable": "./build_cm7/stm32h745zit6_template_cm7.elf",
        "loadFiles": [
            "./build_cm7/stm32h745zit6_template_cm7.elf",
            "./build_cm4/stm32h745zit6_template_cm4.elf"
        ],
        "interface": "swd",
        "device": "STM32H745ZI",
        "configFiles": [
            "interface/stlink.cfg",
            "target/stm32h7x.cfg"
        ],
        "svdFile": "subprojects/mxgen/STM32H745_CM7.svd",

        "numberOfProcessors": 2,
        "targetProcessor": 0,
        "chainedConfigurations": {
            "enabled": true,
            "waitOnEvent": "postInit",
            "lifecycleManagedByParent": true,
            "launches": [                          
                {
                    "name": "Debug OpenOCD CM4",
                    "folder": "${workspaceRoot}"
                }
            ]
        },
    },

    {
        "type": "cortex-debug",
        "request": "launch",
        "name": "Debug OpenOCD CM4",
        "servertype": "openocd",
        "gdbPath": "arm-none-eabi-gdb.exe",
        "cwd": "${workspaceRoot}",
        "executable": "./build_cm4/stm32h745zit6_template_cm4.elf",
        "interface": "swd",
        "device": "STM32H745ZI",
        "configFiles": [
            "interface/stlink.cfg",
            "target/stm32h7x.cfg"
        ],
        "svdFile": "subprojects/mxgen/STM32H745_CM4.svd",

        "numberOfProcessors": 2,
        "targetProcessor": 1,
    },
]

[haneefdm]

The whole chained configurations and even VSCode's own Launch Groups are for doing it all in one Windows. If you have separate windows, you have to start two separate VSCodes (in separate directories).

Also, look in the OpenOCD output window (gdb-server terminal window) and see what it did. Did it start two servers on 50000 and 50001 respectively? If not something is wrong. Maybe ST doesn't not support this. This part is not up to us. But please attach the output of OpenOCD regardless.

Finally, If you use chained configs, try doing an "request": "attach" instead. But first, we gotta establish connection between gdb and openocd which is what is failing for you.

[Nekspire]

Hello @haneefdm, thanks for respond.

The whole chained configurations and even VSCode's own Launch Groups are for doing it all in one Windows. If you have separate windows, you have to start two separate VSCodes (in separate directories).

Yeah i wanted say that i would like to have just an option do debug both of the cores simultaneously (not in saparate windows), so thats why i'm trying to use chained configuration.

Also, look in the OpenOCD output window (gdb-server terminal window) and see what it did. Did it start two servers on 50000 and 50001 respectively? If not something is wrong. Maybe ST doesn't not support this. This part is not up to us. But please attach the output of OpenOCD regardless.

The OpenOCD output says that:

[2022-06-01T15:51:42.277Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
openocd.exe -c "gdb_port 50000" -c "tcl_port 50002" -c "telnet_port 50004" -s "D:\\programming\\vscode\\embedded\\stm32h745zit6_template" -f "c:/Users/jwoli/.vscode/extensions/marus25.cortex-debug-1.4.4/support/openocd-helpers.tcl" -f interface/stlink.cfg -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50002 for tcl connections
Info : Listening on port 50004 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V3J9M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.293992
Info : stm32h7x.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 50000
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0x24000f68
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Padding image section 0 at 0x08000298 with 40 bytes
Info : Padding image section 1 at 0x08014e1c with 4 bytes (bank write end alignment)
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08003198 msp: 0x24080000
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08003198 msp: 0x24080000
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Padding image section 0 at 0x08100298 with 40 bytes
Info : Padding image section 1 at 0x0811285c with 4 bytes (bank write end alignment)
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08003198 msp: 0x24080000
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08003198 msp: 0x24080000

Finally, If you use chained configs, try doing an "request": "attach" instead. But first, we gotta establish connection between gdb and openocd which is what is failing for you.

Surprisingly, today I've tried to run the same configuration on PyOCD with "attach" request and it does work. In case of OpenOCD adding "attach" didin't change anything. But the issue for PyOCD is that it cannot errase the flash after booting it again. It says something like this:

0001056 I Target type is stm32h745zitx [board]
0001260 I DP IDR = 0x6ba02477 (v2 rev6) [dap]
0001323 I AHB-AP#0 IDR = 0x84770001 (AHB-AP var0 rev8) [ap]
0001325 I AHB-AP#1 IDR = 0x84770001 (AHB-AP var0 rev8) [ap]
0001327 I APB-AP#2 IDR = 0x54770002 (APB-AP var0 rev5) [ap]
0001329 I AP#3 IDR = 0x00030003 (AP var0 rev0) [ap]
0001331 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fe000 (designer=020 part=450) [rom_table]
0001332 I [0]<e00ff000:ROM class=1 designer=43b part=4c7> [rom_table]
0001332 I   AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b part=4c7) [rom_table]
0001333 I   [0]<e000e000:SCS v7-M class=14 designer=43b part=00c> [rom_table]
0001334 I   [1]<e0001000:DWT v7-M class=14 designer=43b part=002> [rom_table]
0001334 I   [2]<e0002000:FPB v7-M class=14 designer=43b part=00e> [rom_table]
0001335 I   [3]<e0000000:ITM v7-M class=14 designer=43b part=001> [rom_table]
0001337 I [1]<e0041000:ETM M7 class=9 designer=43b part=975 devtype=13 archid=4a13 devid=0:0:0> [rom_table]
0001338 I [2]<e0043000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=40800:0:0> [rom_table]
0001339 I APB-AP#2 Class 0x1 ROM table #0 @ 0xe00e0000 (designer=020 part=450) [rom_table]
0001341 I [2]<e00e3000:SWO CS-400 class=9 designer=43b part=914 devtype=11 archid=0000 devid=ea0:0:0> [rom_table]
0001343 I [3]<e00e4000:CSTF class=9 designer=43b part=908 devtype=12 archid=0000 devid=32:0:0> [rom_table]
0001343 I [4]<e00e5000:TSGEN class=15 designer=43b part=101> [rom_table]
0001344 I [5]<e00f0000:ROM class=1 designer=020 part=001> [rom_table]
0001344 I   APB-AP#2 Class 0x1 ROM table #1 @ 0xe00f0000 (designer=020 part=001) [rom_table]
0001346 I   [0]<e00f1000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=40800:0:0> [rom_table]
0001348 I   [2]<e00f3000:CSTF class=9 designer=43b part=908 devtype=12 archid=0000 devid=34:0:0> [rom_table]
0001349 I   [3]<e00f4000:ETF class=9 designer=43b part=961 devtype=32 archid=0000 devid=380:0:0> [rom_table]
0001350 I   [4]<e00f5000:TPIU class=9 designer=43b part=912 devtype=11 archid=0000 devid=a0:0:0> [rom_table]
0001351 I CPU core #0 is Cortex-M7 r1p1 [cortex_m]
0001354 I FPU present: FPv5-D16-M [cortex_m]
0001355 I 4 hardware watchpoints [dwt]
0001357 I 8 hardware breakpoints, 1 literal comparators [fpb]
0001368 I Semihost server started on port 50002 (core 0) [server]
0001405 I GDB server started on port 50000 (core 0) [gdbserver]
0003466 I Client connected to port 50000! [gdbserver]
0003494 I Attempting to load RTOS plugins [gdbserver]
0008089 E Unhandled exception in handle_message (b'v'): cannot read register r0 because core #0 is not halted [gdbserver]
Traceback (most recent call last):
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\builder.py", line 259, in _enable_read_access
    self.flash.init(self.flash.Operation.VERIFY)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\flash.py", line 252, in init
    raise FlashFailure('flash init failure', result_code=result)
pyocd.core.exceptions.FlashFailure: flash init failure (result code 0x8000000)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\gdbserver\gdbserver.py", line 423, in handle_message
    reply = handler(msg[msgStart:])
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\gdbserver\gdbserver.py", line 702, in v_command
    return self.flash_op(data)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\gdbserver\gdbserver.py", line 821, in flash_op
    self.flash_loader.commit()
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\loader.py", line 289, in commit
    perf = builder.program(chip_erase=chipErase,
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\builder.py", line 490, in program
    sector_erase_count, page_program_time = self._compute_sector_erase_pages_and_weight(fast_verify)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\builder.py", line 669, in _compute_sector_erase_pages_and_weight
    self._analyze_pages_with_partial_read()
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\builder.py", line 604, in _analyze_pages_with_partial_read
    self._enable_read_access()
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\builder.py", line 262, in _enable_read_access
    self.flash.init(self.flash.Operation.ERASE)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\flash.py", line 243, in init
    result = self._call_function_and_wait(self.flash_algo['pc_init'],
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\flash.py", line 620, in _call_function_and_wait
    return self.wait_for_completion(timeout=timeout)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\flash\flash.py", line 616, in wait_for_completion
    return self.target.read_core_register('r0')
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\core\soc_target.py", line 218, in read_core_register
    return self.selected_core_or_raise.read_core_register(id)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\coresight\cortex_m.py", line 971, in read_core_register
    regValue = self.read_core_register_raw(reg_info.index)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\coresight\cortex_m.py", line 988, in read_core_register_raw
    vals = self.read_core_registers_raw([reg])
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\coresight\cortex_m.py", line 1009, in read_core_registers_raw
    return self._base_read_core_registers_raw(reg_list)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\coresight\cortex_m.py", line 1023, in _base_read_core_registers_raw
    raise exceptions.CoreRegisterAccessError(
pyocd.core.exceptions.CoreRegisterAccessError: cannot read register r0 because core #0 is not halted
0008091 E Unexpected exception: a bytes-like object is required, not 'tuple' [gdbserver]
Traceback (most recent call last):
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\gdbserver\gdbserver.py", line 390, in _run_connection
    self.packet_io.send(resp)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\gdbserver\packet_io.py", line 83, in send
    self._write_packet(packet)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\gdbserver\packet_io.py", line 146, in _write_packet
    written = self._abstract_socket.write(packet)
  File "C:\Users\jwoli\AppData\Local\Programs\Python\Python310\lib\site-packages\pyocd\utility\sockets.py", line 58, in write
    return self.conn.send(data)
TypeError: a bytes-like object is required, not 'tuple'

I know that it's not related to Cortex Debug extension so i don't expect an anwser for this issue. I need to double check this.

[haneefdm]

Two problems I found -- both with OpenOCD and specific to how ST configures it.

1. First you have to enable DUAL_CORE. If you look in the stm32h7x.cfg file you will a dependence on that
2. The transport being used hla_swd does not support multi-core debug.

Problem 1 is solved by

            "openOCDPreConfigLaunchCommands": [
                "set DUAL_CORE 1"
            ],

Which results in

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Warning : hla does not support multicore debugging
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

I cannot solve any of these issues. I don't know what or how you are supposed to STLink-V3 + OpenOCD and have dual core debug working.

Hint: I generally look at STM32CubeIDE as to how it does things and copy paste stuff from there. They seem to be using something very different with their own version of OpenOCD but even with that, I have not been able to get a dual core debug working.

Their tutorial only talks about their own server which is the STLink-Server which is a replacement for OpenOCD. I would try STs own server

I am going to close this because thus far I have not found an issue with Cortex-Debug itself. If we cannot get things running even from the command-line we can't do with this extension. For chained launched to work, all the other SW and HW also has to work.

If you see an issue that I can look at I can re-open this

[Nekspire]

Yeah let's close the issue, atleast im able to debug it using pyOCD, which is also capable to perform multicore debug. Anyway, I appreciate your help and your suggestions to this topic. Thank you so much!