Error Occurred while Flashing Device with Digistump Oak

Thanks phord for the insight. I only have in AP for wi-fi where the Oak is. The problem isn’t the wifi connection, as I can go on Particle, and on the dash it shows my Oak as connected. When uploading a sketch from the Ardhuino IDE, I get confirmation that the sketch was uploaded, the error comes when it tries to flash the Oak.

I don’t know if my problem is related or not, so please feel free to break this off into another thread if it isn’t related.

I also have several Digistump Oaks, and two that I have been programming recently are having issues with establishing the link to Particle. When I look at the particle dashboard after programming they, they keep cycling between offline and online for several minutes, and then trigger a spark/status/safe-mode event, at which point the user program starts running properly.

However, if I do a simple blink sketch, and do a SYSTEM_MODE(SEMI_AUTOMATIC) at the top, I don’t have any issues at all. I did try adding a Particle.connect then, and as soon as that line was processed, the offline/online cycle started again. This is on two devices, and is repeatable without fail after several power cycles. However, three other Oaks on the same network which haven’t been modified in a few weeks are still connecting to the cloud fine.

Any ideas or suggestions would be appreciated.

[18:23:35] Event: spark/flash/status - failed (normal for Oak - it was successful)
[18:23:41] Event: spark/status - online
[18:23:51] Event: spark/status - offline
[18:23:52] Event: spark/status - online
[18:24:02] Event: spark/status - offline
[18:24:04] Event: spark/status - online
[18:24:15] Event: spark/status - offline
[18:24:17] Event: spark/status - online
[18:24:27] Event: spark/status - offline
[18:24:28] Event: spark/status - online
[18:24:38] Event: spark/status - offline
[18:24:39] Event: spark/status - online
[18:24:49] Event: spark/status - offline
[18:24:50] Event: spark/status - online
[18:25:00] Event: spark/status - offline
[18:25:02] Event: spark/status - online
[18:25:12] Event: spark/status - offline
[18:25:14] Event: spark/status - online
[18:25:22] Event: spark/status - offline
[18:25:24] Event: spark/status - online
[18:25:34] Event: spark/status - offline
[18:25:35] Event: spark/status - online
[18:25:45] Event: spark/status - offline
[18:25:46] Event: spark/status - online
[18:25:54] Event: spark/status - offline
[18:25:56] Event: spark/status - online
[18:26:05] Event: spark/status - offline
[18:26:07] Event: spark/status - online
[18:26:16] Event: spark/status - offline
[18:26:18] Event: spark/status - online
[18:26:28] Event: spark/status - offline
[18:26:29] Event: spark/status - online
[18:26:38] Event: spark/status - offline
[18:26:41] Event: spark/status - online
[18:26:51] Event: spark/status - offline
[18:26:52] Event: spark/status - online
[18:27:02] Event: spark/status - offline
[18:27:03] Event: spark/status - online
[18:27:12] Event: spark/status - offline
[18:27:14] Event: spark/status - online
[18:27:26] Event: spark/status - offline
[18:27:27] Event: spark/status - online
[18:27:32] Event: spark/status/safe-mode - {"f":[],"v":{},"p":82,"m":[{"s":1040368,"l":"m","vc":30,"vv":30,"f":"s","n":"1","v":6,"d":[]},{"s":1040368,"l":"m","vc":30,"vv":30,"u":"0","f":"u","n":"1","v":1,"d":[{"f":"s","n":"1","v":9,"_":""}]}]}

Sounds like the symptoms I saw, too. My “failing” oak shows that it is online, but when I try to flash to it it fails. Sometimes it fails before flashing; sometimes it fails while waiting for the reboot. It seems more reliable on short sketches (blink) than my longer sketch, even though it’s not much longer.

I seem to have this trouble when I produce too much Particle activity. I have code in my loop like this:

if (Particle.available()) Particle.println("Got data");

If I don’t read the data waiting in the queue, then my device begins sending several lines of text to Particle.io. After four lines, the connection drops and I go into the offline/online cycle. Sometimes it seems to “wake up” and I receive some spurious data from the device, as if it has been running ok all along but just failing to talk to Particle.

If I ever manage to get “Blynk” on the device, it seems to recover just fine. But code that seems to “abuse” Particle causes this kind of problem for me. :frowning:

Where did you get that from, since I haven't seen that before... If you're talking about Particle publish, then yes, there's a 1p/s limit on those.

1 Like

Excuse my ignorance, but is this some DigiStump dialect?

if (Particle.available()) Particle.println("Got data");

Both these functions are unknown in the Particle implementation of Wiring.

Yes, it’s a digistump Oak extension: https://github.com/kh90909/OakTerm

It's probably akin to publish(), though I haven't looked at the internals.

Is the 1p/sec limitation mentioned in the docs? I can only find references to this limitation in the forums.

What happens if this limit is exceeded? Does the device just ignore faster requests or does the server enforce the limit somehow?

Yes it is mentioned here
https://docs.particle.io/reference/firmware/photon/#particle-publish-

The expected behaviour is that subsequent publishes just get dumped but still count for the limit counter, requiring you to actively keep radio silence for 4sec.
But due to an open issue your device will be thrown off the cloud after about 30~60sec if you don't at least wait 1010ms between consecutive publishes

See here
https://github.com/spark/firmware/issues/1023

Thanks for the details. This could be what's causing grief for Oak users (this thread). I'm sure it's what was causing most of my own issues.

Looking into the OakCore code, I see published events are limited to 4 per second, and events which exceed that are discarded. But there is no rate limiting of the next events sent outside of that window during the next second. The language in the Particle docs is somewhat vague on this, but it sounds like OakCore needs to allow for a 4-second "recovery" period for each batch of 4 events instead of just 1-second.

It’s kinda like you can, on average, send one event per second. If you go over that, you’ll be cut off and need to recover until you’re under the average again. Burst of up to four per second are allowed, with the caveat that it’ll obviously take longer to get back under the average again.

Did I mention the language is somewhat vague? “Kinda like … on average …” is a good analog of it. “need to recover” isn’t much help, either. “You’ll be cut off” is the part that’s not discernible from the docs.

I found another location in the code where println()'s are limited to 1 per 1000ms, so maybe this isn’t exactly violating the docs, but it appears to be running into the same issue that ScruffR mentioned.

To make it clearer:
1 per second.
4 per second allowed in bursts.
Average <= 1 per second.

The exact implementation may be a bit vague, but the gist of it is that you’ll be cut off it you exceed the limits, which are, in my opinion, quite clear. It will then wait for you to get back under the average again. That shouldn’t take longer than 4 seconds, since you’ll be cut off after the burst of 4.
That said, if you’ve got a better way to explain it, then by all means, please do share. Better yet, edit the docs directly :wink:

Hey, way cool and all but, can we stay on topic. My Oak still doesn’t work correctly as it had before. Does anyone have anything to add to help my case in which my Oak was working fine, even publishing events, but now shows connected, but no events being published,and I can program?

You have to remember also that println is Oak specific, although I do believe Particle is there in the back end. So the Particle.publish() limits may or may not apply - I suspect they would though.

As far as vagueness of the documentation, it is and it isn’t! :smiley: Basically, you should post one event per second. You are permitted to send more events back to back(up to a maximum of 4), but that is stealing from the future, which is frowned upon, and thus must cool your heels! :open_mouth: So if you post two events back to back, you must wait for two seconds before posting the next if you want it to be accepted. Post three, wait for three. Post four, wait for four. Post five, fifth messages is lost, and you have to wait for four seconds still.

Recent gremlins mentioned on the forum seem to have been resolved (for a couple of people, anyway) with a update to the firmware (now 1.0.5), which tells Particle that it doesn’t need a system update, and lets things carry on normally.

Hey @bjrohan, have you had a chance to see if 1.0.5 will fix your problem (you’ll need to update the board package via the Arduino Board Manager if you haven’t already)? To see if it fixes the problem, basically what you need to do is power on the Oak (you can boot it in config mode if you wish, but it probably doesn’t matter), and then leave it online for 10/15 minutes (or until you see a “spark/status/safe-mode” event in OakTerm/Particle Dashboard Logs) and then try flashing it again.

2 Likes

Thank you for the info. I believe I will have a problem in doing so because I can’t flash my Oak. I show that it is connected in the dashboard.particle.io, however when going to the events page nothing reports.

Again, when trying to Flash via arduino, the program uploads to Particle, then I get an error message on the failure to flash.

Every single day since this has occurred, I have unplugged my Oak, let it sit powered off for several minutes and reboot just to see if there are any changes, of which there are none.

On your recommendation, I loaded the Arduino IDE, went to Tools, Board, Boards Manager, searched of Oak, in that section, chose version 1.0.5, and waited for the download to complete. I then put my Oak into config mode and went through the process as if it was a new Oak, including connecting to the Oak wifi, setting the wifi and password, after which it connected to Particle (that’s what the browser window said)

After waiting approx 15 minutes, I logged into my particle dashboard, which showed my Oak connected, but again, no events. I logged into Oakterm, same as before, it showed as offline, however the last_heard timer was up to date, and updating. What did change is I went to my digistump dashboard for the program I have, and it was updating (particle.publish) which lists the output of my photocell. It wasn’t doing this before this update.

I tried to flash the basic LED tutorial, and this time I received an error message that my Oak wasn’t registered or something like it). I ran the Oak tool, selected my Oak, and restarted the IDE. I again tried to flash the LED program, and again received the error message an error occured while flashing device right after it showed the program was uploaded.

Any other suggestions?

@bjrohan, You are not alone. I too am seeing OTA upload error on one of my Oaks that may be the same thing you are seeing. This all started when I noticed this OAK was not publishing events to Particle. So I updated to version 1.0.5 and now cannot do OTA updates to this Oak even though it is claimed on Particle. The message is the same as your first post “Error : An error occurred while flashing the device:”. Interestingly I brought up a fresh out of the bag Oak today with no problems. Still trying to figure out what the issue is with the Oak that won’t OTA upload.

There is a thread on the Digistump forums here discussing the ongoing saga.
http://digistump.com/board/index.php?topic=2373.msg11226;topicseen#msg11226 (latest post by me).

I’ve created a custom CLI with debug to try and glean what the error may be. Here is what it reports…

“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!’ } ] }”

I think the error is being reported by a callback from the Particle side.

Like you, I am very anxious to have this understood and resolved.

Just so we are clear what follows the debug detailing the error in my previous post is…
“Error : An error occurred while flashing the device:”

190+ days and I don’t see any replies, is this fixed?

Wow that was back in August 2016. Yes for me the problem was solved by rewriting some sectors on the Oak with balnk bin files using this command…
python esptool.py --baud 115200 --port YOUR_COM_PORT write_flash -fs 32m 0x3FC000 blank.bin 0x3FD000 blank.bin
0x3FE000 blank.bin 0x3FF000 blank.bin

The last sector in the list did not complete but this fixed worked never the less. It was suggested by the creator of the Oak at Digistump.