cortex-debug: Target hangs and becomes unresponsive when debugging under cortex-debug, but works fine with JLinkGDBServer+arm-none-eabi-gdb

Title says it all. I have tons of reliability issues with the VSCode extension, most notably manifested in the target “hanging” - i.e. unresponsive to pause/step/monitor commands issued by the GUI. I am usually able to debug the target for a bit, but once I start using the pause/step/continue commands, the target more often than not hangs. When I debug the exact same binary using the JLinkGDBServer and arm-none-eabi-gdb everything works fine.

I can send you a tarball or zip file of my project archive on request.

System debug info below:

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceRoot}",
            "executable": "./build/Debug/6DOFLC.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "device": "LPC54628J512",
            "interface": "swd",
        }
    ]
}

Toolchain info

Target: NXP LPC54628J512 (On the OM13098/LPCXpresso54628 dev board)
GDB version: GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
JLinkGDBServer version: SEGGER J-Link GDB Server V6.34g Command Line Version

VSCode Versions:

Version: 1.28.2
Commit: 7f3ce96ff4729c91352ae6def877e59c561f4850
Date: 2018-10-17T00:20:56.183Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

Host OS info

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"
Linux kernel release 4.15.0-34-generic

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 16 (4 by maintainers)

Most upvoted comments

Hey Everybody. @PlatformIO’s founder here…

I have to pay a subscription to use PIO+ for continuous debugging after the first free month is over

We don’t make millions on PIO+, this is a legal scheme to keep PlatformIO alive, open source and independent (this is critical for us and PlatformIO’s philosophy). We are working on making the most popular features of PIO+ to be free for end developers. This our main aim. If you like PlatformIO but PIO+ is the main argument why you don’t use it, please mail me@ikravets.com and provide your PIO Account ID (email). I’ll upgrade your account for free.

and PIO+ won’t work without convoluted settings

Please provide more details, we would be glad to fix this issue ASAP.

Regards, Ivan.

ivankravets on Nov 20, 2018

Thank you Ivan @ivankravets for your support @ https://community.platformio.org/t/jlink-v8-upload-problem/5640/6

Also thank you for the generous PIO+ free access till 2020! I can’t believe it’s going to be 2020 in about 13 months!

Hope to be around by then…

Sambo007 on Nov 22, 2018

Let’s take care of that first and I appreciate your offer to continue to use PIO+ for free. I’ll send you a private email concerning that.

Done! Please re-login to get a free access till the 2020 year.

ivankravets on Nov 21, 2018

My case is different, as my work needs to be shared across multiple developers on multiple different platforms.

PIO looks really cool for hobbyists, and I love what they are doing, however you are correct that it really isn’t there yet.

One size fits all does actually work all the time, IF (and definitely a big if 😄 ) you are comfortable with getting down and dirty. I need my tools to work from the command line, because we run scripted builds and need automation. Having it work in a gui is a nicety for increasing the productivity and ease of development.

Many of the uC manufacturers stuff is getting better, but I can’t really find any of them that still don’t entirely suck. You say you are developing for the STM32 family…have you seen https://gnu-mcu-eclipse.github.io/ ? I don’t do much with STM32s anymore, but I TA’ed an intro to microcontrollers and embedded systems class and that is what we used with great results (That is, once we allowed the students to use an IDE…we first started out by forcing them to manually load the code via openOCD and GDB and become proficient with the actual toolchain itself, before abstracting it away).

Best Brett

bigbrett on Nov 20, 2018

The above issue seems can be overcome with set backtrace limit x “preAttachCommands”: [“set backtrace limit 20”]

RogFedex on Oct 15, 2020