Argon stops responding to pings or flash requests

Troubleshooting
1

Link to my code.

My sketch works as expected, but now my device no longer responds to ping or flash attempts.

To the best of my recollection, on the last edit I made I took out all instances of delay(). I’m wondering if that somehow prevents the device from having any available cycles in which to handle incoming requests?

In the particle console, I still get regular spark/device/diagnostics/update events. Here’s one of the most recent ones:

{
  "device": {
    "system": {
      "uptime": 1280,
      "memory": {
        "total": 171480,
        "used": 88112
      }
    },
    "cloud": {
      "connection": {
        "status": 1,
        "error": 0,
        "attempts": 1,
        "disconnect": 1
      },
      "disconnects": 5,
      "publish": {
        "rate_limited": 0
      },
      "coap": {
        "unack": 13
      }
    }
  },
  "service": {
    "device": {
      "status": "ok"
    },
    "coap": {
      "round_trip": 44
    },
    "cloud": {
      "uptime": 0,
      "publish": {
        "sent": 0
      }
    }
  }
}

Any ideas what I’m doing wrong? Thanks!

2

The first thing I’d change is to get rid of that delay(5000) and break that while() loop in your colorFade() function as it doesn’t allow for the cloud task to run.

While you can work around that by using SYSTEM_THREAD(ENABLED) and/or adding Particle.process() inside that while() {...} it’s always better to adopt non-blocking coding scheme.

2 Likes
3

@ScruffR, Thanks for the feedback! I’m still relatively new to Particle programming (and microprocessors in general) and I haven’t fully wrapped my brain around the mindset. In trying out various bits of code to run a light show, I seem to keep causing buffer overruns or other things that make the device inaccessible. I’m getting pretty good at re-flashing the firmware. :sunglasses:

The delay(5000) was/is just for debugging purposes and actually was not in the code that was blocking (I added it later after I was no longer able to flash the device).

That being said, the Particle.process() docs indicate that Particle.process() is actually run automatically during calls to delay() and at the end of every loop(), so having it in there might have kept my device from becoming inaccessible.

It sounds like that may be a suboptimal way to solve the problem. It should be a fun challenge to figure out some non-blocking approaches to writing the colorFade() function.

Thank you very much!!!

4

That is true, but with delay() you need to consider that it will only be called once every accumulate 1000ms of delay time, which will reduce responsiveness of your device by a factor of ~1000 (given an avg. loop() period of 1ms for WiFi devices when loop() is kept streamlined).

And that streamlining (or lack thereof) is also relevant for the second part of that quote. If your loop() diddles about a lot and doesn't quickly exit again, responsiveness will degrade too.

2 Likes