Local compiler does not use v5.3.1 gcc-arm toolchain


Hi folks,

In the process of setting up the local compiler in Workbench, I came across something that others might have encountered. Hope this might be helpful information for the next release of Workbench as the kinks get ironed out. I might also be doing this wrong, so your thoughts are welcome too.

tldr: the 545mb ~/.particle/toolchains/gcc-arm/5.3.1 toolchain installed by the Workbench VISX seems to be ignored during a local compile, and reverts to your older compiler (usually in /usr/local/bin), resultig in a failed compilation attempt. Having a $GCC_ARM_PATH environment variable pointing to the location of the installed 5.3.1 compiler does nothing, it still seems to default to /usr/local/bin.

tldr 2/suggestion? It will be good if the next release of Workbench has an updated makefile that can explicitly use the 5.3.1 toolchain it installed, and simply allow users to point to another toolchain using $GCC_ARM_PATH if so desired.

Background of my setup (and how to reproduce the issue):

  1. macOS 10.14.1
  2. previously-installed arm-none-eabi-gcc v4.9.3 local compiler that I use with particle-cli to build my projects locally. This was done using Homebrew, which handled the symlinking of /usr/local/bin/arm-none-eabi-* to the Homebrew Cellar location
  3. Particle: Install Local Compiler command run using Photon 0.7.0 device OS. Compiler downloaded to ~/.particle/toolchains/gcc-arm/5.3.1.
  4. Particle: Compile application (local) puts out an error that claims version 5.3.1 of the gcc-arm compiler was expected, but could only access the older 4.9.3. The downloaded 5.3.1 toolchain is ignored.


  1. Follow the particle-iot/firmware guide to create a Ruby install script for Homebrew to execute and download the specific v5.3.1 compiler. I however used the existing PX4 Ruby scripts as a starting point, and only changed the urls to pull v5.3.1 as provided in the firmware guide.
  2. Finish Homebrew steps as per above link, in particular those to unlink the older compiler and link the new v5.3.1 binaries to /usr/local/bin.

This was the cc-arm-none-eabi-53.rb I used:

require "formula"

class GccArmNoneEabi53 < Formula
  desc "GNU Embedded Toolchain for ARM"
  homepage 'https://launchpad.net/gcc-arm-embdded'
  version "20160307"
  url 'https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q1-update/+download/gcc-arm-none-eabi-5_3-2016q1-20160330-mac.tar.bz2'
  sha256 "480843ca1ce2d3602307f760872580e999acea0e34ec3d6f8b6ad02d3db409cf"

  def install
    ohai "Copying binaries..."
    cp_r %w[arm-none-eabi bin lib share], "#{prefix}/"


thanks for the report :+1:

can you try:

  1. run the Particle: Launch Compiler Shell command
  2. in the terminal that launches, run: which arm-none-eabi-gcc and copy the output
  3. also in the same terminal, run: echo $PATH and copy the output

then trim out any sensitive info and post your findings here

can you also confirm your terminal is running bash? (echo $0 should return /bin/bash or similar)


Hi @m_m

Yes I can confirm I’m running bash within the VSCode terminal.

Using the terminal window within VSCode I get the following same output as I do from macOS’ Terminal:

$ which arm-none-eabi-gcc

The pertinent bits of $PATH (redacted and split into lines for easier readability):

echo $PATH


Can you do the following just to confirm?

ls -la /usr/local/bin/arm-none-eabi-gcc

I get:

lrwxr-xr-x  1 nrobinson  admin  61 Aug 20  2017 /usr/local/bin/arm-none-eabi-gcc -> ../Cellar/gcc-arm-none-eabi-53/20160330/bin/arm-none-eabi-gcc

Which verifies that the symlink is correct for my installation for v5.3.1 gcc-arm.


Yes, my symlink is similar to yours, as far as I can tell:

lrwxr-xr-x  1 myuser  admin    61B 11 Dec 14:42 /usr/local/bin/arm-none-eabi-gcc@ -> ../Cellar/gcc-arm-none-eabi-53/20160307/bin/arm-none-eabi-gcc

Can you try defining $GCC_ARM_PATH to point to the toolchain that Workbench installs, in ~/.particle/toolchains/gcc-arm/5.3.1 instead of the Homebrew Cellar location? It will help to confirm if this issue is isolated to just my situation.

BTW the following CC variable was defined in common-tools.mk in the firmware build folder, and should point to whatever I have defined in $GCC_ARM_PATH



wow, ok. that’s really weird since i would expect to see a number of paths pre-pended to your $PATH list pointing into the Workbench’s ~/.particle/toolchains directory.

are you sure you ran those commands in the terminal produced after running the Particle: Launch Compiler Shell command? the drop-down menu at the top of the terminal panel should read “Particle Local Compiler”

for example, here’s my $PATH


the 1st one is our copy of the Particle CLI, the 2nd one is gcc-arm that Workbench manages.


My mistake… doh! I realised I didn’t Launch Compiler Shell. All good. :+1:

Does this mean we have to call Particle: Launch Compiler Shell once after starting VSCode? Is there a way to automate this on VSCode startup?


Does this mean we have to call Particle: Launch Compiler Shell once after starting VSCode?

no, we want this to be easy :slight_smile:

Particle: Launch Compiler Shell is just an interactive version of the environment our local compilation tasks run in - if it works, local compilation should as well.

try this:

  1. run the Particle: Create Project command (ctrl/cmd+shift+p then type “particle” and select from the list) and follow the prompts. upon completion, your new workspace should be loaded.
  2. run the Particle: Configure Workspace for Device command and select the Device OS version and your hardware platform (e.g. deviceOS@0.7.0 and photon or if you are using our new Gen 3 hw, deviceOS@0.8.0-rc.25 and argon, etc). depending on your selection, you may see additional dependencies start to download & install.
  3. write or import some basic “hello world” code in the ./src/<your project name>.ino file within your workspace
  4. from the main menu bar select: “Terminal > Run Task…” and run one of the compilation or flash tasks (e.g. Particle: Compile application (local))
  5. connect your device and put it into DFU-mode (docs)
  6. select “Terminal > Run Task…” and run the Particle: Flash application (local) task.

your new firmware should be flashed and your device should restart where you can verify your program is running as expected.

if you run into problems, can you note the step from the list above where the problem occurred?


Thanks for the additional tips.

Local compiles have otherwise been working great for me ever since I upgraded my local compiler to v5.3.1 via Homebrew.

The issue I had originally reported was just that I had v4.9.3 of arm-none-eabi-gcc in /usr/local/bin. Without calling Particle: Launch Compiler Shell on startup, the compiler scripts revert to whatever exists on the user’s machine which, in my case, caused the version mismatch. I noticed that it was the Particle: Launch Compiler Shell command that will prepend the Particle Workbench v5.3.1 toolchain into the path, which will resolve any future compiler version discrepancies.

I also found an extension called Auto Run Command that can trigger off items in the Command Palette on startup, for those who might be experiencing a similar scenario as I have. Modify your User Settings to call this automatically on startup:

``` "auto-run-command.rules": [ { "condition": "always", "command": "extension.launchCompilerShell", "message": "Particle Launch Compiler Shell" } ] ```

Another suggestion: why not put the Particle: Cloud Compile and the Particle: Cloud Flash commands into the Build tasks? It’s currently found only in the Command Palette. Sometimes it’s easier to OTA rather than dfu.


(edited: ignore the parts about Launching Compiler Shell on startup)


:thinking: i’m confused - Workbench aims to install and manage the toolchain that supports local compilation. the goal is for users to never have to worry about managing $PATH (and other pertinent env vars) or instances of the required dependencies (e.g. gcc-arm).

in short, if you are using Workbench, you should be able to simply run the local compilation tasks from VSCode’s Terminal > Run Task… menu item and things should just work. running Particle: Launch Compiler Shell is NOT a prerequisite.

if you want to manage that toolchain yourself outside of VSCode, you should probably discuss that over in https://community.particle.io/c/firmware

to close this out, are you able to successfully run through the steps i laid out here ?


Yes I’ve been compiling without issue after figuring out what went wrong. Just thought to share… and hope this wouldn’t confuse anyone further.

The confusion comes from users who have a pre-existing gcc-arm toolchain – my experience was that Workbench reverted to my older toolchain (installed via Homebrew) when compiling locally initially. The only pertinent thing I have done that might have impacted this is to install the 4.9.3 toolchain in the past to compile Photon pre-0.7.0 firmware. Hope others can try out what I did in the OP to see if the compilation error can be reproduced (and resolved as described below).

The kludgy way to resolve this was to upgrade my gcc-arm (in /usr/local/bin) to v5.3.1. The ‘real’ fix I believe was in making sure $GCC_ARM_PATH was not set in my bash profile, which common-tools.mk (found in the deviceOS build folders) uses to prepend the compiler commands with a specific path. I suspect this was the root cause of my problem.

Based on what you said, all compile tasks should simply execute the toolchain from wherever which arm-none-eabi-gcc reveals, and the tasks explicitly prepend the correct paths before the compile commands. I see that happening when testing it in the Local Compiler Shell.

However, the presence of a $GCC_ARM_PATH set in one’s bash profile seems to override this setup. If I understood this correctly, Particle: Local Compile Shell allows us to quickly to verify if $PATH is being prepended with the 5.3.1 Workbench toolchain location. But it was the presence of $GCC_ARM_PATH that caused issues with the compilation.

In any case, I might be spending too many long hours trying to familiarise myself with VSCode. At least all of the basics are working for me now.


the presence of a $GCC_ARM_PATH set in one’s bash profile seems to override this setup

ah! now i understand. thanks :pray: