Electron will only connect when in Safe Mode

Troubleshooting
1

Hey folks,

Looking for a little help here. I have a new electron board that can only seem to get connected when in Safe Mode.

I’m using a Particle SIM. When the SIM isn’t plugged in, and I have it plugged in to my computer via USB is responsive via the CLI. Everything seems to be working fine.

When the SIM is plugged in, it will boot up and start breathing green and never connect. CLI commands don’t seem that responsive while it’s blinking green. Very often it will just Request Timeout.

If I put it into Safe Mode it will pretty much immediately connect every time.

I updated it to DeviceOS 1.2.1. That went off without a hitch. Still no network without Safe Mode.

I tried using Device Doctor on it, and it worked for a very short while. I can see the events come in to the console. But then, after just a few seconds, it loses connection again and just goes back to blinking green. I tried that a few times and it was pretty consistent.

I put it in Safe Mode and OTA flashed the application firmware using a couple of the starter apps from build.particle.io. Again, the OTA seemed to work (while it was in Safe Mode), but then after just a few seconds after it restarted, it lost connection again and just went back to blinking green.

if I hit the reset button, every once in a while it will be able to get on for a few seconds, I’ll get an event or two on the console, and then it will start hunting again. Most times it just comes up and starts hunting for network.

I feel like I’m missing something, but is it possible I got a bad board? is there any way to troubleshoot that?

2

This sounds like your code on the device is either blocking or disconnecting from the cloud (or never connecting due to a non-AUTOMATIC SYSTEM_MODE).

Usually when the code would attempt to connect to the cellular network without a SIM it would immediately enter Listening Mode (blinking blue) - what CLI commands have you been trying?

3

Thanks for your help ScruffR,

I figured it might have to do with the app firmware, but I’ve flashed it with a few different apps, two of them from the example apps on build.particle.io. It had the same behavior, so I don’t think it’s the app firmware causing the issue. The one time I flashed it with the example app to turn on the LEDs for 1 second then turn them off, it worked immediately after the OTA update for about 5 seconds, then went right back to looking for the network. I’ll try to flash it with an empty setup() and loop() and see what that does. I will try the Threaded mode too, just to see.

As far as CLI commands, they all work great when the SIM isn’t plugged in. But when the SIM is plugged in, I’ll get a “Request Timeout” 90% of the time (especially if it’s breathing green). I’m mostly using the basic commands:

  • particle identify
  • particle usb list
  • particle usb XXX (start_listening, stop_listening, etc)

The thing is, it’s really inconsistent. Which leads me to think it might be hardware related.

4

Can you post a particle serial inspect log?

5

Yessir, I can. I’ll do it first thing tomorrow morning. Well, I’ll do it after I do a bit of reading up on particle serial inspect and its output. I’m just about to head off to bed right now.

Thank you for the advice!

6

okay, this is a little weird. It’s long, so please bear with me.

particle serial inspect shows all greens.

C:\WINDOWS\system32>particle serial inspect
Platform: 10 - Electron
Modules
  Bootloader module #0 - version 311, main location, 16384 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 1213, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #3 - version 1213
  System module #2 - version 1213, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 1213
      Bootloader module #0 - version 311
  System module #3 - version 1213, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 110
  User module #1 - version 6, main location, 131072 bytes max size
    UUID: F346860E82F2351C28C103F1501C5A929866F52FA773B34391022F9B276C6EA3
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 1102

I was tinkering around with the app, so I built a quick little ino file.

//Global Variables Section
int boardLED = D7; 
int billsVariable = -999;

//Function Decs
int doSOS(String s);
int billsFnc(String s);
int dummyFnc(String s);
void dot();
void dash();

void setup() {
  Particle.function("doSOS", doSOS);
  Particle.function("billsFnc", billsFnc);
  Particle.function("dummyFnc", dummyFnc);
  pinMode(boardLED, OUTPUT);
}

void loop() {
}

int doSOS(String s) {
  dot();
  dot();
  dot();
  delay(500);
  dash();
  dash();
  dash();
  delay(500);
  dot();
  dot();
  dot();

  return 0;
}

int billsFnc(String command) {
  bool success;
  success = Particle.publish("test-event", "Hello Cloud", PRIVATE);
  if(!success) {
    billsVariable = -1;
  } 
  else 
  {
    billsVariable = 0;
  }
  return billsVariable;
}

//A dummy command
int dummyFnc(String command) {
  return 0;
}

//assume LED is off
//turn it on for 500ms, then back off, delay 500ms
void dot() {
  digitalWrite(boardLED, HIGH);
  delay(500);
  digitalWrite(boardLED, LOW);
  delay(500);
}

//assume LED is off
//on = 1000ms, off = 500 ms
void dash() {
  digitalWrite(boardLED, HIGH);
  delay(1000);
  digitalWrite(boardLED, LOW);
  delay(500);
}

this compiles fine. I flashed it both locally (I’m using VS Code and the new Workbench stuff) and OTA (while it was in Safe Mode) [Note: I’ve been through this series of events many times now, so am describing different runs].
I subscribed to all my events. I have only the single board. See bottom of this post for that data.

As soon as the flash began (blinking yellow), I started doing particle list every so often to see what surfaced. The first time I did it, it came back with this:

C:\WINDOWS\system32>particle list
test-board [30003e001147373239303438] (Product 6175) is online
  Functions:
    int Light_OnOff(String args)

This kind of threw me for a loop because I do not recall that function. I double checked that it wasn’t in any of the test apps I’d made yesterday in build.particle.io. It wasn’t.

As soon as the board finished flashing, it went cyan, so I quickly did the particle list again. In a couple seconds I got this, which was expected.

C:\WINDOWS\system32>particle list
test-board [30003e001147373239303438] (Product 6175) is online

I waited a couple more seconds and ran it again. also got what was expected.

C:\WINDOWS\system32>particle list
test-board [30003e001147373239303438] (Product 6175) is online
  Functions:
    int doSOS(String args)
    int billsFnc(String args)
    int dummyFnc(String args)

It breathed cyan for about 5 or 10 seconds, then went to flashing green. So, I tried the particle list again. I got this.

C:\WINDOWS\system32>particle list
test-board [30003e001147373239303438] (Product 6175) is online
  Functions:
    int Light_OnOff(String args)

WTAF?

I’m very new to this, so am not clear on what could be causing this. I got this card from a company we’re partnering up with. It came along with a board they made. Is it possible that they have claimed it and didn’t un-claim it and somehow have something set up to automatically OTA flash it?

Here is the output from my Event Monitoring. Note that these events are from a single flash on my part, which I did locally.

F:\Development\particle\bill_test>particle subscribe
Subscribing to all events from my personal stream (my devices only)
Listening to: /v1/devices/events
{"name":"spark/device/last_reset","data":"dfu_mode","ttl":60,"published_at":"2019-08-22T10:11:10.792Z","coreid":"30003e001147373239303438"}
{"name":"particle/device/updates/enabled","data":"true","ttl":60,"published_at":"2019-08-22T10:11:10.952Z","coreid":"30003e001147373239303438"}
{"name":"particle/device/updates/forced","data":"false","ttl":60,"published_at":"2019-08-22T10:11:11.092Z","coreid":"30003e001147373239303438"}
{"name":"spark/device/diagnostics/update","data":"{\"device\":{\"power\":{\"battery\":{\"charge\":{\"err\":-210},\"state\":\"disconnected\"},\"source\":\"USB host\"},\"system\":{\"uptime\":5,\"memory\":{\"total\":113664,\"used\":23656}},\"network\":{\"connection\":{\"status\":4,\"error\":0,\"disconnects\":0,\"attempts\":1,\"disconnect\":0},\"signal\":{\"rssi\":-99,\"strength\":22.91,\"quality\":26.53,\"qualityv\":-18,\"at\":4,\"strengthv\":-99},\"cellular\":{\"cell_global_identity\":{\"mobile_country_code\":310,\"mobile_network_code\":410,\"location_area_code\":51990,\"cell_id\":249824144},\"radio_access_technology\":\"3G\",\"operator\":\"AT&T Wireless Inc.\"}},\"cloud\":{\"connection\":{\"status\":1,\"error\":0,\"attempts\":1,\"disconnect\":0},\"disconnects\":0,\"publish\":{\"rate_limited\":0},\"coap\":{\"unack\":0}}},\"service\":{\"device\":{\"status\":\"ok\"},\"coap\":{\"round_trip\":1422},\"cloud\":{\"uptime\":1,\"publish\":{\"sent\":2}}}}","ttl":60,"published_at":"2019-08-22T10:11:11.797Z","coreid":"30003e001147373239303438"}
{"name":"spark/device/app-hash","data":"C0320559C8CB20DC8D2E99D0EDEB92950C62C2DE4DAC0331A5ABE341348087F1","ttl":60,"published_at":"2019-08-22T10:11:12.914Z","coreid":"30003e001147373239303438"}
{"name":"spark/status","data":"auto-update","ttl":60,"published_at":"2019-08-22T10:11:12.973Z","coreid":"30003e001147373239303438"}
{"name":"spark/flash/status","data":"started ","ttl":60,"published_at":"2019-08-22T10:11:14.453Z","coreid":"30003e001147373239303438"}
{"name":"spark/flash/status","data":"success ","ttl":60,"published_at":"2019-08-22T10:11:18.973Z","coreid":"30003e001147373239303438"}
{"name":"spark/device/last_reset","data":"user","ttl":60,"published_at":"2019-08-22T10:11:23.968Z","coreid":"30003e001147373239303438"}
{"name":"particle/device/updates/enabled","data":"true","ttl":60,"published_at":"2019-08-22T10:11:24.092Z","coreid":"30003e001147373239303438"}
{"name":"particle/device/updates/forced","data":"false","ttl":60,"published_at":"2019-08-22T10:11:24.232Z","coreid":"30003e001147373239303438"}
{"name":"spark/device/diagnostics/update","data":"{\"device\":{\"power\":{\"battery\":{\"charge\":{\"err\":-210},\"state\":\"disconnected\"},\"source\":\"USB host\"},\"system\":{\"uptime\":2,\"memory\":{\"total\":113664,\"used\":24992}},\"network\":{\"connection\":{\"status\":4,\"error\":0,\"disconnects\":0,\"attempts\":1,\"disconnect\":0},\"signal\":{\"rssi\":-95,\"strength\":27.08,\"quality\":38.77,\"qualityv\":-15,\"at\":4,\"strengthv\":-95},\"cellular\":{\"cell_global_identity\":{\"mobile_country_code\":310,\"mobile_network_code\":410,\"location_area_code\":51990,\"cell_id\":249824144},\"radio_access_technology\":\"3G\",\"operator\":\"AT&T Wireless Inc.\"}},\"cloud\":{\"connection\":{\"status\":1,\"error\":0,\"attempts\":1,\"disconnect\":0},\"disconnects\":0,\"publish\":{\"rate_limited\":0},\"coap\":{\"unack\":0}}},\"service\":{\"device\":{\"status\":\"ok\"},\"coap\":{\"round_trip\":299},\"cloud\":{\"uptime\":1,\"publish\":{\"sent\":2}}}}","ttl":60,"published_at":"2019-08-22T10:11:24.956Z","coreid":"30003e001147373239303438"}
{"name":"spark/device/app-hash","data":"F346860E82F2351C28C103F1501C5A929866F52FA773B34391022F9B276C6EA3","ttl":60,"published_at":"2019-08-22T10:11:30.413Z","coreid":"30003e001147373239303438"}
{"name":"mtr_data","data":"{\"FWACTIVATE\":4,\"RSSI\":-95,\"B\":348,\"ERR\":\"MTR_RD_ERR\"}","ttl":60,"published_at":"2019-08-22T10:11:44.841Z","coreid":"30003e001147373239303438"}
{"name":"hook-sent/mtr_data","data":"","ttl":60,"published_at":"2019-08-22T10:11:45.174Z","coreid":"particle-internal"}

Here is the output of my flash operation

> Executing task: make -f 'C:\Users\blong\.particle\toolchains\buildscripts\1.6.1\Makefile' flash-user -s <

Done.
   text    data     bss     dec     hex filename
   7484     116     468    8068    1f84 f:/Development/particle/bill_test/target/bill_test.elf
Serial device PARTICLE_SERIAL_DEV : not available
Flashing using dfu:
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 2b04:d00a
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08080000, size = 7600
Download        [=========================] 100%         7600 bytes
Download done.
File downloaded successfully

*** FLASHED SUCCESSFULLY ***

I’m pretty stumped.

7

Oops, I missed that part on first browse of your post
So, yes that's probably the issue

It appears this device ID is associated with a PRODUCT_ID (6175) (probably by another product creator).
Since that will cause the cloud to revert any changes made to the installed firmware back to what the product creator intended to run on that device you will see this behaviour.

This is the intended behaviour for Products.

If this Electron is in fact a "normal" development device which you bought as standalone device (no part of a 3rd party product where you "salvaged" the Electron from) it's possibly an issue where the product creator accidentally added the wrong (your) device ID to his fleet of devices.

To solve that issue, you should open a support ticket and reference this thread. Particle should be able to find out who owns PRODUCT_ID (6175) and how to get your device detached from their fleet (providing it's not legitimately linked to it).

BTW, if you ever happened to flash some code that featured the macro PRODUCT_ID() with an ID where you are not the owner of that ID, then you just handed over your device ID to that product creator and they probably put it into quaranteene as they don't trust your device ID to be legit in their fleet.

8

Wow. You are fast! Thank you. Since I posted, I have gone back and looked at the app firmware our partner sent along with us. Sure enough, that Light_OnOff was in that chunk of code.

Thank you for the tip on the ProductId. I remember reading that somewhere over the last few days, but didn’t make the connection. The firmware that our partner is using is also coded up to bind their SIMs to their network credentials. However, they gave us a Particle SIM.

All is clear now. I have reached out to them. They should be able to remove that device from their account by unclaiming it right? That would clear the PRODUCT_ID association?

Again, thank you VERY MUCH for your help.

1 Like
9

They also need to remove it from their devices list in the product.

You should also make sure the device is not still running code that would again associate the device with the product.
I would write a dummy sketch that uses SYSTEM_MODE(MANUAL) to prevent the device from going back online and which does not feature the PRODUCT_ID() macro and flash that to the Electron.
Then wait till they released the device ID.
After that you can flash any new code to the device that also reconnects to the cloud (again not using PRODUCT_ID() :wink: )

10

yep. that was the problem. Thanks again for your help.

1 Like