Boron LTE Unresponsive - Solid Yellow in CHG LED

Troubleshooting
1

I have a new Boron LTE. I completed the setup and got connected, could blink the D7 LED over the LTE network.

I inserted the Boron into a classic adapter and then inserted the classic adapter w/ Boron into a Relay Shield. I was powering everything from USB plugged into the Boron. Using tinker I was able to activate the relays on the relay shield. All this was working as of two days ago.

Today nothing is working. The yellow CHG LED on the Boron is lit and not blinking. The blue power LED on the relay shield is lit and not blinking. The Boron status LED is not lit. It’s not connecting to the cloud. It seems dead.

I have power cycled the Boron several times and I have removed it from the relay shield and adapter and done all the power cycle, mode presses, and reset presses several times.

Any idea how to wake the dead?

2

Hi Rickmatt,

I have this same problem with one of my Borons. Mounted in a special PCB of which I have 20 pieces running in the field. This one gave up his spirits when power connected.

Have you been able to wake your Boron?

Can’t find it in CLI- Particle doctor with USB connected.

– edit: D7 led is very dim. Found that reloading the bootloader may fix the device. Only thing is that it is unclear to me how to upload the bootloader with the Particle debugger when there is no CLI connection. Did some pretty extensive searching on the community.

3

I have the same issue. I have the Boron plugged into a custom carrier board and it is powered through the Li+ pin (not USB). It works fine for days, then without warning it becomes unresponsive. When I detach the Li+ power battery and apply power via USB the yellow USB LED will start flashing quickly, but uC won’t run even after reset. The only way to make the Boron responsive is to unplug it from the carrier board and give it USB power. It then works normally, even when I plug it back into the carrier board.
Any idea what could be causing this?
What does the yellow quickly flashing USB LED indicate?

1 Like
4

It’s normal for the CHRG yellow LED to flicker if you detach the battery and supply power via USB. This indicates that there is no battery attached, which is true. Once the device boots, it will detect that there is no battery and it will turn charging off, which stops the CHRG LED from flickering, but since the device doesn’t boot, that’s not happening. But under the circumstances, I would expect flickering.

The other situation is blinking at 1 Hz: charge suspended (Input over-voltage, TS fault, timer fault, input or system over- voltage). This mostly only occurs if you have a real battery and are powering by USB or VUSB and the battery has failed. That doesn’t sound like what you are experiencing.

When the device is in this state, put a DMM on the 3V3 pin. If it’s not powered, then the BATFAT in the PMIC somehow got turned off. However, if that was the case, the Boron should have booted when you powered by USB, so I don’t think this is the case.

What I’d guess is that you have phantom power reset failure. If you power down the device (no power on Li+, USB, or VUSB) but have leakage current going into a GPIO, the nRF52 MCU can get into a bad state where the device will not boot or reset, even if you remove power.

This is closely related to TAN002 which affected Tracker shipping mode, but it can happen with non-Tracker nRF52 devices and situations other than shipping mode (BATFET disabled).
https://docs.particle.io/reference/technical-advisory-notices/tan002-tracker-one-v10-shipping-mode/

The reason removing the device from the carrier board solves the problem is that it completely removes power, and also removes the leakage current from the GPIO, and that’s what is completely resetting the device and allowing it to boot.

To solve the situation, you need to make sure that there is no situation where you remove power from the MCU but current can still flow through GPIO. On the Tracker we needed to add an analog isolator on the GPIO pins to assure power could not flow back from the M8 connector to cause this issue.

Of course it could be something completely different, but that would be my guess.

1 Like
5

Outstanding reply Rick. This really helps. I’m reviewing my schematic to see where the leakage could be coming from. I have a few ideas to test. Thanks!

6

Hi Rick,

I think I may have had the same problem. I've been using a Boron device in a breadboard for several weeks with no problems. Came in this morning and the Boron showed no lights or signs of life. I had left the USB data/power connector off the previous day and figure the battery had discharged. Plugged the USB in and the charge light came on briefly (I believe), but no activity from the RGB, nothing. Reset and Mode buttons produced no effect and Particle CLI showed no device. Unplugged the battery and put another fully charged one on it. No difference. Then I came across your previous post. The only other connections to the Boron were to the Serial1 (TX, RX, and GND). The device on the other end of the serial line was powered up. Disconnected the serial 3-wire connector from the powered device. Still no difference! Removed the Boron from the breadboard and voila, everything is back to normal. I can't see how removing a Boron from the breadboard with no connections would make a difference. Maybe it took a few minutes for some latched-up circuit inside the nRF52840 MCU to discharge and allow a normal reboot.

What I would like to know is if this is still a problem with the Boron/nRF52840? If so what is the remedy? Must you guarantee that no signal/power is present at any GPIO pin if the Boron battery discharges? That doesn't sound right. Will the new parts EtherSIM BRN404X and B404X behave similarly?
I am using firmware version 4.0.0. My device id is: e00fce68e18485a6e73c1f4f.

Thanks,

Bob Vinci
ColdSnap

Blockquote
Platform: 13 - Boron
Modules
Bootloader module #0 - version 1101, main location, 49152 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 4003, main location, 671744 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Bootloader module #0 - version 1101
Radio stack module #0 - version 202
User module #2 - version 6, main location, 262144 bytes max size
UUID: 875D945180CDA3407D409C69FABAEA66FB0CD50DEED291C0E88E5849FD65EF27
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 4003
Radio stack module #0 - version 202, main location, 192512 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS

image
image1266×1280 147 KB

7

I’d suspect it takes a while to fully discharge and reset and if you waited long enough with the device in the breadboard it would have eventually worked.

It’s not practical to solve this problem in the Boron itself. If you’re in a situation where you have an externally powered device that feeds into a GPIO, such as the RX pin in your serial case, you will need to have some sort of isolator. That’s what we did on the Tracker One M8, but it only has effectively 3 pins that are switchable between GPIO, I2C, and Serial, and the board is significantly larger than the Boron.

1 Like