Boron almost never connects except to publish power-on/reset events

Particle Boron running Device OS: 0.8.0-rc.27
Other hardware: Featherwing tripler, Ultimate GPS Breakout v3, LIS3DH via I2C

Running code: assettrackerexample.ino (I made sure it was compiled for the same OS target as I am running)

My issue is that despite breathing cyan, my Boron seems to rarely actually be reachable through the cloud. It is never pingable and only a few times has it published GPS data to signal’s website. Running a diagnostic in the web IDE fails. Setting the device to “signal” mode does not cause it to rainbow flash either.

I am in an area with good AT&T GSM reception. I have confirmed with AT&T Business that LTE IOT support is active in my area.

Nothing is emitted to the USB serial console so I’m not sure how to proceed with further troubleshooting. At this point the only way to get new code on is via the console by putting it into serial listen mode.

Update:
The usb serial console eventually shows “…” so I am guessing there is some code running and perhaps outputting a ‘.’ each time it tries to connect?

Try adding SYSTEM_THREAD(ENABLED) and see if this changes anything.
If it does, your code is somehow blocking which may cause that behaviour and should be located and resolved.

Have you tried Safe Mode?

I added your suggestion right after my library imports and uploaded it via ‘particle flash’. Now I get green blink -> cyan breathe -> red sos -> reboot. The code I am running has worked before without crashing but I’ll try flashing a very simple example and see if that works.

I uploaded "blink an LED’ and that does the same thing; still crashing.

I’ll try safe mode.

It won’t go into safe mode. Holding down MODE eventually goes to blinking blue (listen mode?). Doesn’t matter how long I hold MODE.

Safe Mode is entered by holding down MODE then tapping RESET while still holding MODE and then let go of MODE as soon you see magenta.

If you post a SHARE THIS REVISION link from Web IDE we may be able to test what’s wrong.

When that happens we also need to know the number of red blinks after the SOS

I can’t get it to safe mode.When it goes magenta, releasing MODE puts me back in blue flashing mode. I can apparently use ‘particle flash’ in this mode, but it won’t return it to normal breathing cyan.

“share this revision” is not working for me here in Safari. However, it is just the “Blink and LED” project found in the library.

Ah it is possible it went to Factory Reset. I’ll re-add it via my phone.

Yep. I was able to re-activate it.

However it is still not pingable and fails the diagnostic in the console.

Messing with it more, it occasionally will do a RED SOS blink once (I haven’t yet been able to count the flashes accurately) but then it will go on to cyan breathing for a bit before going back to green blinking.

It’s pretty useless if I can’t even run the ‘blink’ program…

I put it in DFU mode (flashing yellow) and ran ‘particle flash --usb tinker’. This has made it pingable and once again able to upload code. Why though???

Frustrating!

Probably your code - that’s why I said 10 days ago

and asked for

What did we get?

In deed!

1 Like

I thought the code may have ben an issue, that’s why I uploaded the “Blink an LED” example from the library to the Boron. I didn’t think you needed or wanted me to share that, as I took it straight from the git and did not modify it.

I’m over my 5 MB limit, so can’t do anything more until later this month.

Blink an LED is foremost meant to be a simple demo to show the device works, it’s not taking care to keep the device responsive to cloud requests AND it doesn’t publish anything to the cloud.
Hence it’s not a good test case for anything cloud related.
Also when your device still crashes, how can you be sure it’s actually running that firmware. Or do you see the blink pattern? (you didn’t say)

BTW, if you have hit the data limit you can up your hard limit via console.particle.io/sims
And to save data you can flash new firmware via USB.

What demo code would you suggest as being good for troubleshooting cloud issues? I’ve also got a Segger J-Link Mini somewhere, and could get the whole build/debug environment set up, but that’ll have to wait until I have more free time.

Thanks for pointing out the data cap unlock. I’ve bumped myself up and will try to flash via USB when possible.

You could use a slightly altered Blink an LED

int led1 = D0; // Instead of writing D0 over and over again, we'll write led1
int led2 = D7; // Instead of writing D7 over and over again, we'll write led2
void setup() {
  pinMode(led1, OUTPUT);
  pinMode(led2, OUTPUT);
  Particle.function("toggle", toggleLED);
}

void loop() {
  static uint32_t msLast = 0;

  if (millis() - msLast < 1000) return;
  msLast = millis();
  digitalWrite(led1, !digitalRead(led1));  // toggle LED 1
}

int toggleLED(const char* dmy) {
  int state = !digitalRead(led2);
  digitalWrite(led2, state); 
  return state;
}

This code should attend to the cloud as often as possible and hence be much more responsive to cloud requests than the original Blink an LED.

But for some more elaborate cloud debugging you can use this repo

1 Like