Workbench local compile and flash for Core platform - Is this possible?

I have a few of the old Spark Core devices that I need to be able to compile and flash without internet. I have downloaded and installed the VS Code workbench extensions and can’t figure out how to get this working.

I have installed and selected deviceOS@1.4.4 which seems to be the last version that supports the core, but I am unable to select “core” as the platform, so I’ve selected “photon”.

Using the “Particle: Flash application (local)” command gives me the following results:

Opening DFU capable USB device...
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x080a0000, size = 5632
Last page at 0x080a15ff is not writeable
make[2]: *** [../../../build/ program-dfu] Error 74
make[1]: *** [../build/ modules/photon/user-part] Error 2
make: *** [C:\Users\darri\.particle\toolchains\buildscripts\1.9.2\Makefile:72: flash-user] Error 2
The terminal process terminated with exit code: 2

I have also tried using the cli to flash the binary directly but I had to use a –force switch and then the device ended up stuck in DFU mode. I figure this was from compiling a binary that is targeting the photon, I had to factory reset to regain use of the device.

Is there a custom toolchain I can install with support for the core?


Hey @planetdaz, welcome to the community.

While Workbench no longer supports the core officially, there is a settings file for Workbench that you can modify to add support for the core.

First you want to find the global vscode extensions directory:

  • Windows %USERPROFILE%\.vscode\extensions
  • macOS ~/.vscode/extensions
  • Linux ~/.vscode/extensions

In that directory you will find a directory named something like particle.particle-vscode-core with the version at the end. Open that directory.

Once you are in the particle.particle-vscode-core directory, open src, and then compiler.

In the compiler directory you will find a manifest.json file. Open it.

There are two modifications you must make:

  • First, find the line with "firmware": "deviceOS@1.4.4". On the line above it there should be an array of integers called platforms. Add a new integer to that array. “1” is a good choice. The line should look something like "platforms": [1, 6, 8, 10, 12, 13, 14, 23], afterwards.

To use 0.7.0 like @peekay123 suggested, do the same thing but with the platforms array above the "firmware": "deviceOS@0.7.0" line.

  • Second, scroll down to the big platforms array. You should see objects like this:
    "id": 6,
    "name": "photon",
    "generation": 2

Insert a new object into the array that looks like this:

    "id": 1,
    "name": "core",
    "generation": 1

Save the file and then reopen your project in Workbench.

If you get a popup about installing the dependencies again or a notification that local compilation won’t work, ignore them.

Configure your project for core and then try to build it.


@planetdaz, DeviceOS 1.4.4 is too large for the Core. The last DeviceOS version I would recommend for the Core is 0.7.0.

1 Like

Hi Nathan,

This was fast and perfect advice! Thank you for taking the time to include so much detail it worked on the first try, and now I am successfully flashing my old cores with working code without a reliable internet connection.

Was this procedure listed somewhere in the docs? I searched for days and couldn’t find it.

Thanks again!

1 Like

Thanks @peekay123! I am able to load my code onto the core using 1.4.4, the total bin size is about 103kb.

So when you say it’s too large, do you mean that it puts me close to maxing out the RAM (which I believe is 128k)?

Would I lose much in terms of API if I step down to 0.7.0? I plan to run a lightweight http server on the core to respond to GET and POST requests and drive a few pins, so nothing huge.


1 Like

@planetdaz, the Core only has 20KB of RAM, not 128KB. Did you actually flash your Cores with the new code and it worked?

@peekay123 Yes, the full 103kb loaded and is running right now. I’ve seen 128k listed as the capacity of the spark core. Are you thinking of an earlier version maybe?

props to @nrobinson2000 for the in-depth reverse engineering there.

i need to call out the (hopefully) obvious that a) these files are always updated with each release of Particle Workbench and thus any edits will be lost b) the current implementation will change over time making these instructions inaccurate / obsolete

as always, we can only support users engaging with the public interfaces we put out - tweaking internals like this means you are on your own. please plan accordingly :pray::pray:


@planetdaz, that’s good news that it works! I have ditched all but one of my Cores and use Photons and Argons for WiFi now. I’ll see if my Core will run its code at v1.4.4!

1 Like

Thanks @m_m, that’s important for me to be aware of for sure!

Is there any chance we can keep support for the “core” as part of workbench? I understand that the device is past its lifetime but I see a lot of existing users still out there, and it would be a shame to lose the ability to compile and flash it locally.


@planetdaz, I just compiled my code which uses the Blynk library against V1.4.4 and it fails since it is too large to fit on the device. Thus the reason for sticking with v0.7.0.

@peekay123 What is the total firmware size with deviceOS and libraries?

Is there any chance we can keep support for the “core” as part of workbench?

realistically, no.

that said, you should be able to lean on WB’s support for custom Device OS builds:

you’ll need to add / replace the <device-os-repo>/.workbench/manifest.json file (depending on the version of Device OS you need to run) with one that looks like:

    "version": "1.0.0",
    "toolchains": [
            "firmware": "deviceOS@source",
            "compilers": "gcc-arm@5.3.1",
            "debuggers": "openocd@0.11.2-adhoc6ea4372.0",
            "platforms": [1],
            "scripts": "buildscripts@1.9.2",
            "tools": "buildtools@1.1.1"
    "platforms": [
            "id": 1,
            "name": "core",
            "generation": 1

…or something along those lines - you’ll have to experiment a bit to find the right settings. this approach is better in that you won’t have to reapply changes when WB updates.

1 Like

@planetdaz, with v0.7.0:

In a nutshell:
Flash used	107244 bytes
RAM used	10604 bytes

With v1.4.4, the flash is exceeded by 4572 bytes.

1 Like