Upgrading the firmware in the P1's needed if app does not flash?

We’re attempting to move to P1’s from the Photons and have trouble:

  1. I successfully connect to the access point and claim the P1 on my account
  2. I successfully get the P1 to connect to the correct WiFi
  3. I can blink the LED from build.particle.io/build/new#devices

but then:

  1. I attempt to flash our app to the P1, like we flash Photons with “particle flash”. It executes without any error message, but Tinker remains on the P1, and there is no sign of our app.

What might be going on here, and how do I fix it?

I noticed that the P1’s run Particle firmware 0.5.x, instead of 0.6 like the Photons. I was expecting that they would automatically upgrade (that may have been a wrong expectation). Might that explain the behavior? The app is compiled with “particle compile” without further options.

If I need a Particle firmware upgrade, how do I do that? I was expecting a button somewhere on the website saying “push upgrade to 0.6 now” or something like that, but no.


What is the exact command and have you built the binary explicitly for P1 or are you trying to flash the Photon binary?

I doubt that. With any sort of recent CLI particle compile without options complains like this

C:\tmp\test\dmy>particle compile

Please specify the target device type. eg. particle compile photon xxx

Got this resolved. This is what I learned:

  • Thanks @ScruffR and everybody who’s always so helpful on the forums, even on a Saturday night!
  • I did not know that P1’s required a different build command than Photons
  • I did not know that one can flash a binary compiled for Photon to the P1, and there is no error message that I can see
  • I did not expect that the particle on-line build service is sometimes flaky. It happens that I execute the same command 5 times in a row from the command-line, no error messages in all cases, and the actual app arrives on the target only once.

Between all of the above, I got a little lost there on Saturday.

  • It would be nice if the compile/flash commands said something like “Your target is currently on firmware x.x.x; will upgrade to y.y.y” as a kind of progress message.

This isn’t entirely true.
Hence I asked this

If you used particle flash --serial firmware.bin then it’s true, that is the reason why I use particle flash --usb firmware.bin which gives me an error message if the binary won’t fit.

That’s usually caused by the firmware already running on your device.

I want to follow-up on the latter. Last week there were some instances where I needed to run the over-the-air flash command 20 (!) times in a row before the updated firmware arrived on the device. Due to physical constraints, flashing via USB or serial was not possible.

What exactly could be the reason for this? If it is the firmware already on the device, why would the 20th time succeed?

And – how would I debug this?

If your code starves the cloud task of processing time and/or interferes with the WiFi and/or is very interrupt heavy and/or uses ATOMIC_BLOCK and/or similar things OTA reliability can fet impaired.

1 Like