Breathing Cyan, but won't flash from /build (also periodic cyan flashing and rapid flashing)

Opening a new thread (sorry for the earlier hijack - thought if it was related it might help diagnose a wider-reaching issue).

I only have a single Core. It iseems to be connected and breathing Cyan. It’s publishing events and I’m able to read them from the cloud, and /build is showing the status as online. I have also observed that I repeatedly get a flashing cyan, then a rapid flashing cyan, then back to breathing cyan. I’ve timed several of these events, and it seems to happen like clockwork - breathing for one minute, then flashing, then rapid flashing (all cyan).

Anyhow, just updated my code to slightly modify the data I’m publishing for the event, but when trying to Flash (either my own modified program, or the Blinking LED demo) it doesn’t go magenta, and eventually results in a “Request Timeout, Flash Unsuccessful”

I’ve been able to do other things from Build, like Rename the core (verified by doing a /devices API call.

I’ll try putting it on a different wifi network to try my luck, but does anyone have any advice?

It’s possible that whatever code you have on your core is restricting/limiting the core’s ability to maintain a connection to the cloud. We see this fairly often when users do a lot of TCP operations or have numerous delays or other blocking operations. My suggestion is to always have either a brief period in the beginning of your program where you do nothing but connect to the cloud and wait for say 10 seconds or have it coded such that a certain pin can be brought low or high in start-up to trigger the “wait for new firmware” function.

You could also post your code and we could take a look at it to see if any optimizations could help.

That sounds a lot like the code I’m running :slight_smile: I was really just trying to get something up and running so I could go from there.

I’d like to be able to “remotely manage” the core, so rather than a pin brought low or delay upon startup would it make sense to have a (cloud api) function on the core that sets some kind of semaphore for the main loop and then delays?

And then lastly, if the conclusion is that it’s the code causing the issue, I suppose I’d need to use USB to flash it to get out of that mess?

#include "DS18B20.h"
#include "OneWire.h"

DS18B20 ds18b20 = DS18B20(D2);
char szInfo[64];
void setup() {
void loop() {
    if(! {
        Serial1.println("No more addresses.");
    float celsius = ds18b20.getTemperature();
    sprintf(szInfo, "Temperature: %2.2f Celsius, (Chip Name: %s)", celsius, ds18b20.getChipName());
    Spark.publish("tmpinfo", szInfo);

I’ve edited your post to properly format the code. Please check out this post, so you know how to do this yourself in the future. Thanks in advance! ~Jordy

You can use USB or you can just do a factory reset. Might be faster to the factory reset but, going forward, it would be useful to have a local development setup so you can flash over USB when you run into this issue again.

I would replace your delay() with a millis()-based delay so your code spends as much time outside of loop() as possible. See (I haven’t tested it but that should work)

1 Like

<<< going forward, it would be useful to have a local development setup so you can flash over USB when you run into this issue again. >>>

What do you mean by a local development setup? I’ve tried to get the Spark-CLI to work on my Mac, but ran into problems and went back to trying to use the online BUILD.

I mean flashing via the DFU utility. You compile the code locally and flash the code locally bypassing the cloud completely. Do a forum search for “DFU insert operating system here” and you should find several good tutorials. If you run into trouble post back and I’ll help you out

By “DFU” do you mean “Spark Dev”, ? Or is that yet another development tool? It’s another, awesome, development tool which lets you flash code when it isn’t connected to the cloud