Error : An error occurred while flashing the device:

[exeng]

Some additional info to add to the puzzle:

Same Oak is still failing so I decided to bring up my (straight of the package) only virgin Oak. Let's call it OAK_SPARE.

Using the 1.0.5 repro and OakCLI 1.0.2 (latest with my debug output)
1. Did a factory restore on OAK_SPARE.
2. Did SoftAp update on OAK_SPARE.
3. Did a OTA upload of a simple blink test program to OAK_SPARE.
It flashed and ran as expected. All OK... OAK_SPARE working.

Then tried the same on the failing OAK. Let's call it OAK_FAIL.
Using the 1.0.5 repro and OakCLI 1.0.2 (latest with my debug output
1. Did a factory restore on OAK_FAIL.
2. Did SoftAp update on OAK_FAIL.
3. Did a OTA upload of a simple blink test program to OAK_FAIL.
OTA upload fails with the same debug output reported on previous fails...

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\build8316527855105053068.tmpBlinkTestPgm.cpp.bin
null
{ ok: false,
  code: 200,
  errors:
   [ { id: 'd9d9Removed for public consumption',
       status: 'Update failed - File was too big!' } ] }

So as reported err = null, data reports file was too big!

So why the difference? BTW, both are claimed and seen on Particle. The only thing that is different (I think) is OAK_FAIL had been previously in service (at repo 1.0.0) and posting events to Particle before all this started. At some point OAK_FAIL events were no longer seen on Particle. For that and other reasons I decided to update OAK_FAIL which now cannot be OTA uploaded.

[PeterF]

If you want to give something else a try, as it's seeming even more likely it's on the Particle end, try unclaiming your Oak (go to Particle Console, and click the "..." next to the offending Oak and unclaim), and run it through the OakRestore / SoftAP update process again to make it claim again. Maybe that will get something unstuck.

If it doesn't want to automatically claim, you can do a manual claim as noted in the wiki.

Hopefully this will knock it on the head, as you seem to have eliminated just about everything on your end!

[exeng]

Pete, Been down that path already with no luck (See the earlier posts).

I have factory restored and firmware updated multiple times trying to make it go away. Then resorted to trying to get more info with the help of kh.

On the good side, we have a repeatable failing Oak. Would really like to know what Particle is seeing during the OTA exchange and how they are handling it. I can try it again (really... one more time?) but I'm feeling like there is something about this Oak that Particle doesn't like. If I were a conspiracy theorist, I'd wonder if Particle is denying my Oak from participating.

[exeng]

Pete, Just for you and only you, I did it one more time making sure to un-claim the Oak first.... and no cigar. Same result on OTA sketch upload attempt. Same error message.

[exeng]

kh, Pete, et al
 
BTW posted on Particle Community:
https://community.particle.io/t/error-occurred-while-flashing-device-with-digistump-oak/24060/23?u=exeng

[PeterF]

Pete, Just for you and only you, I did it one more time making sure to un-claim the Oak first.... and no cigar. Same result on OTA sketch upload attempt. Same error message.

Aw... thank you! Ok, I'll go with the conspiracy theory... the Particle gatekeeper is obviously saying 'This Oak Shalt Not Pass'

For giggles, if you want, we can trade device IDs of your problem Oak (via PM) and my usual test subject, and see if we can flash each others Oaks (that just sounds wrong!)... and then swap back after trading notes. Should be as easy as an unclaim to free up, and a manual claim to attach to another Oak. No reflashing required

[exeng]

I was actually thinking about doing that and using an id from one of my working Oaks but didn't know if that would cause a problem or worst rendering two Oaks down.

Let me think about it.

[exeng]

Pete, tried to use one of my id's from another oak. Unclaimed both. Follow the wiki for setting the device id but it didn't change. Could be I'm doing something wrong. It would be a great experiment if I could get it to stick. In any case did yet another restore / SofAP update. Verified that the original id was there and claimed on Particle. Still no OTA upload success.

[kh]

For giggles, if you want, we can trade device IDs of your problem Oak (via PM) and my usual test subject, and see if we can flash each others Oaks (that just sounds wrong!)... and then swap back after trading notes.

You can effectively do the same thing yourself by creating a second Particle account, then unclaiming from the original account and claiming on the second. I tried this when debugging this issue on my Oak in June. The Oak continued to behave the same way on the new account. But it would always be interesting to see whether this is repeatable or not, since this problem is so intermittent and rare.

[exeng]

kh, Thanks. Will give that a try when Pete let's go of my device-id (an experiment in progress).

[PeterF]

Well, it seems exeng can upload code from his end to my test subject without any drama. However I can't claim his Oak (yes, it was unclaimed!!  ). Think we're getting nearer to the heart of the problem though... maybe... possibly?? 

btw, I'm trying to get a IRC channel up for any Oak related discussion... hopefully this works

---
Join us on IRC chat on Freenode (chat.freenode.net) in your preferred IRC client or via the web client at ##DigistumpOak.

[exeng]

kh, Also fails on second account. Another tidbit to log in the mystery of why. At this point, I'm torn between donating the Oak to Erik for debug and continuing to work on figuring out the problem.

I think, it will require getting Particle involved somehow to see what is going on an their end.

[kh]

kh, Also fails on second account.

Yes, I expected it would. Good to know at least that is repeatable...one less permutation to worry about!

I think, it will require getting Particle involved somehow to see what is going on an their end.

I've sent a message to Erik asking him to take a look at the OakCore code where the Oak communicates its maximum firmware size to the cloud. I've also asked the Particle developers who were helping me to debug my instance of this issue to take a look at the Particle Cloud code that parses this communication on their side. Exeng, I sent them a link to your thread and mentioned that I'm sure you'd be happy to provide your device id so that they could look it up in their logs, so they might contact you about that.

I'll post here if I get any responses.

[exeng]

kh, Thanks. Happy to help get to the bottom of this.

[exeng]

Update but on a side issue for a complete picture...

There is something very strange going with this Oak. It seems to have difficulty with the claim process. After trying to go through the restore/SoftAP update it does not auto claim and manual claim fails (Pete, perhaps why you couldn't claim it). It seems to only claim when completed during SoftAP process.
http://192.168.1.70/particle = Connected
http://192.168.1.70/device-id = {"id":"d9Removed for public consumption","c":1} Note the "c":1 (Claimed)
And yet it is not claimed nor can it be claimed according to Particle.

Again, let's just log this and say focused on the OTA fail. Only mention it in case there is some connection to the OTA issue. I'm trying to get it back to claimed (which I have been able to do during this debug effort) so that we can debug the repeatable OTA fail.