For reference, here is some feed back on the new firmware rc.26 made available last night.
When flashing OTA to my existing mesh networks, build.particle.io returns a “Flash unsuccessful.” fairly quickly. However, I can see on the device it starts flashing magenta and it continues to flash magenta for a long time. Presumably, it is doing the “safe-mode self-healer” thing that takes a while. The one Argon I flashed on my home network seemed to have all LEDs off for an extended period which tempted me to want to power off or reset the device. But, I waited patiently and the flashing magenta started or came back eventually. Total flash time is about 2-3 minutes.
Flashing the Xenon acts just like the Argon with a quick “Flash Unsuccessful.” in WebIDE and then and extended period of magenta flashing (seems to take a bit longer than the Argon but not much.)
Just with the last 2.5 hours of testing, it seems that the marco-polo heartbeat tests still do not respond 100% of the time with only the Argon upgraded. I am flashing the Xenons now…
The atypical OTA flashing behavior is a known issue and will occur the first time you flash code to a device running 0.8.0.rc-25. It was necessary to work around a bug in 0.8.0-rc.25.
The first time you flash code from the Web IDE to a device running 0.8.0-rc.25 that targets 0.8.0-rc.26 or later, the first flash operation will fail but it will start a mandatory Device OS upgrade. You can then flash your user code again. This will only happen on the first flash from 0.8.0-rc.25 to 0.8.0-rc.26 or later from the Web IDE.
I have same experience, from the Particle App on IOS, with one Xenon, tried to flash it 5 times, without luck, I was able to flash my second Xenon as well as the Argon
Yeah, when you click on the “show raw” at the “Flash unsuccessful” error, it will actually say it is installing a mandatory upgrade (I have to admit, it is a little bit hidden).
I also did a test of the new 0.8.0-rc.26 firmware. I have a one Argon, one Xenon mesh, which has been running for about 22 hours, and both devices are currently breathing cyan. I have “heartbeat” code running with the devices sending Mesh.publish to each other with 10 second delays. The Argon should get a publish every 20 seconds, and I kept track of the longest delay between receiving them. That longest delay was 50 seconds, so at least one mesh publish must have been missed. I’ll do finer grained testing today to determine how often either of the devices loses connection to the cloud, and how often a mesh publish is missed.
I have the same issue with one of my Xenons... I did the OTA flash, then it goes through the blinking magenta and eventually goes to breathing cyan and is running user code OK (as indicated by the heartbeat on D7 LED). But there are no online events in the console for it and after about 2 minutes of running, it does an SOS-7 blinks-SOS, then reboots, repeat. It won't register any variables or functions either.
EDIT: Don't forget to target the new OS version when switching to another device in the IDE. Seems to have been my problem. After re-flashing and making sure the correct OS is selected, it flashed, came back online and is fairly solid right now.
UPDATE: I’ve uploaded new binaries that enable logging from an ISR.
I would appreciate if you could flash the following debug system firmware. They will automatically log on Serial1 @ 115200, you should not instantiate Serial1LogHandler in the user application. Unfortunately we cannot reliably log from an ISR to Serial. If you don’t have an UART-USB adapter, you can use another device running a simple app and connecting its RX to TX of the device being debugged.
Running RC26 and Marco Polo on an Argon and 3 xenon my argon locked up overnight with cyan on and the marco light on. The xenon’s went fast flash green.
resetting just the argon restored marco polo activity so the xenon’s were still ok.
So there is an RC26 argon lockup issue with marco polo.
I would recommend using the most recent version of the MarcoPolo code which is at v0.3.1. I’m hosting the updated code on github. I made some changes on the Marco code to move the cataloging of responses outside of the subscribe call back. I wanted to ensure that no responses were missed because the Marco code was “busy” when the response is received. I also added serial debugging output which shows all the responses received, in what order and the number of millis() it took to respond.
However, I did not change anything on the Polo code which would affect anything really. I added Particle.variable to the Polo code so that you can verify the firmware version (at console.particle.io) after flashing new code. And I added a method to select an external antenna on startup if D4 is high.
I had super-high hopes last night when I left my office because I was getting like 98% of the responses. But now this morning, I see that one of my Xenons dropped off the mesh. It was still “beating” but for some reason wasn’t publishing to the mesh… or the Argon wasn’t receiving… not sure what to make of that. Now I took that Xenon, reset it, and moved it to within a few feet of the Argon and it’s still being a bit flaky.
@ninjatill At this moment, Mesh_MarcoPoloHeartbeat_Polo.v0.3.1.ino and Mesh_MarcoPoloHeartbeat_Marco_v0.3.1.ino are containing the same code on GitHub (both the Polo code)
@ninjatill Thanks for the heads up and for posting the update.
I’m now running v0.3.2 and I’ve forked in github in case I add features (but I haven’t yet)