0.4.9 program from DFU fails


OK so my earlier enthusiasm for 0.4.9 may have been a tad too soon :-((.

I have a Photon and programmed it up with 0.4.9. Actually myself and my client have a few.

We can program up with code built for 0.4.7 and it runs OK. Much dicking around with updates followed by breathing magenta issues though. Not quite sure what I did to work around this :frowning:

We have a version of the same code - with a few changes, and this builds in Atom Dev, and uploads just fine. Runs works etc. etc.

So - build the bin again using the CLI, try to DFU this code in and we get -

Error writing firmware…CRC is invalid, use --force to override

So add --force (BEFORE --usb!!) and it says that it has worked.

The photon reboots then sits there breathing magenta and NOT running my app (I use Serial1 for debug), and its printing nothing.

Press reset - reboots, connected and breathes magenta - still no serial output.

Run FLASH from Dev code downloads, starts up and runs just fine :-O.

SO - in Dev just compile (No flash) so that we get a bin file (after flash its lost!!). Then load this using DFU and it works perfectly.

Rebuild same code using CLI and the bin AGAIN fails CRC.

Compare the 3 bin files and they are completely different :frowning:

Good one is 32396 bytes built 18:35
First CLI is 18154 bytes built 17:46
Last CLI is 26708 bytes built 18:38

Might I be so bold as to suggest that the CLI compiler is broken ???.

The following is the CLI output from the build

Memory use:
   text    data     bss     dec     hex filename
  32204     192   21416   53812    d234 /spark/compile_service/shared/workspace/6_platform_6_24_2/firmware/afc99afb14440f36ebae5929c12940971cc802759321ffdf290ad2a03a30/afc99afb14440f36ebae5929c12940971cc802759321ffdf290ad2a03a30.elf

grabbing binary from: https://api.particle.io/v1/binaries/56a90eb956dd1e6c117cd37c
Compile succeeded.
Saved firmware to: E:\Particle\Projects\HomeController\HC_060a.bin

So - the DFU reporting crc is bad should NOT be overridden with --force :open_mouth: - as it is quite correct - the crc is bad because the file grabbed is broken :-O.

Hope someone can understand this issue and fix it please ;-))

I use Dev to create and test code - then use CLI to make a clean build to send to my client - as the CLI is (used to be) the only way to find warnings and some error details. When CLI says its clean - I used to trust it :-O.

NB If a perticle dev wants my code I am willing to send it by private email/dropbox etc. - as it actually belongs to my client. It IS now quite complex though…

Edited - it MIGHT of course simply be the CLI - as I also updated that yesterday to the latest :open_mouth: - I WAS using 1.8.12 and am now using 1.9.3.

Best Regards


What version node are you running?
Should be >= 4.2.4

Really ???.

I am still running an OLD version - as per earlier requirements - ie it didn’t previously work with anything HIGHER than 0.12.x when I started using the Photon :-O. This was the advice as given on this forum :-((. In fact when I first started using the Photon - I originally installed 4.x.x and when that failed - I was told that the CLI etc. would not work with anything better than 0.12.x

You know - its why I have so much trouble with ‘open source’, lack of coherence…

Will upgrade node to the latest V4.2.6 - I assume that it probably won’t work with the actual latest - ie 5.5.0 ???.

Thanks again @ScruffR for keeping me on the ‘straight and narrow’…



OK upgraded Node to 4.2.6 and it compiles straight away and produces a working bin file this time :-O.

Might I suggest that someone who knows this stuff creates and maintains a document which defines the development environment needed for stable photon compilation please ??? - and that there is a notification system behind it to tell us mere mortals when it changes ???.

I ‘guess’ that I’d better update my Atom Dev installation as well so will have to trawl around to find how to do that !! - as ‘Help|Check for update’ says there is none - but I suspect that is simply referring to the base Atom code …

Thanks yet again @ScruffR :wink:

Well, that was an interesting diversion…

I downloaded and ran the ‘Particle Dev’ installer, extracted the Windows setup file and ran it.

The install failed a couple of times - log tells me that access was denied to some path or other - so I ran as administrator. That’s when all hell broke loose, and I got a ‘Malicious Malware detected’ warning (I run Kaspersky Total Internet Security AND MalWareBytes). System deleted the installer file and then ‘disinfected’ and rebooted my machine :-((.

So - I guess I will be sticking with the earlier version then !!!.



So - after trying (and failing) to install the latest Atom dev environment - the old version now no longer runs.

Is there anywhere I can get the older version please - as the ‘disinfection’ deleted the installer, which had overwritten the older installer :-((.

Also I was getting errors when running CLI particle - after installing Node 4.2.6, so I had to update the CLI again, and yesterday it was 1.9.3 - today its 1.10.0 :-O.

So now I have lost my Particle dev environment again :-((. Any ideas how to recover it please ???.



Any chance you could share the code you’re having issues with? I’ve got node 5.5.0, and CLI 1.10.0 which I could give it a shot with?


Thanks for responding, but after @ScruffR’s feedback I installed Node.js 4.2.6, then upgraded CLI to 1.10.0 and that now all works.

I have also managed to re-install Particle Dev (after my malware issues with the particle download) by getting direct from https://github.com/spark/particle-dev-app/releases/tag/v1.0.19.

So I am now fully operational again…

The biggest problem was that I was still using Node 0.12.7 (as advised by this forum some months back), and up until yesterday (0.4.9) my CLI worked just fine then it broke a compile (or download of the bin after a successful compile), without any warnings that the file was incomplete.

We really need a doc to tell us what tools we need to be using and when this changes, including how to upgrade them (easily :wink: :-O.

Basically - I need to create Photon code as an ‘application programmer’, so don’t want/need all the ‘noise’ of maintaining knowledge of toolchains etc. :open_mouth: - this is why I use the on-line compiler tools (which are great by the way!!) instead of installing the whole lot locally… Also comments when flashing telling me to use --force are highly misleading ;-O.

Sorry - not trying to ‘bitch’ here - just want to help you guys get this product finalised and released - as I see a GREAT future for these modules ;-)).

Best Regards


Glad you’re operational again.

I agree with you that the tools definitely need some work, and have brought this up with the nice folks at Particle as well. The problem with the non-online tools is that they get updated every so often (or their dependencies). That’s generally a good things, unless breaking changes are introduced. What makes this even more complicated is that people are using different operating systems (Windows, OSX, and various Linux distributions). Making matters worse is the fact that there are several different versions of said operating systems, which may, or may not, be compatible with the required software. Then there are also hardware/drive issues, like USB2 vs. USB3.
All things considered, there are virtually countless different configurations possible, which is a hell if your trying to get a stable release out. As you’ve noticed, the suggested version of firmware has changed in the course of time, as new features are implemented, and bugs are fixed. Tested those on all different setups with possible other programs conflicting is a humongous task, which can’t be dealt with considering the team size. If you’ve ever tried to install Windows, you’ve Probably noticed that even large companies like Microsoft struggle with that :confused:
Changed/updates need to be communicated in a better way, and tools need to be stabilized. Those are points I’ve been pushing for, and Particle is aware of these issues. With the upcoming release of the electron, hopefully some more resources will be available to tackle these points.

Good to hear you’re up and running again and I agree that things like this are frustrating.

I remember that - I meyself had given such advice during the periode where 4.x.x was rather new and CLI hadn’t been adapted to deal with unexpected changes in it. But this got sorted soon after.

And the “new” problem with 0.12.x was already mentioned to Particle a while back by others (including me), to remove 0.12.x from the supported versions list - as it isn’t.
But as Jordy said, keeping up with all these changes is a challange.

Im running nodejs with v0.10.36 but my CLI worked fine.

Would love to inspect the binary if possible. You can do it with particle binary inspect xxxx.bin


So are you using the current/latest CLI ???.

As for the bin - be my guest :smile: doesn’t really say a whole lot !!

CRC failed (should be 0c0f04d1 but is 2bf58c0b)
Compiled for photon
This is an application module number 1 at version 3
It depends on a system module number 2 at version 11

It doesn’t even tell me that one bin (good) is 32,396 bytes and the bad one is 27,484 bytes - so probably just truncated during download by the CLI :-O.

I DO fully understand the issues with different OS’s, hardware configurations etc. etc. - and I KNOW (first hand) that Windows can be a real nightmare. I have been a software (and hardware) developer for some 40+ years now ;-)) - yup I really am an old fuddy… :wink: - been installing Windows since pre 3.1 !!

So - my suggestion/request is not to circumvent the issues, but to maintain a document/web page etc which simply defines the ‘versions’ for the various tools expected and how/where to keep them updated. This would keep the docs all in one place rather than having to find from one source what version is expected, then find how to install/upgrade that etc. usually by trawling through the forum and/or remembering where it was originally downloaded from etc.

As always hoping that the feedback is useful…

Best Regards


1 Like

IMHO node.js is a brittle platform to build things on that aren’t deployed in your own sandbox (e.g. a docker/vagrant/virtual environment in the cloud.)

Too much version skew, and mysterious other behaviours for my liking.


You might think that about Node.js, and I do BUT Microsoft obviously wouldn’t agree :-O. Node is now well embedded into Visual Studio 2015 :-O.

They sell it as cross-platform mobile development - but in reality it just loads up a shed-load of open-source for you - and then gets the config wrong to-boot ;-)). I know - I wasted a load of time on that until I moved away and used Google’s Android Studio = much cleaner ;-)) - and I have used VS at least since the 90’s :-O.


1 Like