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

[bigbrett]

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

[0ge]

Have you checked out issue #101?

[bigbrett]

I did. I do not want to "run to main", as there is stuff in the init and reset handler that I have to debug Pls let me know if I can provide any supplementary info. Brett

…

On Mon, Nov 12, 2018, 23:58 0ge ***@***.*** wrote: Have you checked out issue #101 <#101>? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMpVjQvptMSWTcYRUsO9sL-YTB7hFR6ks5uum2vgaJpZM4YQwJH> .

[0ge]

Yeah, I didn't mean it as a solution, only if its the same issue.

[bigbrett]

Okay, thanks. Any suggestions for how I could further debug to help it get fixed?

…

On Sun, Nov 18, 2018, 23:52 0ge ***@***.*** wrote: Yeah, I didn't mean it as a solution, only if its the same issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMpVlYzYfhWsvRYlykbp0KKXcw4ghgcks5uwmMugaJpZM4YQwJH> .

[Sambo007]

Hey @bigbrett,

I am like you having too much trouble to get debugging working with VSCode and its add-ons: PIO, GDB, etc...
I've been recently spending most of my time getting the development tool setup and working right rather than my App itself.

At first, I liked the idea of having one tool for many different platforms and uCs. It's certainly much better than Arduino IDE for Arduino development (I use it for my students and small projects ). But now I think Atmel Studio (a modified version of Visual Studio) is much better. Also when I did some NXP uC development a few years back, LPCXpresso (now they have MCUXpresso), I was debugging my code from the start.

Currently, I am working on a project based on an ST Cortex uC, I've spent a month on VSCode to get debugging working and it's still having issues and I have to pay a subscription to use PIO+ for continuous debugging after the first free month is over. and PIO+ won't work without convoluted settings. This Cortex-Debug tool here let us supposedly debug for free, when it works right. I believe it's time to go back to have a different tool for each platform. ST now has TrueSTUDIO - Atollic.

'One size fits all' doesn't fit right most of the time... Besides the good IDEs are based on Eclipse or VS. so effectively they'll look and feel the same. Too many .ini settings, Python scripts, and Json config files for VSCode. I also don't believe we'll see reliable support for Trace & Profiling within VSCode any time soon.

Bottom line, I'm now seriously thinking that the best thing is to revert back to the uC manufacturer's provided software tool(s). Most of them are buying the tool company and are providing the Pro version of their software for free. I prefer to work with a decent, solid IDE with GUI based configs and with built in debug support that works reliably in a few mins and not weeks or months. Maybe your case is different since you're running under Linux and some of these tools are Windows only; not sure.

Cheers...

[bigbrett]

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

[ivankravets]

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.

[Sambo007]

Hi Ivan,

I apologize if I sounded negative in my previous post.

I recommended PIO to all my students when I was the Director of Engineering Labs at a local university. Plus I am happy using it for small projects that don't require serious debugging, which is much better than Arduino IDE. IntelliSense alone is enough good reason; and let's not forget the light weight of VSCode/PIO compared to VS/VisualMicro.

Lately however, I am having some issues and I already posted my problem on the PIO Community a few days ago: JLink V8 Upload problem. And I am still hoping to get a reply from you, which I honestly appreciate.

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.

Please don't let me or anybody else slow you down on your great and continual effort to enhance PIO.
I am willing to support you in beta testing when my time permits.

Wish you the best...

[Sambo007]

Hi Brett @bigbrett,

Thanks for the feedback and for the GNU eclipse link.

On another unrelated subject (not sure if I am breaking a rule here or not? I'll know soon for sure...), your executable file name: 6DOFLC.elf caught my attention. I am currently working on a sophisticated 9DOF AHRS device from the ground up.

Out of curiosity (I know: curiosity killed the cat 😄), what are you working on and what does the 'LC' stands for?

[ivankravets]

@Sambo007 ST STM32 was the last dev/platform where we used openOCD for J-Link probe. We have just switched it to the official J-Link tool for debugging and uploading. More details => https://community.platformio.org/t/jlink-v8-upload-problem/5640/6

Does it work now?

[ivankravets]

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.

[bigbrett]

@Sambo007 LC stands for load cell, i.e. a very specific arrangement of mechanical strain gauges that give you a way to measure the forces and moments applied to a "joint", say for a robotic arm or other unspecified appendage. A "sensor" that gives you xyz force components and xyz moments about a joint linkage axis, if you will.

[Sambo007]

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...

[RogFedex]

observing the hung issue right after hitting the breakpoint in the code in my setup. it is taking too long time (about
2 mins) to get resume and other buttons to get enabled. After 2 mins if
step in or step out is tried then it takes again another 2 mins to move to next
instruction

In Eclipse setup this issue is not observed.. so guessing something missing here.
With showDebugOutput, i see the below message right after break point is hit
53-stack-info-depth --thread 1 10000
54-stack-info-depth --thread 1 10000

And then after almost 2 mins later, lot of messages are poring out starting
from...
GDB -> App:
{"token":53,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[["depth","10000"]]}}
55-stack-list-frames --thread 1 0 19
.....

During the 2 mins, the Debug output window shows the
debugger is continuously reading a a particular address in memory

.....
.....
Read 4 bytes @ address 0x0020E386 (Data = 0xA801E7D4)
Read 4 bytes @ address 0x0020E386 (Data = 0xA801E7D4)
Read 4 bytes @ address 0x0020E386 (Data = 0xA801E7D4)
Read 4 bytes @ address 0x0020E386 (Data = 0xA801E7D4)
......
.....

Not sure why debugger is continuously reading the memory

The address (0x0020e386) is in the code area but not related to the
breakpoint set - however in the call_Stack, the address showing up
(incorrectly). Line 474 in abcd.c is at address - 0x0020e8d6.
None of the addresses in the call_stack seems correct anyways.

func1@0x0021c3b0
(c:\a\b\c\d\file1.c:200)
func2@0x00211ed8
(c:\a\b\e\f\file2.c:1948)
func3@0x00211f1e
(c:\a\b\e\f\file2.c:1109)
func4@0x0020e386
(c:\a\b\e\f\abcd.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)
func4@0x0020e386
(c:\a\b\e\f\abcd.c.c:474)

Failed to get Stack Trace: Invalid thread id: 1 (from stack-info-depth
--thread 1 10000)

[RogFedex]

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

[PhilippHaefele]

@bigbrett A lot of things have changed in the meanwhile. If you're still interested in using this extension, please retest with the latest version of the extension. If you still have the issue, please enable "showDevDebugOutput" in your launch.json and post the content of the Debug console (as collapsable block or file) here. We'll then reopen the issue and try to help you.

@haneefdm Please close