OneThinx, VSCode, Cortex-Debug GDB Deprecation

If you have read the previous posts and followed them, you have set up an environment to build and debug PSOC5LP code natively on a Mac, after creating the schematic in PSOC Creator.

So, today, my VSCode updated itself. Suddenly two warnings popped up:

WARNING: Cortex-Debug will deprecate use of GDB version 8. Please upgrade to version 9+

And this, when I went to run my code:

launch.json: “runToMain” has been deprecated. Please use “runToEntryPointā€¯ instead


I did not know what to do about the first message. So, I started searching. Turns out for programmers, Google is your friend. (Not so much for free speech, but good for development.)

Finding The Arm Toolkit

In the /Applications/VSCode_OneThinxPack_macOS directory, the development environment for using cross compile and debug on the Mac exists. I started looking around.

In that folder is the folder gcc-arm-none-eabi-9-2020-q2-update. Inside that folder are the folders that support cross compile for the Arm processor for the Mac. (Or Linux, or Windows, depending upon your OneThinxPack.)

Hmm. Where did that come from? Not sure.

I looked for MacPorts, and HomeBrew. Tried installing arm-none-eabi-gcc for HomeBrew. No dice. Something wrong with my installation according to brew. Nope, it is wrong.

So, I googled the exact name, and I found it! It was at the ARM designer’s website. Thankfully, OneThinx did something very right. So I went to the ARM site and looked around. Found it!

The link is: I searched for, and download the pkg file on that page. I ran it and it installed.

Hmm. Where? I started looking. Finally found it in the ARM directory in the Applications folder. Gee. Thanks ARM for NOT telling me anything.

So, looking inside the ARM directory, I found the same directory pattern as in the gcc-arm-none-eabi-9-2020-q2-update. So I renamed the folder to gcc-arm-none-eabi-10-2021-q4-update, and then I moved it into the OneThinxPak directory.

Then, I edited the variables.env file in the OneThinx directory to reflect the new compiler (after making a backup of the older env file.) Here is the result:

# Set the location of this pack
export ONETHINX_PACK_LOC="/Applications/VSCode_OnethinxPack_macOS"

# Set the PDL version (must match the folder name of the PDL!)
export ONETHINX_PDL_VERSION="PDL_1.3.1.1499"

# Set the Compiler version (must match the folder name of the Compiler!)
export ONETHINX_COMPILER_VERSION="gcc-arm-none-eabi-10-2021-q4-update"

# Set the Tools version (must match the folder name of the Tools folder!)
export ONETHINX_TOOLS_VERSION="tools_2.0"


I logged out and logged back in. I launched a terminal (inside /Applications/Utilities folder) and executed “set | grep ONE” and saw the following:

wmimac:~ maxfield$ set | grep ONE
wmimac:~ maxfield$ 

Everything should be good. I launched VSCode, opened a folder, and it was still stuck on the older compiler. I clicked on the “GCC 9.3.1 arm-none-eabi” section at the bottom:

the DropDown at the top had the new compiler listed:

I chose “GCC 10.3.1 arm-none-eabi.” Clicked on “Clean-Reconfigure” and then debugged.

It worked! No more deprecation error. And the old kit is still available in case we have to go back.

JSON “runToMain” Deprecation

The next thing is the Json deprecated error. Unfortunately, “runToEntryPoint”: true, does not work.

Hmm. I tried several things. Finally, as I was stumbling around, I typed in “run” while the cursor was on the line at that point, and VSCode gave me a “runToEntryPoint” pop-up menu. I hit enter, and it filled in correctly:

“runToEntryPoint”: “main”,


I started a Debug Session, and it worked!


The debug console complained of gdb not being python scripting compatible.


After about an hour of searching for where gdb was being specified, I gave up. There are different ways to skin a cat, so I used a terminal program and went into the folder did a soft link to fix this. The original GDB is saved as gdb.orig just in case:

imac:bin$ cd /Applications/VSCode_OnethinxPack_macOS/gcc-arm-none-eabi-10-2021-q4-update/bin
imac:bin$ sudo mv arm-none-eabi-gdb arm-none-eabi-gdb.orig
imac:bin$ ln -s arm-none-eabi-gdb-py arm-none-eabi-gdb

That worked! I now have a debug session without errors, and without reported deprecations or problems listed in the gdb window.

Final Thoughts.

We have the system updated. A preliminary debug session has worked, so I believe we are good.

These instructions should (mostly) work on Linux and Windows, more or less…


Add a Comment

Your email address will not be published. Required fields are marked *