Web IDE flashes timing out

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?
  • Are there other things I should check at my end?
1 Like

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.

Could you try placing the device in safe mode to ensure the user code isn’t interfering in the process in some way? Worth a shot.

1 Like

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 %

I did try Safe Mode a few times, and it had no effect. I even tried flashing Tinker with the device in Safe Mode and that timed out as well.

Should I contact Particle Support, or are they aware that people are having problems like this?

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 :wink:
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?

Thanks for asking … I’ve been bit by that one before.

The lights change as the flash is applied, but the flash process often times out before it gets that far.

Everything seems to be working properly at the moment, but there were a couple of hours where I could not flash in the morning.

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.

2 Likes

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.

1 Like

Interesting. Are there any other scenarios that would cause a lot of timeouts, even with good cell signal? Would larger bin files cause an issue?

Keeping the controller occupied in tight loops (or similar) is always a bad thing - OTA or not.

Sorry, not sure what you mean there. We go through our main loop on roughly a 60ms cycle, the system’s not getting stuck in delays or anything…

That was a general statement - I have no means to know what your code does or doesn’t do.