Error Occurred while Flashing Device with Digistump Oak

I was running a program on my Digistump Oak just fine, which was successfully publishing to Particle just fine as well, which a dashboard I have was receiving data just hunky dorey.

I noticed something was awry when I attempted to upload a new version of the program, when I received the following:

Using config file at: /home/bjrohan/.oak/config.json
Sending file to cloud, to flash Brian_Oak (Device ID: xxxxxxxxxxxxxxxxxxxx)

Error : An error occurred while flashing the device:

Upon checking my Particle account, it shows that my device shows connected when powered, and when I disconnect oak power, my Particle account responds accordingly, showing disconnected.

I tried uploading a very basic Pin 1 flash program and received the same error message.

My original program is still on my Oak, and functioning as far as I can tell as expected, however it’s not publishing any Particle logs as it was before.

I also restarted the Arduino IDE, same issue. I also restarted my computer, with no change in error message.

Any ideas what is going awry, and how to correct it?

FWIW my son has another Oak, connected to the same wi-fi network, and he can flash new programs and publish to Particle just fine.

Thank you for the input.

Anyone? This is still an issue for me. I thought perhaps after a few days / reboots it may magically go away :-/

Is there anyone from particle here that can help?

The problem is that it’s weekend and Independence Day tomorrow - so you might need to be patient :wink:

1 Like

I’m having the same trouble here. I’ve recovered from it a couple of times, but it’s back now. Maybe it’s an intermittent problem on the particle.io side.

My problem seems to be with my local wifi connection. We have two APs here, and I was connected to one further away on this device. When I switched back to the closer AP, the device is working again.

Maybe you have a signal interference problem on one device. Try repositioning it and/or disconnecting peripheral connections.

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

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?