Particle Boron stuck in Green

Troubleshooting
1

I was working with some Borons, they were connected and working properly before, but now they are not so I’ve been trying to get them to reconnect and here are the logs.

starting tests...
turning cellular on...
0000015009 [system.nm] INFO: State changed: DISABLED -> IFACE_DOWN
0000036159 [hal] ERROR: No response from NCP
deviceID=<redacted>
manufacturer=
model=
firmware version=
ordering code=
IMEI=
IMSI=
ICCID=
0000117160 [app] INFO: enabling trace logging
0000117162 [ncp.at] TRACE: > AT+CGDCONT?
0000123793 [sys.power] TRACE: re-enabling charging
0000123836 [sys.power] TRACE: Battery state UNKNOWN -> CHARGED
0000124781 [sys.power] TRACE: Battery state CHARGED -> DISCONNECTED
0000127163 [ncp.at] TRACE: > AT+CSQ
attempting to connect to the cellular network...
0000137165 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000137165 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000137169 [hal] TRACE: PPP netif -> 8
0000137170 [net.ifapi] INFO: Netif pp3 state UP
0000137170 [net.ifapi] INFO: Netif pp3 state UP
0000137173 [hal] TRACE: Powering modem on
0000137174 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000137174 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000137323 [hal] TRACE: Modem powered on
0000137324 [hal] TRACE: Setting UART voltage translator state 1
0000138326 [ncp.at] TRACE: > AT
0000139327 [ncp.at] TRACE: > AT
0000140328 [ncp.at] TRACE: > AT
0000141329 [ncp.at] TRACE: > AT
0000142330 [ncp.at] TRACE: > AT
0000143330 [ncp.at] TRACE: > AT
0000144331 [ncp.at] TRACE: > AT
0000145332 [ncp.at] TRACE: > AT
0000146333 [ncp.at] TRACE: > AT
0000147333 [ncp.at] TRACE: > AT
0000148334 [ncp.at] TRACE: > AT
0000149334 [ncp.at] TRACE: > AT
0000150335 [ncp.at] TRACE: > AT
0000151335 [ncp.at] TRACE: > AT
0000152336 [ncp.at] TRACE: > AT
0000153337 [ncp.at] TRACE: > AT
0000154338 [ncp.at] TRACE: > AT
0000155339 [ncp.at] TRACE: > AT
0000156340 [ncp.at] TRACE: > AT
0000157341 [ncp.at] TRACE: > AT
0000158341 [hal] ERROR: No response from NCP
0000158341 [hal] ERROR: No response from NCP
0000158343 [hal] TRACE: Setting UART voltage translator state 0
0000158344 [hal] TRACE: Hard resetting the modem
0000169345 [net.pppncp] TRACE: Failed to initialize ublox NCP client: -210
0000169347 [hal] TRACE: Setting UART voltage translator state 0
0000169349 [hal] TRACE: Modem already off
0000169450 [hal] TRACE: Powering modem on
0000169601 [hal] TRACE: Modem powered on
0000169602 [hal] TRACE: Setting UART voltage translator state 1
0000170604 [ncp.at] TRACE: > AT
0000171605 [ncp.at] TRACE: > AT
0000172606 [ncp.at] TRACE: > AT
0000173606 [ncp.at] TRACE: > AT
2

Hi there – can you try doing the CLI command particle update on at least one of the Borons?

How many Borons are exhibiting this behavior?

Are they all connected to the same type of circuit (if any)?

How are they being powered?

3

So, I already tried that, all Borons should be running OS 1.4.2 and they are 20 devices as of now that present the same error.

The thing is, when I hit Patricle Identify, it only shows (if it doesn’t time out) the device ID, after that it shows it’s unable to determine device firmware.

4

I want to make sure that the following are all true:

  1. There are 20 devices,
  2. all of which are running 1.4.2,
  3. but none of them report the Device OS when queried, and
  4. all are giving the [hal] ERROR: No response from NCP message

And – once again – what are they connected to? How are they being powered? Are batteries being used as either the primary or backup power source?

How did you update the units to 1.4.2 – manually, or via selecting a target Device OS in either Web IDE, CLI, or workbench?

Did this behavior begin only after the 1.4.2 update?

Finally – where did you buy these units from, and approximately when was it?

5

Sure,

Let me elaborate further:

These borons where bought on in a batch of about 150 borons, back in Feb or March, directly with our Particle Sales Executive.

They have been powered only through USB 5V 3 Amp output, no external Lipo as backup.

I was using an external sim and recently we began to change to the internal SIM, so through CLI, I ran a Particle Update, and my code to activate the internal SIMs. Of all the Borons, these 20 present those logs I uploaded.

First, they would lose connection to the cloud constantly, due to the local carrier coverage, that’s why we changed to internal sims, since they have better coverage, and they were running OS 1.2.1 back then.

These Borons only operate as voltage sensors out in the field measuring charge levels through analog inputs every 2:30 minutes.