Installing on Spark Photon



I’ve just got a Spark Photon and I’m trying to set it up but I’m a bit lost with all the outdated documentation.
So I’m wondering which version and branches I should run:

  • spark firmware : vanilla from spark/firmware with branch hal or latest?
  • brewpi firmware : from BrewPi/firmware/ with develop branch?
  • brewpi tools : from BrewPI/brewpi-tools with master branch ?

Thank you,



I just pushed a few changes for the photon and new board version.

In brewpi firmware: feature/sparkv2
In spark/firmware: latest

In BrewPi/brewpi-tools: have not looked at it yet.
In BrewPi/brewpi-script: develop

You will have to make sure your photon is running the latest modules from spark/firmware. The BrewPi firmware is easiest to flash by adding program-dfu to make.

I will update to do all of that for you once the BrewPi Photon release is out.

When building the firmware yourself, also look at:


Ok, now it’s clear but still, can’t compile the brewpi firmware.

The spark firmware is compiling (from main/, using make PLATFORM=photon all) and uploading to the photon very well.

Then, I cd into firmware/platform/spark/ and make now complains about a missing “ymodem.h” if I run it without argument or complains about undefined MODULE_VERSION[1] when running with make PLATFORM=photon. I’ve cleaned everything many times.

Any hints?


[1] In file included from src/module_info.c:2:0:
…/…/…/dynalib/inc/ error: #error MODULE_VERSION not defined
#error MODULE_VERSION not defined


My spark firmware branch is latest
My BrewPi firmware branch is feature/sparkv2
I do not have any untracked changes and build with make clean all PLATFORM=photon.

Also try running make clean all PLATFORM=photon program-dfu in spark-firmware/modules


I’m now running exactly the same versions as yours, freshly checkout’ed and still getting this error :confused:

Maybe that’s a compilation environment issue?

I’m running Ubuntu/Linux with gcc arm-none-eabi-c++ (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288].

Also, i’ve noticed that when I pass “PLATFORM=photon”, MODULE_VERSION is no more defined in GCC compilation arguments:

  • without PLATFORM=photon:

    arm-none-eabi-gcc -DSTM32_DEVICE -DSTM32F10X_MD -DPLATFORM_THREADING=0 -DPLATFORM_ID=0 -DPLATFORM_NAME=core -DUSBD_VID_SPARK=0x1D50 -DUSBD_PID_DFU=0x607F -DUSBD_PID_CDC=0x607D -DSPARK_PLATFORM -DFLASHEE_EEPROM -DINCLUDE_PLATFORM=1 -DPRODUCT_ID=0 -DPRODUCT_FIRMWARE_VERSION=65535 -DUSE_STDPERIPH_DRIVER -DDFU_BUILD_ENABLE -fdata-sections -DBUILD_NAME=“0.2.10-28-gb794a28” -DSPARK_PLATFORM_NET=CC3000 -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -DMODULE_VERSION=0 -DMODULE_FUNCTION=3 -DMODULE_DEPENDENCY=0,0,0 -DRELEASE_BUILD -I./inc -I…/wiring/inc -I…/system/inc -I…/services/inc -I…/communication/src -I…/communication/lib/tropicssl/include -I…/hal/inc -I…/hal/shared -I…/hal/src/core -I…/platform/shared -I…/platform/MCU/STM3[…]

  • with PLATFORM=photon:

    arm-none-eabi-gcc -DSTM32_DEVICE -DSTM32F2XX -DPLATFORM_THREADING=1 -DPLATFORM_ID=6 -DPLATFORM_NAME=photon -DUSBD_VID_SPARK=0x2B04 -DUSBD_PID_DFU=0xD006 -DUSBD_PID_CDC=0xC006 -DSPARK_PLATFORM -DINCLUDE_PLATFORM=1 -DPRODUCT_ID=6 -DPRODUCT_FIRMWARE_VERSION=65535 -DUSE_STDPERIPH_DRIVER -DDFU_BUILD_ENABLE -fdata-sections -DBUILD_NAME=“0.2.10-28-gb794a28” -DSPARK_PLATFORM_NET=BCM9WCDUSI09 -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -DRELEASE_BUILD -I./inc -I…/wiring/inc -I…/system/inc -I…/services/inc -I…/communication/src -I…/communication/lib/tropicssl/include -I…/hal/inc -

Maybe there’s a missing include when using this flag? I see that MODULE_VERSION is defined in a from the spark firmware.

I’ve also tried to run make from the module directory of the spark firmware and everything is running smooth and the photon gets flashed correctly.


I am now getting the same issue on my work PC.
My home PC and work PC have the same version of gcc and the same branches checked out.

@mdma can you help us out?


I found something, on my work PC, I had make.exe on my path twice:
Both in:
C:/MinGW/bin (make 4.0)
C:/MinGW/msys/1.0/bin (make 3.81)

On my home PC, I only had the second one. And voila, when I removed the first directory from the path, the build worked.


That sounds a good track but I’m afraid it’s not that easy to downgrade make (4.0 here) using the package manager of a distribution. Maybe the build system was slightly changed and it needs to be reflected in BrewPi firmware?

@mdma do you have any record of something changed in spark’s build system to allow it to be compiled using make 4.0+? I’ve searched the web to see if there were breaking changes between 3.8 and 4.0 or a porting guide but found nothing.



I got some deprecated warnings on 4.0, maybe that’s a clue?
Matthew did all the makefile magic, so I don’t really know the specifics, but he’s on vacation now for a week.


Additionally, there is a bug in the latest branch and in the latest release in the Particle repository.
It has been fixed in develop, so I would recommend building develop instead of latest. The bug is related to I2C and causes a deadlock when reading temp sensors.

I have built the images and put them in my personal repo for pre-release testing:

You can automatically flash them with from:


Thanks Elco. I’ll be away until August 10th but will try to figure out why I can’t compile that based on your clues once I’m back.



I am trying to compile and getting the same error:

In file included from src/module_info.c:2:0:
…/…/…/dynalib/inc/ error: #error MODULE_VERSION not defined

Also I am using Ubuntu and make 4.1.

I have tried both master and develop branches.

@glibersat did you manage to find out what was wrong?




So far, I’ve only used builds available on github but when I was trying to compile, I think the problem was because of make being too recent. It seems to behave differently with make ~3.9. Maybe @mdma has a clue about that? Does the photon build require a make < 4.x?



Yes, building from source requires make 3.81. Make 4.x is an entirely different animal and being a major version rev isn’t 100% compatible with the 3.x