Oaks not updating

[Grisbane]

I'd like to start a new thread for all of us who have not been able to get our Oaks updated.

I have 2 Oaks and have been trying to get them updated via http://rawgit.com/digistump/OakSoftAP/master/config.html for 3 weeks now with no success.  I've tried multiple times almost daily.

I'd love to hear what others have done to make this work.  Those who are also having trouble can join and get updates to this thread and hopefully drop off as their Oaks start updating.

Thanks!

[koioslabs]

I had a lot of trouble getting mine to update, what worked was to move it as far away from my laptop as i could, maybe I just got lucky. I also was as far from my multiple ap's (all on same ssid) as I could get in my home.

I'm on a late 2013 macbook pro...

[DeuxVis]

What I don't understand is why there is no available information about how to update it through a usb-to-serial adapter.

This is certainly possible ? Or am I missing something obvious ?

[Grisbane]

Thanks koioslabs!  I've tried configuring 2 different Oaks to go through 2 different wireless routers from different power supplies and different locations.  Still no go.  I don't think that the laptop/computer matters as much since it all happens through the rawgit.com site.

Which brings up DeuxVis's point.  Why can't we just access these devices through our USB ports on the computers like any other Arduino device?  Particle.io sounds convenient for some, but should not be the ONLY way to get updates and upload programs.

I'm sure DigiStump is working hard to get these fixed, but more communication would be nice, even if just to acknowledge the problems and let us know they are working on it.  If that is happening in a distinct location that I'm not aware of, please someone let me know.

Thanks!

[tcarleton]

Can someone post a list of "good" routers (aka: works with the current update process)  I'm not convinced this is a router issue, and I'm willing to run to the store and buy a couple of "good" routers for the cause to test that theory.

I've skimmed through the SoftAP repository and it appears (to me, who knows nothing about javascript) the connectivity to the cloud providers is obfuscated. There can be many valid reasons for it, I'm not criticizing that, but it makes it hard to reverse engineer the firmware download process for troubleshooting.   (Are we downloading multiple payloads from multiple hosts? Are the hosts globally load balanced but I'm getting sent to the other side of the world? Is there a bad hop on my providers side?)

Continually trying updates has shown that I have two different routers that sometimes work and sometimes fail. I've had Oaks activate in three attempts, others that took attempts over several days to activate. I'd like to help, but failing a method to load the firmware from my own network (eliminate everything past my router) I don't see a point in trying more updates.

So, if anyone has a list of known good routers for the firmware updates (ideally, Erik says they work), I'm willing to eat the cost for a couple of models and try them.

[digistump]

Acknowledgement and work on these issues is happening both on github.com/digistump/OakCore and on Kickstarter updates.

You can't connect an Oak to a USB port - as we've tried to make clear from the very start, it is an OTA only device, USB is power only. You can use a USB to Serial adapter to load things on to it (it works!), but that of course isn't the main goal. As far as Particle.io being the only way - you can also use a serial adapter, you can use a local particle server, or you can use your own custom update firmware. That said, the particle updates are working for everyone who has got that far, it is the initial update from our servers (not Particle) which comes to the Oak over HTTPS that isn't working for some.

As far as how to update with a usb to serial adapter - the reason for putting the Beta out there is to get feedback on the update process and firmware, if we opened that up right at the start then we would not have gotten much feedback that we need to solve these issues. Not to mention my focus has been on solving the issues as best I could first. We'll be releasing the bin file to update to the latest firmware along with the first non-beta firmware release, if nto sooner (as soon as I get a chance). You can build it form the OakSystem repo already.

-- while I was writing this tcarleton posted their message---

I'm not convinced it is a router issue either, not convinced either way, as I'm still only able to reproduce the issue very sporadically - and I'm working on some firmware that people with serial adapters that are having issues can run, and it will generate a better log to serial that might help discover what is wrong. I suspect it may have to do with connection speed/router speed/basically how quickly the data is being thrown at the Oak.

Everything is SoftAP is minified and pulled into a single file because your browser needs to have that whole file in memory, since you disconnect from your internet during the process. It has little to do with the update process, other than the wifi connection itself, if you watch the network inspection tab you'll see the Oak just gets your wifi connection data from setup, this triggers a restart to the update rom and that downloads the update from digistump's servers - the Oak doesn't get the update from Particle. That said, you can find all of the sources for the included js on particle's github (github.com/spark) in the SparkJS/ParticleJS project and the softap-setup-js repos - we should pull those all into sources file in our repo in the future.

[tcarleton]

Thank you for the update - it was very helpful!

[PeterF]

Indeed... thanks for that Erik.

If you want any more Oaks donated to the debugging cause... I have three virgin Oaks (out of five) yet to be powered up for the first time, and have 3V3 USB-to-Serial adapters. The other two are running v0.9.3 and running some simple blinky sketches, after an hour or so of persuasion to update and register on Particle. I hit two hurdles in the end - the first update (two to  four tries fixed that), and particle registration (connecting via a second AP seemed to fix that). Haven't had any issues since then. I got SoftAP to kick in again, and connected back to the normal AP/router, and didn't have any issues with them since.

Pete

[exeng]

Been trying to bring a second Oak up to the beta 3 firmware without success. It's extremely frustrating to literally spend hours just trying to get firmware installed.  I have observed two patterns that present themselves when the upload fails. The first one, I typically see when starting a first update after a fresh restore. When the firmware update is initiated by SoftAP the rapid flash appears to last almost long enough to complete but does not yield a successful install. Subsequent retries more often than not, flash rapidly for about 5 or 6 times, then back to the slow flash. The latter is an obvious sign of failure but now I have to wait for the timer to run down to check for what I already know will be the result. Seems like the fails are either early in the update or very close to the end.

Has there been any clues as to why these uploads are failing? Is it dropped packets, timeouts, race conditions? Is there anything we can do to help debug the problem? I've literally spent half the day trying to update this one Oak. At least I have 1 that is up and running.

[DeuxVis]

Thanks for taking the time to reply erik, I understand.

I've been unsuccessful in getting the initial update onto any of my 3 oaks, I'll try on a friends wifi router when I get a chance.

[Grisbane]

Thank you for the reply Digistump/Erik!

I'll start looking for communication updates on the sites that you listed.  I think knowing where to look will help others having similar issues.

I just got my USB-Serial adapter in and will figure out how that works next.  I'll start with restoring them to factory and will move on from there.

Thanks for all your hard work!  I know this is beta and am glad to be a part, even if beta's can be quite frustrating at times.  The "happy dance" when it works will all be worth it though!

Thanks again!

[exeng]

UPDATE... Tried again this morning and the Oak updated on the first try. All I can surmise is that Wireless network traffic is much lower this AM than it was last night and perhaps this helps ensure that packets are not dropped.

If my frustration (in my previous post) sounded like a complaint, it was not. Just an expression of the frustration that occurs when you just want to get the update to work and you have no control.

Yes, Erik (Digistump) is done an excellent job supporting the Oak and communicating to us all.
exeng

[digistump]

I was finally able to replicate the update issues reliably - specifically they seem to involve fast connections allowing the device to download data so fast that each loop to write the data to the Oak's memory goes so fast that it outpaces the Oaks ability to erase the next block of memory before writing it. (This bug seems to possibly have some deep roots in the chips internal libraries).

I was not able to reliably replicate this previously because, being in a rural area, my internet connection is slower than many (1.5mbps on a good day) and all of my local testing was done with extensive debugging output turned on, which slowed down the loops enough to prevent this from showing up. Stripping my debug output down significantly and ensuring no output occurred during the write/erase loops, while also hosting it locally within my network allowed me to reproduce the issue 100% of the time.

My fix is to have the web server send only one sector worth of data every 50 milliseconds. This results in a total time of at least 150ms per sector, which seems to fix this issue. I've tested it locally and remotely with 100% success.

This fix is live and you can test it by retrying the update (no changes to the Oak or Config App needed).

If the update still fails to work then please download the newest OakRestore here (https://github.com/digistump/OakRestore) and follow the instructions to provide the debugging output so we can look into it further, as this very well could be one issue of several.

(Sorry that's very long winded as I'm copying the text from a Kickstarter update I'm preparing, but seems worth posting here)

[rwohleb]

Does this server change only affect that initial update/provisioning via SoftAP? It took a crazy number of tries, but I was able to get it done last week. However, deploying code via Particle has been hit-or-miss and I'm wondering if it's a related issue.

[digistump]

Initial update only - Particle is a different beast that we haven't heard much feedback about issues with except for when the update does not start at all (hopefully fixed in the next release that I'm putting together now, along with wayy faster updates from particle) - please let me know if you are experiencing other issues with the Particle updates