Particle Device OS Updates: Comments

I am experiencing problems for updating all of the photons I flashed OTA since last Friday (since the update). None of them can run any program anymore. I could have one working again by updating it via usb and dfu. But I have several devices that I gave to testers, and I cannot get them to connect via usb. How am I supposed to do to update them, or just get them working again ?

Thank you.

Sorry you’re having problems with the 0.4.4 update. Please send a PM to me and @Dave with the device IDs of the affected Photons and we’ll look into the issue for you.

Please try flashing a different app from Particle Build (Web IDE) - that is the process that starts the update process. The update is in 3 parts - normally they are all delivered after flashing the app once, but in some cases it’s been necessary to repeat the flash process.

Thanks,
mat

PM sent.

I already tried to flash different apps (blink LED) many times, without success.

1 Like

Trying to flash from particle cli known fix for 0.4.4 but having Error writing firmware… error

Please try with sudo, alternatively see this post for providing the required permissions. Dfu-util doesn't connect to core on Ubuntu [Solved]

Here’s an update on the current state of updating 0.4.4 firmware:

Ways to update to system firmware:

  • build an app in the Web IDE and flash this to the device.
  • use particle flash <mydevice> source.cpp to build and flash from source

Unsupported:

  • particle compile + particle flash myphoton firmware.bin
  • particle flash myphoton firmware.bin
  • flashing from Particle Dev

The system will send 3 binaries - one large one (system-part1), a smaller one (system-part2) and finally your application binary.

At present, it is sometimes necessary to repeat the process to ensure all binaries are properly transferred.

4 Likes

The main attraction with the 0.4.6 release on the photon is the introduction of multithreading, specifically that the system code runs on it’s own thread so the application loop runs freely.

To get a feel for how your application runs with the system thread enabled, you can try a simple blinky sketch:

SYSTEM_THREAD(ENABLED);

void setup()
{
   pinMode(D7, OUTPUT);
}

void loop() 
{
   digitalWrite(D7, !digitalRead(D7));
   delay(500);
}

You’ll notice that the LED blinks from quite early on in startup, through the device connecting to WiFi, connecting to the Cloud. If you flash data OTA, you’ll see also that the LED keeps blinking right up until the device has to reset to apply the OTA update. Exciting stuff!

The system thread feature is a Beta release - feedback, questions etc… very welcomed so we can refine this and push it towards a full release in 0.4.7.

Happy threading :smile:

2 Likes

Very exciting for sure! Thank you for this release!

Question, since the multithread feature is beta… Is there any risks using it (memory leaks/crashes/etc)?

Memory leaks have been tested for, but certainly there will be less RAM until we tune the system more rigorously and there is the possibility of crashes, particularly when entering/existing listening mode, or with code interacting in ways that couldn’t happen before.

All of this only when SYSTEM_THREAD(ENABLED) is added - without system threading the firmware is intended to be at least as stable as 0.4.5, if not more so due to the various fixes added.

@mdma, This is so COOL! This is available for local building only I assume at this point? When do you expect the Web IDE to be updated?

0.4.6 is already in the web IDE :wink:

Does this affect code which was previously stopped when there is no Wi-Fi connection ?

e.g. Will my code run now with no Wi-Fi when it would not run in previous releases ?

It’s funny you mention this blinky example, I have a similar piece of code in an IRQ that responds to the magnetic reed switch in an anemometer - this code blinked (flipped the state of) the LED in 0.4.5, but does not blink the LED at all in 0.4.6:

int BLINK = D7;

void wirq()
{
    # other logic to increment a value here    
    digitalWrite(BLINK, (digitalRead(BLINK) == HIGH? LOW : HIGH));
}

I haven’t put much time into trying to figure out why, but I will probably try your way of writing it (as it’s easier to read anyway). I didn’t know that HIGH and LOW are actually synonyms for true/false :wink:

Yes your code will now run and run and run, while the Wi-Fi does whatever it needs to do to maintain a connection :smile:

Run @mdma’s example above and you’ll be so amaze!!!

I just ran this code and it works fine, can you try this one?


SYSTEM_THREAD(ENABLED);

void setup()
{
   pinMode(D7, OUTPUT);
}

void loop() 
{
   //digitalWrite(D7, !digitalRead(D7));
   digitalWrite(D7, (digitalRead(D7) == HIGH? LOW : HIGH));
   delay(100);
}

I did a test via a hotspot and noticed that the Photon does a SOS once I kill the hotspot.

Not sure if its related to the hotspot or if the same behavior will happen on a regular router as well.

What is the number of blinks after the SOS?

I just tried blocking Wi-Fi by removing my external antenna on my u.FL only photon (chip ant removed), and then covered my hands around it to completely weaken the RF it sees… it would blink CYAN for a bit, then drop back to blinking GREEN. When I reconnect my external antenna the connection is restored very quickly. Best part is watching that D7 LED blink steadily the entire time :wink:

I’ll try actually switching off my Internet connection in my router in a little bit and see if there’s any difference.

Does this SOS happen with threading disabled? If I can request that everyone who finds a problem also checks with threading disabled that will help us a lot in narrowing down the problem.

Works fine with threading disabled. Goes immediately flashing green once I kill the hotspot.