Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
975 stars 236 forks source link

Won't start upload and debug, only builds code. #603

Closed MarioPL98 closed 2 years ago

MarioPL98 commented 2 years ago

Hi. I have pi pico connected to pi zero with openocd and exposed in lan. I'm trying to setup a remote dev env. I've installed all compiler and debugger stuff, cortex-debug in vsc and tried to run remote debug with launch.json provided in examples (changed ip of course). All examples have been built successfully (to disk) but when I try to debug, just nothing happends except rebuild.

You can see everything here: https://imgur.com/XR8jaHW Version is latest from vs code extension market. When I click debug it just builds the file. For a brief moment debug controls appear at the top but they disappear when the build finishes. Nothing is send to the pi zero or pi pico. I assume it should flash pi pico remotely but it doesn't even try to connect to openocd.

What am I doing wrong? Why does it only build and doesn't even attempt to deploy and debug?

haneefdm commented 2 years ago

There may be several issues. OpenOCD may not have actually opened a port for your LAN. Normally (for security), it only opens TCP ports for a local machine unless you use the bindto command

Config Command: bindto [name]
Specify hostname or IPv4 address on which to listen for incoming TCP/IP connections. By default,
OpenOCD will listen on the loopback interface only. If your network environment is safe, bindto
0.0.0.0 can be used to cover all available interfaces.

Like any TCL command, you can use it from the command line like -c "bindto \"0.0.0.0\"". Not sure if backslashes or quotes are needed around 0.0.0.0.

Based on the image, I can't tell what is going on. We don't use the output window in any way. What we use is the Debug Console. We have nothing to do with a build. That is between VSCode and your build tasks/scripts.

MarioPL98 commented 2 years ago

Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2 "[C:\Users\Mario\Desktop\pi-dev\pico-examples\build\blink\blink.elf]()"
1-gdb-set target-async on
Reading symbols from arm-none-eabi-objdump.exe --syms -C -h -w [C:\Users\Mario\Desktop\pi-dev\pico-examples\build\blink\blink.elf]()
Reading symbols from arm-none-eabi-nm.exe --defined-only -S -l -C -p [C:\Users\Mario\Desktop\pi-dev\pico-examples\build\blink\blink.elf]()
Reading symbols from objdump: Time: 170 ms
Reading symbols from nm: Time: 193 ms
2-exec-interrupt
Could not interrupt program. Trying to end session anyways TypeError: Cannot read property 'stdin' of null
GDB never responded to an interrupt request. Trying to end session anyways
3-break-delete
Could not delete all breakpoints. TypeError: Cannot read property 'stdin' of null
4-target-detach

This is what I get now in debug console. Weirdly enough there were only 3 completely different lines here before. I must have done something so it changed. Maybe because I have switched to the preview version.

Openocd still doesn't show any signs of attempted connection.

MarioPL98 commented 2 years ago

Is there anything else I can post to help diagnosing this issue?

haneefdm commented 2 years ago

I am trying to reproduce what you have. Did you start the gdbserver (openocd) with the bindto. The output you show make no sense if you are using an "external" server (doesn't matter if you use openocd or something else).

haneefdm commented 2 years ago

It appears you are no longer using "external" type server?

haneefdm commented 2 years ago

Can you post your launch.json please?

haneefdm commented 2 years ago

It appears your gdb probably exited even before it can get started? But the following does not make sense.

2-exec-interrupt

I see no responses back from gdb at all. We don't send a request for interrupt before we initialize a few things. On one server type yes but not for "external" or "openocd"

haneefdm commented 2 years ago

With "showDevDebugOutput": "raw", I would expect the Debug Console to look something like the following...if you are using the external type server and the latest pre-release. Your output looks nothing like that. Not even close.

Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2 /Users/hdm/STM32CubeIDE/workspace_1.1.0/firststm/Debug/firststm.elf
1-gdb-set target-async on
Reading symbols from arm-none-eabi-objdump --syms -C -h -w /Users/hdm/STM32CubeIDE/workspace_1.1.0/firststm/Debug/firststm.elf
Reading symbols from arm-none-eabi-nm --defined-only -S -l -C -p /Users/hdm/STM32CubeIDE/workspace_1.1.0/firststm/Debug/firststm.elf
Reading symbols from objdump: Time: 18 ms
-> undefined=thread-group-added,id="i1"
-> ~"Reading symbols from /Users/hdm/STM32CubeIDE/workspace_1.1.0/firststm/Debug/firststm.elf...\n"
Reading symbols from /Users/hdm/STM32CubeIDE/workspace_1.1.0/firststm/Debug/firststm.elf...
-> 1^done
2-gdb-version
Reading symbols from nm: Time: 24 ms
-> ~"GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.07) 10.2.90.20210621-git\n"
-> ~"Copyright (C) 2021 Free Software Foundation, Inc.\n"
-> ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law."
-> ~"\nType \"show copying\" and \"show warranty\" for details.\n"
-> ~"This GDB was configured as \"--host=x86_64-apple-darwin10 --target=arm-none-eabi\".\n"
-> ~"Type \"show configuration\" for configuration details.\n"
-> ~"For bug reporting instructions, please see:\n"
-> ~"<https://www.gnu.org/software/gdb/bugs/>.\n"
-> ~"Find the GDB manual and other documentation resources online at:\n    <http://www.gnu.org/software/gdb/documentation/>."
-> ~"\n\n"
-> ~"For help, type \"help\".\n"
-> ~"Type \"apropos word\" to search for commands related to \"word\".\n"
-> 2^done
3-interpreter-exec console "set print demangle on"
4-interpreter-exec console "set print asm-demangle on"
-> 3^done
-> =cmd-param-changed,param="print asm-demangle",value="on"
-> 4^done
5-interpreter-exec console "source /Users/hdm/.vscode/extensions/marus25.cortex-debug-1.3.4/support/gdbsupport.init"
6-interpreter-exec console "source /Users/hdm/.vscode/extensions/marus25.cortex-debug-1.3.4/support/gdb-swo.init"
7-target-select extended-remote 192.168.1.4:123
8-interpreter-exec console "monitor reset halt"
9-target-download
10-interpreter-exec console "monitor reset halt"
11-enable-pretty-printing
-> 5^done
-> =cmd-param-changed,param="language",value="c"
-> =cmd-param-changed,param="language",value="auto"
-> 6^done
-> 7^error,msg="192.168.1.4:123: Operation timed out."

And here is my launch.json (there is no actual server running on "192.168.1.4:123")

        {
            "cwd": "${workspaceRoot}",
            "executable": "./Debug/firststm.elf",
            "name": "External",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "main",
            "showDevDebugOutput": "raw",
            "servertype": "external",
            "gdbTarget": "192.168.1.4:123"
        },
MarioPL98 commented 2 years ago
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug",
            "type":"cortex-debug",
            "cwd": "${workspaceRoot}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "servertype": "external",
            // This may need to be arm-none-eabi-gdb depending on your system
            "gdbPath" : "arm-none-eabi-gdb", 
            // Connect to an already running OpenOCD instance
            "gdbTarget": "192.168.1.36:3333",
            "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
            "runToEntryPoint": "main",
            // Work around for stopping at main on restart
            "postRestartCommands": [
                "break main",
                "continue"
            ],
            "showDevDebugOutput": "parsed",
        }
    ]
}

This is my launch.json. I'm going to set showDevDebugOutput to raw and check again.

MarioPL98 commented 2 years ago

This is my debug console output after changing to raw output, looks same as before:

Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2 "[C:\Users\Mario\Desktop\pi-dev\pico-examples\build\blink\blink.elf]()" 1-gdb-set target-async on Reading symbols from arm-none-eabi-objdump.exe --syms -C -h -w [C:\Users\Mario\Desktop\pi-dev\pico-examples\build\blink\blink.elf]() Reading symbols from arm-none-eabi-nm.exe --defined-only -S -l -C -p [C:\Users\Mario\Desktop\pi-dev\pico-examples\build\blink\blink.elf]() Reading symbols from objdump: Time: 138 ms Reading symbols from nm: Time: 153 ms 2-exec-interrupt Could not interrupt program. Trying to end session anyways TypeError: Cannot read property 'stdin' of null GDB never responded to an interrupt request. Trying to end session anyways 3-break-delete Could not delete all breakpoints. TypeError: Cannot read property 'stdin' of null 4-target-detach

MarioPL98 commented 2 years ago

If you want me to, we can meet on some text/voice chat and I can share you my screen if that helps you finding the issue.

Also, I checked my pico<->zero connection and everything seems to be working fine. If netstat doesn't lie, I have 0.0.0.0:3333 and couple others listening.

image

There also seems to be no errors in openocd. If I disconnect any of the swd pins, I get logical errors. Otherwise no issues. image

MarioPL98 commented 2 years ago

I just discovered that gdb does segfault. Trying to fix it now.

MarioPL98 commented 2 years ago

image But the python works... image I tried to gdb arm-none-eabi-gdb: image

MarioPL98 commented 2 years ago

image 32 bit gdb and python also has this problem

MarioPL98 commented 2 years ago

Turns out this is a known Issue. https://github.com/msys2/MINGW-packages/issues/6997 I installed this: https://packages.msys2.org/package/mingw-w64-x86_64-gdb-multiarch Instead of mingw-w64-x86_64-arm-none-eabi-gdb, which is much older. Everything seems to work fine with mingw-w64-x86_64-gdb-multiarch. Issue can be closed.

haneefdm commented 2 years ago

Well, that is huge progress and good digging. My suggestions.

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

haneefdm commented 2 years ago

Oh, you got it solved Good. But my recommendation still stands Always use the ones release by ARM

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

It is not just gdb. Objdump, nm also have to work properly.