The Spark Core Firmware

The Spark Core Firmware

This firmware depends on two other libraries: the Spark Common Library and the Spark Communication Library

  1. Download and Install Dependencies
  2. Download and Build Repositories
  3. Edit and Rebuild
  4. Flash It!

1. Download and Install Dependencies

  1. GCC for ARM Cortex processors
  2. Make
  3. Device Firmware Upgrade Utilities
  4. Zatig (for windows users only)
  5. Git

1. GCC for ARM Cortex processors

The Spark Core uses an ARM Cortex M3 CPU based microcontroller. All of the code is built around the GNU GCC toolchain offered and maintained by ARM.

Download and install the latest version from:

2. Make

In order to turn your source code into binaries, you will need a tool called make. Windows users need to explicitly install make on their machines. Make sure you can use it from the terminal window.

Download and install the latest version from:

3. Device Firmware Upgrade Utilities

Install dfu-util. Mac users can install dfu-util with Homebrew, Linux users may find it in their package manager, and everyone can get it from

4. Zatig

In order for the Core to show up on the dfu list, you need to replace the USB driver with a utility called Zadig. Here is a tutorial on using it. This is only required for Windows users.

5. Git

Download and install Git:

2. Download and Build Repositories

The entire Spark Core firmware is organized into three repositories. The main firmware is located under core-firmware, while the supporting libraries are subdivided in to core-common-lib and core-communication-lib.

How do we download these repositories?

You can access all of the repositories via any git interface or download it directly from the website.

Make sure all of the following repositories are downloaded into the same folder. For example (if all of the repositories are downloaded in a folder called Spark):


Method 1: Through the git command line interface.

Open up a terminal window, navigate to your destination directory and type the following commands:

(Make sure you have git installed on your machine!)

  • git clone
  • git clone
  • git clone

Meathod 2: Download the zipped files directly from the Spark’s GitHub website

How do we build these repositories?

Make sure you have downloaded and installed all the required dependencies as mentioned previously.

Open up a terminal window, navigate to the build folder under core-firmware and type:

make clean all

This will build your main application and both the dependencies.

For example: D:\Spark\core-firmware\build [master]> make clean all

Navigating the code base

All of the repositories are sub divided into functional folders:

  1. /src holds all the source code files
  2. /inc holds all the header files
  3. /build holds the make file and is also the destination for the compiled .bin and .hex files.

3. Edit and Rebuild

Now that you have your hands on the entire Spark Core firmware, its time to start hacking!

What to edit and what not to edit?

The main user code sits in the application.cpp file under core-firmware/src/ folder. Unless you know what you are doing, refrain yourself from making changes to any other files.

After you are done editing the files, you can rebuild the repository by running the make clean all command. If you have made changes to the other two repositories or have updated them, make sure to run make clean all command to rebuild all of them.

4. Flash It!

Its now time to transfer your code to the Spark Core! You can always do this using the Over The Air update feature or, if you like wires, do it over the USB.

Make sure you have dfu-util installed and available through the command line


  1. Put you Core into the DFU mode by holding down the MODE button on the Core and then tapping on the RESET button once. Release the MODE button after you start to see the RGB LED flashing in yellow. This process is also described in greater detail here.

  2. Open up a terminal window on your computer and type this command to find out if the Core indeed being detected correctly.

    dfu-util -l
    you should get the following in return:

    Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/20*001Ka,108*001Kg" 
    Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=1, name="@SPI Flash : SST25x/0x00000000/512*04Kg"

    (Windows users will need to use the Zatig utility to replace the USB driver as described earlier)

  3. Now, navigate to the build folder in your core-firmware repository and use the following command to transfer the .bin file into the Core.

    dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

   For example, this is how my terminal looks like:

D:\Spark\core-firmware\build [master]> dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

Upon successful transfer, the Core will automatically reset and start the running the program.

**Still having troubles?** Post your questions here!


The Spark application team: Zachary Crockett, Satish Nair, Zach Supalla, David Middlecamp and Mohit Bhoite.

The core-firmware uses the GNU GCC toolchain for ARM Cortex-M processors, ARM's CMSIS libraries, TI's CC3000 host driver libraries, STM32 standard peripheral libraries and Arduino's implementation of Wiring.


Unless stated elsewhere, file headers or otherwise, all files herein are licensed under an LGPLv3 license. For more information, please read the LICENSE file.


Want to contribute to the Spark Core project? Follow [this link]() to find out how.


Latest Version: v1.0.0

This topic is now pinned. It will appear at the top of its category until it is either unpinned by a moderator, or the Clear Pin button is pressed.

Anyone just copying and pasting the above lines from section 4, step 3, please be aware that “br” was added to the lines. The correct statement should be:
dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

@fillibar Thanks! I’ve removed that typo.

i’m having trouble getting this to build, i’ve installed binutils-arm-none-eabi, gcc-arm-none-eabi and libnewlib-arm-none-eabi as well as dfu-utils etc. (on debian jessie/sid) and proved the arm toolchain works:

$ arm-none-eabi-gcc -print-multi-lib

but the makefile is not finding header files in /usr/include/ for example:

core-firmware/build$ makeBuilding core-common-lib
Building file: ../CC3000_Host_Driver/cc3000_common.c
Invoking: ARM GCC C Compiler
mkdir -p obj/CC3000_Host_Driver/
arm-none-eabi-gcc -g3 -gdwarf-2 -Os -mcpu=cortex-m3 -mthumb  -I../CC3000_Host_Driver -I../SPARK_Firmware_Driver/inc -I../STM32F10x_StdPeriph_Driver/inc -I../STM32_USB-FS-Device_Driver/inc -I../CMSIS/Include -I../CMSIS/Device/ST/STM32F10x/Include -I. -ffunction-sections -Wall -fmessage-length=0  -MD -MP -MF obj/CC3000_Host_Driver/cc3000_common.o.d -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -c -o obj/CC3000_Host_Driver/cc3000_common.o ../CC3000_Host_Driver/cc3000_common.c
In file included from ../CC3000_Host_Driver/cc3000_common.c:46:0:
../CC3000_Host_Driver/cc3000_common.h:41:20: fatal error: stdlib.h: No such file or directory
 #include <stdlib.h>
compilation terminated.
make[1]: *** [obj/CC3000_Host_Driver/cc3000_common.o] Error 1
make: *** [check_external_deps] Error 2

The link is stale

How can I submit some patches?

You can submit patches through pull requests on any of our public repositories:

If you're not familiar with Github pull requests:

Are you using the fork and pull or the shared repository and topic branches model?

btw, the links under “Download and Install dependencies” no longer work, e.g. link 4 Zatig goes to - http://discourse/#4-zatig

I've got the toolchain all setup, and can run make no problem from the build directory, but now it would be nice if I could get dfu-util working.

Easier said than done on Windows 7 32-bit! It's practically non-supported... I'm working my way through installing all of the tools again to build the sources for dfu-util

Dfu-util-windows - Openmoko

If anyone has a better way, please let me know! Thanks.

Hey @BDub,

It looks like they have pre-compiled binaries for Windows on the site: – open it up with 7-zip, and the win32-mingw32 version worked for me (at least on win7-64 bit)



Awexome! Thanks Dave :slight_smile: I put the binaries in my PATH and they work. Just had to install the Zatig WinUSB driver for the CORE DFU device that pops up with you put the :spark: Core into DFU mode (Flashing Yellow). Built the master branch and I’ve got Tinker loaded as expected.

Earlier I had replaced the SPARK CORE WITH WIFI device that is present when the Core has booted, with the Zatig WinUSB driver. So I’m guessing I should put the other driver back that creates the USB to Serial Bridge.

One problem I am now having is when I try to rebuild the project again by typing make in the core-firmware\build directory, I get this error:
obj/src/application.o.d:1: *** multiple target patterns. Stop.

Also can anyone comment on about how long it takes to compile the sources this way? I will time mine again when I get it working, but it seems to take quite a while longer than the web IDE.

The first compile takes a while because it’s clean (from scratch) compile. After that, only files that have changed are compiled.

I didn’t have to remove the Zadig driver and still got usb comms from the core.

So at this point, what is the most supported / easiest environment for this? I can run Linux in a virtual PC if needed as it looks like Windows is just not really a supported env here.
Sill - I winder how long it will be, or if the road map even includes, parity support in the “official” Arduino IDE?

I ask because frankly my dev box is to important to my day to day to destabilize byhacking in random bits and chunks from different locations, unofficial links and so on. So I am putting it into a VC anyway - so is Linux a more directly supported ENV?


That’s kind of what I was thinking too based on the bounty to rework the makefile. Problem is I haven’t been able to compile a second time yet. I wonder if installing the MinGW environment has done something? I did that to try to compile dfu-util sources… well I’ll try to uninstall and see what changes.

I decided to google the error first, and found the GNU make manual says:

‘missing target pattern. Stop.’
‘multiple target patterns. Stop.’
‘target pattern contains no `%'. Stop.’
‘mixed implicit and static pattern rules. Stop.’
These are generated for malformed static pattern rules. The first means there's no pattern in the target section of the rule; the second means there are multiple patterns in the target section; the third means the target doesn't contain a pattern character (%); and the fourth means that all three parts of the static pattern rule contain pattern characters (%)–only the first two parts should. If you see these errors and you aren't trying to create a static pattern rule, check the value of any variables in your target and prerequisite lists to be sure they do not contain colons. See Syntax of Static Pattern Rules. 

Here’s the files that it’s complaining about… these times are all from when I created the first build successfully.

And the first part of the application.o.d file:

I doubt this is MinGW related… so I think I’ll leave it installed.

EDIT: Ok, If I delete all 3 of the obj directories, it will build again… but I’m guessing that shouldn’t be necessary? :wink:

Allllrighty then… .I think this might be the issue but still don’t know enough to solve it.

I read that Make interprets the colon as defining a target pattern, and since this is technically all one line it thinks there are multiple target patterns.

Two sources claim the c:\ windows path should be generated in a more relative path manner so Make doesn’t choke…

But I have no idea how to do that…

@zachary @mattande any ideas?

EDIT: for now I just made two batch files…


rmdir /S /Q obj
rmdir /S /Q ..\..\core-common-lib\build\obj
rmdir /S /Q ..\..\core-communication-lib\build\obj



dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

@BDub - I’ll fire up a linux VM and get it running, then a windows one and work in this some - Makefiles and so on are within my sphere (as opposed to this hardware stuff :slight_smile: ) so I can actually be useful there!


Thanks @Soulhuntre! I’ve been searching and reading, trying to figure this out…

I renamed the paths in the application.o.d file like this manually:

And now the error is in the next dependency file. Here’s a before and after…

So if possible to make the GCC toolpath relative somehow I think that could be the best solution, or if “/cygdrive/c/” is valid for everyone (probably not) do some kind of renaming thing on the dependency file. I dunno, I’m not an expert here …

Windows (MinGW) is supported - I’ve been compiling on windows. There are some “gotchas” in the makefile that mean it doesn’t work fluidly out the box, but I hope to submit patches to fix these issues.