ARM GCC and Offline Bootloader Different Result from particle cli

I am attempting to set up a completely offline build process to deal with a network firewall and slow network issues at a work site. I installed all per the “offline” section of this instruction:

It works well with tinker. But with another application it is obvious that the .bin file is wrong (too small) compared to running “particle…” and the program does not work after loading though it resets and breathes ok.

I set things up by adding the same (as when running particle) set of code to a new folder in ./user/applications. I changed the name of the .ino file to application.cpp. I’ve even copied that application.cpp into /user/src.

In administrator cmd.exe:

cd firmware/main
make all program-dfu PLATFORM=photon APP=myCode

I’ve done make clean etc numerous times and as I said, tinker repeatedly compiles, installs, and works properly whenever I try it. I’ve rebooted, tried non-administrator…

I’m at wits end. Is there something obvious I’m doing wrong? To go deeper I could provide the verbose output of “make tinker” vs “make myCode.” I don’t see any clues in that. Or anything else needed. Thanks for looking.

So you have a folder ./firmware/user/applications/myCode/ that contains your application.cpp (although the name is irrelevant as long it is .cpp)?
And you have checked the binary in ./firmware/build/modules/photon/?

BTW, just changing from .ino to .cpp is not enough.
With .cpp you need to have #include <Particle.h> and possibly required function prototypes in place, since there is no Wiring preprocessor doing this for you, which would be in cloud builds.


Including the Particle.h header line as you suggested was the solution.

I would have thought the linker would croak without it.

Anyway, on this day, at this moment, you’re a genius!


1 Like

Grumble…I tried on another PC, this time Windows 10. The other was Win 7. Now I’m getting the same problem again on that new PC. It’s still ok on Win 7. I’m not sure I did:
"And you have checked the binary in ./firmware/build/modules/photon/?"
properly. What do you mean by “checked?”

Additionally, sometimes I get the message “fatal error: Photon.h: No such file or directory compilation terminated” but not always. If I start over from scratch it does not throw that message.

It shouldn’t be sometimes but always …

… since it’s not Photon.h but Particle.h :wink:

Since this is the place where the binaries should get put after a successful build, I just wanted to point you there, in case you didn’t find your .bin.
Took me some time to locate my binaries at first :flushed:

Yea!! It worked. It was the typo. What a silly one, too.

Thank you.

By the way, it would be helpful if there were a unique #define test for this compiler setup so my code is more portable. I use #ifdef ARDUINO to deal with arduino platforms for example. I searched a bit without any luck. Do you happen to know if the virtual environment we’re creating using the ARM GCC has any unique #define available for C++ compiling?

You mean something like #ifdef PARTICLE? :wink:

A lot of ported libraries use that already.

My dumb. I had thought, because of my typo regarding PHOTON instead of PARTICLE, that “particle compile…” did not like “#include PARTICLE.h” when in fact it was complaining about “#include PHOTON.h” Two steps forward to cancel out one step back. “#ifndef ARDUINO” works just as well. Thanks again. I can now port this program to three PC types and two targets for use in my class. I need to buy some more photons for the class.