How to program/debug MCU/DSP in VSCode

[Rinnake]

Hello,

I would like to ask if you program MCU/DSP in VSCode? I've tried to run NXP microcontrollers there (I followed: https://mcuoneclipse.com/2021/05/01/visual-studio-code-for-c-c-with-arm-cortex-m-part-1/) and  everything works without problems. It uses GCC with cmake/make to build the program, and debug via J-link.

I wanted to replicate this procedure on a DSP from TI (specifically the C2000 series, TMS320Fxxx), but I haven't managed to make it work - specifically, I don't know how to configure the "launch.json" correctly. For now, I'm doing the build with a command/script from their CCS IDE ("C:\\ti\\ccs1220\\ccs\\utils\\bin\\gmake -k", "-j", "8", "all", "  -O) although I'd rather do the same process as it was with NXP above (GCC, cmake).

TI uses very different approach against NXP/STM. As a debug probe, C2000 boards have XDS100, probably openocd which supports this debug probe. However, I have no idea how to set everything correctly in launch.json that debugging can subsequently be done in VSCode without problems.

Thanks for any help.

[artag]

I don't do anything in VSCode. I can't imagine why anyone would want to.

[meshtron]

I don't do anything in VSCode. I can't imagine why anyone would want to.

I do lots of programming in VS Code and prefer it to any other IDE I use.  I do C# and web dev stuff in Visual Studio, but all Python and C++ in VS Code.  It's super lightweight, customizable, fast, nicely integrated with Github, etc. - what's not to like?!?

@Rinnake have you tried using the PlatformIO extension for VSCode?  It is more geared towards dev boards (vs bare metal stuff) but it can and is used successfully by folks for bare metal/custom stuff too.

[Rinnake]

No, platformio.io is missing DSPs from TI. I've just realized, that when I will create and build a project in CCS, it creates "makefile" which informs about the compiler and linker which should be used during the building. So now I know how to build the project in VSCode, but I do not know, how to debug it - I mean, how to correctly set "launch.json" for debugging/communicating with the target DSP.

[artag]

what's not to like?!?

Dark mode, for a start. Yes, I do know how to fix that.
2nd biggest dislike is the overcrowded tiled interface. Can I get rid of that and have floating windows ? It amazes me that we all use flexible overlapping windowed interfaces and then some applications stuff everything into a box with unusably tiny subboxes for every subtask..

[nctnico]

No, platformio.io is missing DSPs from TI. I've just realized, that when I will create and build a project in CCS, it creates "makefile" which informs about the compiler and linker which should be used during the building. So now I know how to build the project in VSCode, but I do not know, how to debug it - I mean, how to correctly set "launch.json" for debugging/communicating with the target DSP.

You need to look closely at the console output of Eclipse (CCS) and see which program is used for the debugging. If that is some form of GDB then it should be possible to hook that up the VSCode. Assuming things aren't complicated by copy protection / license handling.  A quick Google shows me you are not the only one looking to do this but none seemed to have put the time in to sort it out. It likely is going to take a good part of a week to figure this out. Best start is likely to create a launch setup for VSCode from scratch. You also might want to look at how to use VSCode for cross-compiling. Then you don't have to use make files but you can use VSCode's own 'make' system.

Random Google find that tries to do the same for a different architecture:
https://www.netburner.com/learn/how-to-use-visual-studio-code-to-debug-your-netburner-applications/

[Rinnake]

You need to look closely at the console output of Eclipse (CCS) and see which program is used for the debugging. If that is some form of GDB then it should be possible to hook that up the VSCode. Assuming things aren't complicated by copy protection / license handling.  A quick Google shows me you are not the only one looking to do this but none seemed to have put the time in to sort it out. It likely is going to take a good part of a week to figure this out. Best start is likely to create a launch setup for VSCode from scratch. You also might want to look at how to use VSCode for cross-compiling. Then you don't have to use make files but you can use VSCode's own 'make' system.

I do not think it will be an easy way to make it work since it seems that C2000 from TI has more complicated settings against usual MCU:

https://teslamotorsclub.com/tmc/posts/2696107/

I was watching in the console in CCS during debugging and found practically nothing against building a project, where I can see the steps to accomplish it.

[nctnico]

Which debugger is TI using? Is that GDB? A typical debugging setup consists of a program that controls the debugging at the high level (like gdb) and a hardware/software layer that communicates with the actual processor and also implements how the processor communicates over JTAG. The IDE interfaces with the high level debugger. GDB is pretty standard, so if (big if) TI uses GDB, then it should be possible to transplant the debugging setup from CCS to VSCode. Unless ofcourse controlling the debugging is done at a high level from CCS directly.

I would leave OpenOCD out of it because as you have found out, it is not compatible with the processor you are using. And yes, JTAG is much less versatile then you'd think. It is basically nothing more than two shift registers. What is done with it, depends entirely on the manufacturer and you'll need whatever protocol the manufacturer designed into the processor. There is no high level communication standard for JTAG communication.

So basically the first question is: what debugger is TI using at the high level?
Second question: can you debug the C2000 without needing CCS. IOW: can you start a debugging session from the command line?

[mayor]

I use CC13XX myself, never got debugging to work with VS Code and OpenOCD (lack of proper cJTAG support in my case). I can look for my config files and share them with you. That being said, TI is working on CCS Theia, based on VS Code, and that works well. You might have to ask on the TI forums for C2000 support if it's not already available. You might get a link to beta if it's available.

[Rinnake]

So basically the first question is: what debugger is TI using at the high level?

It uses "XDS100v2 On-Board Debug Probe" that enables JTAG debugging/programming as well as provides serial communication back to the PC.

Second question: can you debug the C2000 without needing CCS. IOW: can you start a debugging session from the command line?

I'm not sure about that right now. In FAQ (https://www.ti.com/lit/ug/sprui77c/sprui77c.pdf), I've found something about using another tools/probes:

1. Can other programming and debug tools (such as an XDS510 debug probe) be used with the C2000
LaunchPad?
While a user could potentially connect an external debug probe to the F28379D device present on the
LaunchPad, it would require some rework of the board. It is recommended that users who want to use
an external debug probe, purchase a controlCard and docking station that includes an external JTAG
connector

I use CC13XX myself, never got debugging to work with VS Code and OpenOCD (lack of proper cJTAG support in my case). I can look for my config files and share them with you. That being said, TI is working on CCS Theia, based on VS Code, and that works well. You might have to ask on the TI forums for C2000 support if it's not already available. You might get a link to beta if it's available.

If your config files somehow worked with VSCode, I would be glad if you could share them. Yes, I know about CCS Theia. It looks promising, but it does not support any other ARM than M0+ yet...

[mayor]

If your config files somehow worked with VSCode, I would be glad if you could share them. Yes, I know about CCS Theia. It looks promising, but it does not support any other ARM than M0+ yet...

You have to ask on the TI forum- CC13XX is Cortex M4, not officially available yet, but I was provided a link just by asking.

Here's where I left off many months ago, hope this helps a little. I don't see an openocd target file for TMS320, maybe some exist online.

launch.json (change hard coded path for your executable!)

Code: [Select]

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceFolder}",
            "executable": "Debug/empty_CC1352R1_LAUNCHXL_tirtos7_ticlang.out",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "main",
            "servertype": "openocd",
            "configFiles": [
                "/usr/local/opt/open-ocd/share/openocd/scripts/board/ti_cc13x2_launchpad.cfg"
            ],
            "gdbPath": "/Applications/ARMGNUToolchain/12.2.mpacbti-bet1/arm-none-eabi/bin/arm-none-eabi-gdb",
        }
    ],
    "showDevDebugOutput": "raw"
}

TI boards in my openocd install:

Code: [Select]

ti_am335xevm.cfg ti_beaglebone-base.cfg ti_cc3200_launchxl.cfg ti_j721s2evm.cfg
ti_am437x_idk.cfg ti_beaglebone.cfg ti_cc3220sf_launchpad.cfg ti_msp432_launchpad.cfg
ti_am43xx_evm.cfg ti_beaglebone_black.cfg ti_cc32xx_launchpad.cfg ti_pandaboard.cfg
ti_am625evm.cfg ti_blaze.cfg ti_dk-tm4c129.cfg ti_pandaboard_es.cfg
ti_am642evm.cfg ti_cc13x0_launchpad.cfg ti_ek-tm4c123gxl.cfg ti_tmdx570ls20susb.cfg
ti_am654evm.cfg ti_cc13x2_launchpad.cfg ti_ek-tm4c1294xl.cfg ti_tmdx570ls31usb.cfg
ti_beagleboard.cfg ti_cc26x0_launchpad.cfg ti_j7200evm.cfg
ti_beagleboard_xm.cfg ti_cc26x2_launchpad.cfg ti_j721evm.cfg

/usr/local/opt/open-ocd/share/openocd/scripts/board/ti_cc13x2_launchpad.cfg (referencing unmodified openocd files):

Code: [Select]

# SPDX-License-Identifier: GPL-2.0-or-later

#
# TI CC13x2 LaunchPad Evaluation Kit
#
source [find interface/xds110.cfg]
adapter speed 1500
transport select jtag
source [find target/ti_cc13x2.cfg]

TI targets in my openocd install:

Code: [Select]

ti-ar7.cfg ti_cc13x2.cfg ti_cc32xx.cfg ti_k3.cfg ti_tms570ls20xxx.cfg
ti-cjtag.cfg ti_cc26x0.cfg ti_dm355.cfg ti_msp432.cfg ti_tms570ls3137.cfg
ti_calypso.cfg ti_cc26x2.cfg ti_dm365.cfg ti_rm4x.cfg
ti_cc13x0.cfg ti_cc3220sf.cfg ti_dm6446.cfg ti_tms570.cfg


[abeyer]

what's not to like?!?

That it tries to sit in some weird middle space of being too big to be just an editor but too small to be a full ide -- and rather than get the better parts of both, it ended up with the worst of both.

[asmi]

That it tries to sit in some weird middle space of being too big to be just an editor but too small to be a full ide -- and rather than get the better parts of both, it ended up with the worst of both.

You couldn't be more wrong. It took the BEST parts of both, and currently is the best developer's productivity tool ever existed. If you don't agree, you simply don't know how to use it properly.

[abeyer]

the best developer's productivity tool ever existed.

 

[SiliconWizard]

what's not to like?!?

That it tries to sit in some weird middle space of being too big to be just an editor but too small to be a full ide -- and rather than get the better parts of both, it ended up with the worst of both.

I thanked your earlier post, but that's personally not the reason why I did. I don't like that it's all Typescript sh*t, that it tends to be slow, I don't like its auto-indent feature (I like simpler ones), I don't like how configuring about everything requires cryptic options in JSON files (AFAIR) - and I don't mind configuring stuff using config files, just that the way they did it looks pretty horrible to me - and a number of other reasons. Also that it's a bunch of telemetry-stuffed MS software. Sure you can get it compiled from source (VSCodium), rather than the MS distribution, but VSCodium doesn't quite support all existing extensions, and extensions are one of the key benefits of VSCode.

I use Geany these days on Linux most of the time. In terms of functionality, it's close to VSCode and it's fine. It's just more lightweight, faster and easier to configure, and has nothing to do with MS.

[meshtron]

what's not to like?!?

That it tries to sit in some weird middle space of being too big to be just an editor but too small to be a full ide -- and rather than get the better parts of both, it ended up with the worst of both.

Horses for courses I guess.  Works great for me, zero complaints.  Love the flexibility, configurability of nearly everything, and how little time I spend thinking about the tool vs just getting code created.  @artag mentioned a desire to have floating windows - never something I've tried but appears it legitimately can't do that even after years of people requesting it.  But, works great for me and if I could use it instead of Microchip Stuido (or MPLAB) I'd do it in a heartbeat.  But then again, I'm only cosplaying as a developer at all much less an MCU dev.