How can you develop with a >2mn wait between each flash?

[PeterF]

Reposting message here as OP had trouble posting new thread and I didn't want it to get lost in the other thread

marcmerlin: Ok, so apparently I can't even open a new thread, it's just left in limbo with no one to moderate/approve it.
As a result, I'll post here, sorry

Subject: how can you develop with a >2mn wait between each flash?

I just wasted hours, and I mean hours, setting up my first oak. First it wouldn't connect to wifi and get the update (finally it got it) and then it would not show up on particle, so I tried again and again and again until I found that I had to connect to the device, get the device id via 192.168.0.1/device-id and manually add it on particle.
Why is this still broken and not working out of the box?

Anyway, now I can flash blink, but it takes 2mh to flash, each time (not counting the timeout on the arduino side that says the flash has failed when it fact it's still going on)
[22 :41: 53] Event: spark/flash/status - started
[22 :43: 45] Event: spark/flash/status - success
[22 :43: 46] Event: spark/status - offline
[22 :43: 55] Event: spark/status - online

How can you write code and test it with such a lag? I can't go to the fridge or get a coffee between each cycle, I'd end up fat and going to the toilet all the time...
Is everyone putting up with that, or are you doing local flashing, or testing on another esp8266 board first?

[PeterF]

Firstly, it sounds like your issue is related to the discussion that was happening in this thread: Arduino IDE says - Error : Flash timeout - flash failed. - But, it still works! I didn't post this under that, as although it is related, your question is different

My belief is that this issue has come about due to some change on the Particle stack resulting from their recent outage. However, I haven't dug into it at all, so I could be completely wrong. Having said that, I need to go make a post on their forum (or check to see if somebody else has already and add it it) to see if it is something they can check... they've been pretty good in the past on checking up on their Oak support infrastructure.

But my answer to your question this has only been an issue for the 1.5 weeks, so it's pretty new to a lot of us I think - and you're lucky it is 3 minutes... mine takes 5 minutes to flash!!! A lot of us have Oaks in service, and no need to flash them, so it hasn't affected us *yet*. When I decide to do my next lot of Oak work, I'll be doing either Serial uploads, or if I don't really need particle, I'll wipe the Oak stuff and use the ESP8266 Arduino stuff and it's own OTA support (which didn't exist when the Oak was being developed). Local server stuff isn't an option at the moment as the Particle local server stuff doesn't appear to be working, and Erik was working on an alternative but is MIA.

Regarding your setup issues... there are issues in the updater firmware that shipped, hence the issues are still present. The workaround was to simply use the Easy Serial update process, and bypass the whole first run update process.

Anyway, that should be enough for now

[emardee]

The bottom line is that flashing used to be very fast until very recently! We aren't sure what caused the recent problems, but I would expect that once the issue is resolved, flashing will be fast again!

The first update was always the hardest (even before this recent problem) as you have discovered, but once you get past that, there is every reason to enjoy the platform as it should be flashing very quickly for any sketch upload each time you tweak the sketch.

Mike

[marcmerlin]

Thanks for replying, good to know that the very slow speed is temporary. Yes, I get the timeout too and flash that succeeds 1mn later or so. I didn't realize the 2 were related.

As for the firmware, I thought once my first firmware update succeeded (it did) I would end up with an oak that connects automatically. Clearly that was not true and even after the latest firmware was downloaded, I had to go through the cumbersome procedure to find the device ID and manually add it on particle (sure, not so bad once you finally figure out why it's been failing all this time and that you have to do this)

Anyway, I'll stay put and see if it gets better again, or just install some serial flashing on them and flash them like a regular ESP8266, skipping all the cloud stuff.

[PeterF]

Yeah, at the end of the initial update, it does try to connect to particle and register itself, but sometimes that doesn't work, so you need to manually claim it. Annoying when you don't know about it, but at least you should only need to do it once per Oak (per lifetime of the Oak).

Just be aware that to do serial flashing of the Oak, you need a USB to serial converter, and one that is 3.3v compatible (not a 5v one!). I always recommend CH340 based ones as they seem the most reliable and are cheap... but any genuine FTDI or other brand chip is fine.

[postuma]

Link for ESP8266 OTA: http://esp8266.github.io/Arduino/versions/2.0.0/doc/ota_updates/ota_updates.html.

Anyone have personal experience with it & Oak, as yet? I plan to try, but with some trepidation ...

[PeterF]

Just so you know, that's for the v2.0.0 version of the ESP8266 Arduino boards package, and 2.3.0 is the current version... and I believe something major changed in the OTA stuff around 2.1.0 to 2.2.0... so have a look at this version instead... http://esp8266.github.io/Arduino/versions/2.3.0/doc/ota_updates/readme.html

I have tried it out briefly, and it worked great. I didn't bother doing much more than grab the OTA example as is, and shove it on, and then modified it to also blink the P1 led and then load that OTA, but it worked great, and was extremely fast... I believe I said 5 seconds to flash before... I could even be over-estimating it as it was really fast Have yet to try any further... but it certainly looks promising.

[postuma]

Great! Thanks!

[pkourany]

Particle has now fixed the OTA delay issue!

[PeterF]

Damn you! I was just coming over to say that bryce over at Particle had looked into it and squashed the bug.