Error : An error occurred while flashing the device:

[exeng]

OK back to claimed and active. OTA still fails with same error.

At this point I have done all I can do to help figure this out. It's time for the big boys (Erik and Particle) to get involved per kh's recommendation.

[exeng]

My head is spinning...
This will either add to solving the mystery or add confusion...

If you remember I said I brought up a brand new Oak out of the bag under the same environment and steps as I have been using for the failing Oak. I also reported that the new Oak was working fine (and it is). In my desperate search for any and all info that would help, I dumped the "info" from both Oaks and it seems that the new (working) Oak somehow loaded version 6 and system-version 1.0.0 while the failing Oak has version 10 system-version 1.0.5. I swear I've been using the same process of restore/SoftAP update for both. Same restore master.

Failing Oak "system_version":10,"version_string":"1.0.5","meta_id":0,"meta_data":"","first_update_domain":"oakota.digistump.com","first_update_url":"/firmware/firmware_v1.bin"
New Oak "system_version":6,"version_string":"1.0.0","meta_id":0,"meta_data":"","first_update_domain":"oakotafallback.digistump.com","first_update_url":"/firmware/firmware_v1.bin"

Note the update_domain "oakotafallback.digistump.com" for the new Oak. Again, I'm pretty sure I did the same restore/SoftAP update steps on both.

Since the 6 / 1.0.0 combo is working, I'll try to get this on the failing Oak to see what happens.

[PeterF]

I'm happy for kh to prove me wrong, but I suspect that means the fallback server has an older copy of the firmware than the primary one. When you did the SoftAP update with the new Oak, did you have to tell it to update more than once? SoftAP is supposed to use the fallback server for retries, and that maybe how it does it (by changing the first_update_domain setting on the Oak), as it is the oak that does the actual update... SoftAP just gives it a not so gentle prod to actually go and do the update.

The easiest way to push the fallback firmware file onto your misbehaving Oak is to do the serial update, and use the firmware file from https://oakotafallback.digistump.com/firmware/firmware_v1.bin

The command line you need is at the bottom of the OakRestore page. The only difference here is to do the update, you connect P2 to GND on power on (not a typo, P2), putting the Oak into serial upload mode.

I can't tell you what version it actually for *certain* as I don't have a copy of the 1.0.0 binary any more, but I suspect it is actually v1.0.0, and hasn't been updated since the first stable release was pushed. The system_version numbering has a strange history meaning it doesn't always relate to the actual version of the firmware (hence the reliance on the version_string over the system_version to actual work out the firmware version installed :-/).

[exeng]

Pete, RE:

When you did the SoftAP update with the new Oak, did you have to tell it to update more than once?

I cannot remember how that exactly went down. But I'm sure I was going through the same process with the same files/environment when updating the new and failing Oak. So you can imagine my surprise upon seeing the different versions. And... since there seems to be no easy way to get version 6 system version 1.0.0, it must have been done (as you say) without my intervention.

I'll give your suggestion a try but if it fixes the Oak we'll lose the failing Oak. I guess, I can go through the normal restore/SoftAP to get back to it's abby normal failing state.
 

[exeng]

Pete, Could not download the oakatafallback image. Unlike the link to the latest oakota image link which prompts for download, the link you provided just dumps raw to the screen (also had to ignore certificate warnings). That said, I most definitely did not purposefully install version 6 system version 1.0.0 on the new Oak. But at least it works.

I'll just put the failing Oak back to it's failing state at version 10 system version 1.0.5 (actually it's still in that state) and wait on Erik and Particle assuming kh's request to them sparks interest in solving this.  Not going to touch my remaining Oaks until this is sorted out.

Really need to see more detail on the exchange and the traffic between Oak and Particle.

[PeterF]

lol... yeah, the certificate warning error is normal here... both the primary and fallback links will give them.... didn't realise the fallback image would't prompt for download, and instead show the contents of the file (as exciting a read as it isn't!)... I just shoved the link into my download manager so didn't browse directly to it. If you still want the image, you can grab it from my dropbox... freshly downloaded from a few hours ago.

Either way, all I think happened is the when time you told the Oak to update as part of SoftAP, the Oak fell over partway in, so when SoftAP prompted you to retry, it switched the Oak over to the fallback server, and since that hasn't been updated / has the older firmware, it gave you v1.0.0.

The only other info I can give you that may help in debugging is the particle api url, which you can view to see what particle reports about your device. It looks like this:

https://api.spark.io/v1/devices/DEVICE-ID/?access_token=ACCESS-TOKEN

Where you substitute your device id and access token (you can find both on Particle Build if you need them) and shove that into the address bar of your browser. You should then get an exciting white page with the following exhilarating output.

Code: [Select]

{
  "id": "DEVICE-ID",
  "name": "Oak1",
  "last_app": null,
  "last_ip_address": "58.XY.45.XYZ",
  "last_heard": "2016-08-16T07:05:04.841Z",
  "product_id": 82,
  "connected": true,
  "platform_id": 82,
  "cellular": false,
  "status": "normal",
  "variables": {},
  "functions": []
}
Don't know if that will really gives you anything more than what OakTerm does... but more info is good, right?   

[exeng]

Pete, Thanks.  I'll try these next round. So far on points  I'm getting beat. Looking for the knockout punch.
Cheers.

[PeterF]

Nah, you'll win one way on the other... either you'll beat it at it's own game or just introduce the Oak to 120v AC to brighten it's day

[exeng]

Pete, kh, et al,

OK... So this morning I just tried the Particle API as suggested. For the new Oak and the failing Oak, when each powered on they appear to be connected to Pariticle as the blue dot is on the dashboard and flashing.  The API devices request looks mostly normal for both expect Pacticle reports connected true for the new Oak and connected false for the failing Oak. I assume Particle won't flash if it doesn't think an Oak is connected. Also last_heard report is consistent with what I would expect for both Oaks.

Failing Oak...

...
 "last_heard": "2016-08-16T15:33:53.371Z",
  "product_id": 82,
  "connected": false,
  "platform_id": 82,
  "cellular": false,
  "status": "normal",
  "variables": null,
  "functions": null

New (working) Oak...

  ...
  "last_heard": "2016-08-16T15:54:21.678Z",
  "product_id": 82,
  "connected": true,
  "platform_id": 82,
  "cellular": false,
  "status": "normal",
  "variables": {},
  "functions": []

So why ? the flasing blue dot on Particle for the failing Oak when it's powered up and Particle doesn't think it's connected? When powered down Particle's dot stops flashing (albeit with a delay). And yes, I check  the failing Oak when powered down and it's reported as connected false. Also checked the Oak "IT'S-LOCAL-IP"/particle and got back "Connected" from the system.
BTW Oak Terminal (which I believe gets this info) also shows the failing Oak "offline".

Haven't tried the fallback image yet. Time for morning coffee.

[exeng]

Latest update...

Loaded the Oak fallback image that Pete provide, which shows as system_version 6, version_string 1.0.0 as does the new working Oak. Verified by the following:

Failing Oak reports
http://192.168.1.70/version {"v":1}
http://192.168.1.70/info {"id":"d9Removed for public consumption","claimed":1,"claim_code":"","server_address_type":1,"server_address_domain":"device.spark.io","system_version":6,"version_string":"1.0.0","meta_id":0,"meta_data":"","first_update_domain":"oakota.digistump.com","first_update_url":"/firmware/firmware_v1.bin","first_update_fingerprint":"98 66 d5 5c 3d 4a 49 24 e3 1b 72 8b 8f 2e 65 2e 32 2a 7b 95"}
http://192.168.1.70/particle Connected

Cannot claim the device nor OTA upload. It was previously claimed and present (even after the load of the fallback image) but couldn't OTA upload. Unclaimed it, cycled power, can't claim it (which has been an ongoing behavior. Claims only when SoftAP update works.
Makes you wonder what is real difference between to new working Oak and the failing Oak under test/debug.

This whole claim thing is looking suspect with Particle... and I also don't understand when I do have it claimed and present on Particle why Particle API reports it's connect status as false. Wondering if something is out of sync with Particle's view of this device.

I'm going to go through the normal factory restore / SoftAP update once again to get it back to it's (other) failing config. The one I have been trying to resolve for days. I've poked it from every which way to no avail. Double Arrrrgh!

[kh]

I got a response from the Particle developers yesterday to say they think your debugging info may help to narrow down the issue, exeng. I suggested they get in touch with you to get your device ID to compare with their logs, or perhaps a full image of your Oak (that way, if you unclaimed yours, they could effectively make a clone for in-house testing - I'll write up some instructions on making a full image if they're interested in doing this).

[exeng]

Thanks. Also sent an appeal to Erik as did you. Offered the device id and/or the physical Oak. At this point I've done all I can do.

Would like to know from Particle why their flashing online indicator on the device screens does not match what is returned from Cloud API connect status for this Oak. Posted a ? on Particle Community but so far only readers and no answers. https://community.particle.io/t/dashboard-build-device-status-question/25179

Thanks for all the help. If nothing else, I learned a lot during this exercise. But I still want to nail this.

(oh... and Thanks to Pete also).

exeng

[exeng]

Yet another update...

Checking Particle Cloud API again after OTA failing Oak powered up and...

    "connected": true,

So naturally I was excited to try an OTA sketch upload. Result fail. Same error as before with my additional debug output showing err (null) and data objects.

OakCLI tool version 1.0.2
Using config file at: C:\Users\Stephen\AppData\Roaming\oak\config.json
Sending file to cloud, to flash OAK_GD (Device ID: d9Removed for public consumption)
Get ready to flash C:\Users\Stephen\AppData\Local\Temp\build2369503282518711042.tmpBlinkTestPgm.cpp.bin
null
{ ok: false,
  code: 200,
  errors:
   [ { id: 'd9Removed for public consumption',
       status: 'Update failed - File was too big!' } ] }

Error : An error occurred while flashing the device:

[saperlot]

I have same the problems since a few days.

So i did a restore over serial (took the latest firmware_v1.bin form 09-Jul-2016 13:40).
Now i see the device is up on particle.
When i try to flash the simple blink example it starts to flash (oak blinks).
After a few seconds i see the OAK stops blinking, but the IDE still shows Flashing.
Oak is going back to "fresh install" blinking and shows on particle "No user rom found".
Then the IDE tells me "Error : Oak is back online before flash sucessfull."

The Oak clearly gets restarting within the flashing process. I can not get any new FW on it.

OakCli: 1.0.2
OakArduino package: 1.0.5

[exeng]

saperlot, I think what you are seeing is different than the problem I'm having. I've seen the error you posted few times over the course of using my Oak's (many months)...

"Error : Oak is back online before flash sucessfull."

and it's always been a transient problem. Never understood why but usually resolved itself upon a retry. Can't say that I've seen the other part you mention...

...shows on particle "No user rom found".

since it would go away on retry.

Is it repeatable? Have you tried all the usual stuff... Safe mode before trying to upload a sketch, or doing a factory restore and normal OTA firmware update rather than serial update?

The problem I have been chasing is that I have an Oak the refuses to OTA upload a sketch. I've got the latest system SW on it and using 1.0.5 and CLI 1.0.2. I'll spare the details as they are well documented in this thread. The big guns may be getting involved in trying understand what is going on. Hopefully we'll get to the bottom of this.