In the past few days, I’ve seen an excessive number of timeouts when I attempt to flash devices via the Web IDE. Most of the time everything works great, but I’ve experienced “blocks of time” when flash timeouts are common. My solution has been to walk away for a while, and, for the most part, that has worked … everything is normal when I return. This evening, walking away did not help. In the past three hours, I’ve clicked the lightning bolt about 30 times, and my device was only updated twice. I should note that the problem is only with flashing. Compiles have always worked fine.
I’ve searched for issues on my end, and everything seems okay:
Clearing cache, switched browsers, flashing other code (like Tinker), makes no difference.
My router tells me that it has a 31Mbps down / 29Mbps up connection to the internet.
My Xenon is mounted on an Ethernet FeatherWing and has a wired connection to the router and the Xenon reports regularly to its MQTT broker. Particle Console tells me that it normally has round-trips of 40-50ms, with occasional readings ranging from 2ms to 150 ms.
When I encounter one of these troublesome time blocks:
Are there other details that I should be looking at in the Particle diagnostics?
You are not alone with this experience. I suspect that there are periods of high use on the compile and flash services that are causing timeouts. How big are the binaries you are flashing.
Thanks for letting me know that others are seeing this also. I didn’t find recent posts on the topic, so I thought I was alone. The binary that I’ve been working with is < 400 lines of code, but I am using three libraries emonLib, OneWire, and MQTT. Here is what a compile tells me:
Output of arm-none-eabi-size:
text data bss dec hex
17260 124 2276 19660 4
In a nutshell:
Flash used 17384 / 110592 15.7 %
RAM used 2400 / 20480 11.7 %
It can be that your device is blocking the loop or somewhere flash has been disabled or reset is blocked. It is not the flash size. Maybe you need to check the code?
Some silly question, but better safe than sorry for not asking
Are you always flashing from the same machine/browser session?
If not, could it be that you have got a different devices selected as target?
Can you signal the selected device prior to the flash attempt?
Does the device ever respond with a magenta RGB LED or does it stay completely unimpressed by the flash attempt?
Are you using SYSTEM_THREAD(ENABLED)?
That’s another tricky one since your application is still running during firmware download and hence can cause it to fail.
Bingo. This is the first time I’ve used that. One of the examples that I followed for OneWire or EmonLib used that. I can’t find that example right now. In any case, I’m going to remove it to see if / how things change.
Thanks for the tip.
Status after one day: Only one flash timeout today. Things are looking good.
Status after 6 days: I’ve seen a couple of timeouts, but everything seems to be back to normal.
It appears that SYSTEM_THREAD(ENABLED) was the culprit.
Another silly… I do most of my programing on my desktop PC. I will occasionally take my laptop out to the physical site to ‘touch-up’ or monitor the device. I will end up being on WEB IDE on both machines on the same app, generating inconsistent results. Something to check?
For me with both SYSTEM_THREAD(ENABLED) and SYSTEM_MODE(SEMI_AUTOMATIC), I found that the flash would always time-out from the web IDE but then as soon as it timed-out the photon would begin the flash and complete successfully. I’m not sure that’s quite what you’re seeing though?
In case it helps, what solved it for me was adding a Particle.process() to the end of the main loop. According to the documentation this shouldn’t be required in threaded mode but who knows.
It shouldn't be required in non-threaded SEMI_AUTOMATIC mode either since Particle.process() is called between iterations of loop(). So if you are not using serialEvent() your own Particle.process() call will be executed back-to-back with the regular Particle.process() call.
When you get a time-out but end up with a successful update your actual flash takes pretty much the exact same time as the timeout period for the cloud flasher is set to (which can be due to threaded user code running duringe the download).
Thanks ScruffR, I’m not using any serialEvent functions. I’m not sure then why calling Particle.process() fixes the timeout, because as you said it would be called anyway.
That said, I haven’t tried the code without the process call since about 0.6.something so I’ll see if anything’s changed.
Is there a solution to allow for cloud flashing with SYSTEM_THREAD(ENABLED)? As in, is there some function call we can make to pause our code, but still run the RTOS so that it will update?
SYSTEM_THREAD(ENABLED) in itself does not stand in the way of OTA flashing.
Your code just needs to refrain from interfering with the update (e.g. Particle.disconnect() , WiFi.off(), …) once it has started.
