Visual studio code as an IDE for MBED


Mbed is a great hardware platform. The modules are based on arm processors, which provides lots of power and memory. Especially compared to many arduino development boards. Also, it’s generally more professional: there are much clearer paths to go from proto-typing to production hardware.  There are also a couple of disadvantages: it’s just not so easy to program as a pycom or arduino device.

MBED and the IDE

Mbed comes with it’s own online editor. This is nice to start out with, but, as you will soon discover, it has some limitations. Working in a browser environment is never really the same as native applications, especially if you want to edit lots of files.  What bothered me the most was:

  • the ability to do proper code searches
  • jumping into function definitions
  • descent code completion
  • debugging

I just find it much more pleasant to work from within a known IDE: visual studio code. Luckily, this is perfectly possible. In fact, VSC is not the only editor you can use for mbed development. Some other platforms you can use: netbeans, eclipse, qtCreator, code::blocks,…


The tool-chain

Before you can build and debug your devices with VSC, you’ll need to setup your tool-chain and debugger. You can read up on this page for more detailed instructions, The short(er) version is this:

  • install the GNU arm embedded tool-chain
  • put the location of the tool-chain into your path. This will look something like:
    C:\Program Files (x86)\GNU Tools ARM Embedded\6 2017-q2-update\bin
  • You can test this by opening a command prompt and run:
    arm-none-eabi-gdb --version
  • Install a debugging interface. I use pyOCD cause this worked best for me.  (Alternatively, you can try openOCD). To install pyOCD, run:
    pip install pyocd
  • To test if the debugging interface works, you can run:

    The result depends a bit on the board that you are using. For most boards, it says something like:

    INFO:root:DAP SWD MODE initialized
    INFO:root:K64F not in secure state
    # ...
    INFO:root:CPU core is Cortex-M4
    INFO:root:FPU present
    INFO:root:6 hardware breakpoints, 4 literal comparators

    Key is the line marked in red: this indicates that the debugger found hardware support for breakpoints.


Once your tool-chain is ready, you can set up a project in Visual studio code. Detailed instructions can be found on the docs site of mbed. Basically, it comes down to this:

  • in VSC, install the C/C++ plugin (by Microsoft)
  • export a project from mbed’s online compiler. This seams a bit of a drag at first: why do I still need to create a project in the online version to get it working in VSC, but once you see the whole process, it becomes clear that this actually makes things a bit easier. The online compiler has an export function that specifically targets VSC and prepares things like compiler options for you. There are some issues with the export though, more on that in the next few steps. For now:
    • create a new project in the online compiler (you’ll need to create an account for this). Make certain that you select the correct device for your project. The template project isn’t so important as we’ll be writing the code in VSC anyway.
    • import all the required libraries. This step is important. It helps the export to set everything up properly.
    • right click on the project and select export program.
      • Use the same target as the board that you originally picked for your project (otherwise, the export might fail).
      • Select VSC-GCC-ARM as the export tool-chain.
    • This will start a download. Put the content of this zip file, somewhere on your disk.

      Important: make certain that there are no spaces in the path to your project as this will prevent the compiler from working properly, and the error messages are not clear on this issue (took me a while to figure this one out)

  • Open the project with VSC
  • The zip file contains a number of files that should be placed in the folder ‘.vscode’, but instead, they are placed in the root folder. This is something you will have to correct yourself.
  • Finally, you need to modify ‘launch.json’ a bit (from the mbed docs):
    • If you’re using pyOCD as your debug server, verify that debugServerPath is set to the location of pyocd-gdbserver.
    • If you’re using OpenOCD as your debug server:
      1. Change debugServerPath to point to the location of openocd.
      2. Change debugServerArgs to include your OpenOCD arguments. For more info, read our toolchain document.
    • I also had to replace ‘make’ with ‘mbed’
  • run the following command from your project folder so that the source for all dependent libraries are downloaded:
    mbed deploy

    note: some libraries are already included in the zip that was downloaded. In that case, the command will probably complain that the folder already exists. To fix this, delete the folder and run the command again.

  • You will also have to run the following command to set up the build tools:
    mbed export -i vscode_gcc_arm -m K64F --profile mbed-os/tools/profiles/debug.json

    This gave some issues with me that you might also experience:

    • I have both python 2.7 and 3 on my system. It only worked with V2.7 for me. Just make certain that the path to python 2.7 is first in your environment path.
    • Some libraries could be missing, these have to be installed separately:
      pip install pyelftools
      pip install jsonschema
    • Start the debugger in VSC. This will initiate a compilation. If all went well, the compilation succeeds but the debugger will probably complain that he couldn’t find the ‘.elf’ file. This still requires some small changes in ‘launch.json’:
      • correct the path for the field ‘program’. For me it looks like this (depends on the board you are using):
        "program": "${workspaceRoot}/BUILD/LPC1768/GCC_ARM/${workspaceRootFolderName}.elf",
      • same for the first line under ‘setupCommands’ (for windows):
        { "text": "-environment-cd ${workspaceRoot}\\BUILD\\LPC1768\\GCC_ARM" },

Tips and tricks

  • On my system, the debugger hangs after starting it a second time. This is cause the python process isn’t closed properly so I usually kill that process manually. Note that this are usually a couple of ‘python’ processes running. just kill them all and the debugger will work again.
  • There are differences between the online compiler and the GCC. The latter is more modern and supports newer C++ features. This difference can be annoying sometimes. Also, it appears that the online compiler runs on some sort of linux system, cause including headers is case sensitive (which is not the so on windows systems)

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.