Unreliable USB serial on Boron (Device OS: 1.3.0-rc.1)


#1

While troubleshooting connectivity issues with my Boron running Device OS: 1.3.0-rc.1 I noticed that the USB serial debug printing seemed to stop randomly.

As a test I ran the following firmware on the Boron:

SYSTEM_MODE(MANUAL);

void setup() {
  pinMode(D7, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  Serial.println(millis());
  digitalWrite(D7, HIGH);
  delay(1000);
  digitalWrite(D7, LOW);
  delay(1000);
  
}

and monitored the serial output in the serial terminal using:

particle serial monitor --follow

The LED on the Boron blinked as expected without stopping but the serial output stopped randomly. Hitting the reset did not always work. Here is a sample output:

C:\Users\rober\Downloads>particle serial monitor --follow
Polling for available serial device...
Opening serial monitor for com port: "COM14"
Serial monitor opened successfully:
2561
4561
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
2437
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
2439
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
2442
4443
6443
8443
10444
12444
14445
16445
18446
20446
22447
24448
26448
28449
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:

The

Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:

events are where I hit the reset button after the serial output stopped.

As a test I ran the same firmware on a Photon with v1.1.1. It worked as expected - the LED flashed and the serial kept printing:

C:\Users\rober\Downloads>particle serial monitor --follow
Polling for available serial device...
Opening serial monitor for com port: "COM10"
Serial monitor opened successfully:
6141
8141
10141
12141
14141
16141
18141
20141
22141
24141
26141
28141
30141
32141
34141
36141
38141
40141
42142
44142
46142

Anyone able to repeat this? Is this a firmware bug or am I overlooking something?


#2

Could this be a power or wiring issue?
I don’t see that on my Borons.


#3

Nothing is connected to the Boron other than the USB cable and a battery. The same cable and PC works with a Photon.


#4

What does the RGB LED do in these instances?


#5

Slow white flash as expected in manual mode.


#6

As an additional test I registered a new Boron to v1.1.0 and ran the same test. It works fine.

One way to rule out hardware issues is to downgrade the 1.3.0-rc.1 photon to 1.1.0 and retest. I hesitate though because:

  1. I can’t find clear instructions on how to downgrade 1.3.0-rc.1
  2. I’m not wanting to brick another $60 kit.

#7

Is this a Boron 3G or LTE?
I don’t have an LTE but with my 3G I can’t replicate the issue (just running 3 minutes).

You’d just put your device into DFU Mode and run particle update -v. This will install the most recent stable version (currently 1.1.1).


#8

LTE. I’ll try the update.


#9

Oh my goodness - now I have two 1.3.0-rc.1 Boron LTE devices stuck in DFU mode after doing the below on my device that was having USB serial hiccups.

C:\Users\rober\Downloads>particle update -v

> Your device is ready for a system update.
> This process should take about 30 seconds. Here it goes!

▌ Updating system firmware on the device...dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 2b04:d00d
▀ Updating system firmware on the device...sion 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 = 0x00030000, size = 668192
▌ Updating system firmware on the device...Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error during special command "ERASE_PAGE" get_status

! An error occurred while attempting to update the system firmware of your device:

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error during special command "ERASE_PAGE" get_status


> Please visit our community forums for help with this error:
https://community.particle.io/
Cannot read property 'code' of undefined
TypeError: Cannot read property 'code' of undefined
    at dfuError (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\dist\cmd\update.js:121:18)
    at dfu.findCompatibleDFU.then.catch.err (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\dist\cmd\update.js:29:14)
    at tryCatchReject (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\node_modules\when\lib\makePromise.js:845:30)
    at runContinuation1 (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\node_modules\when\lib\makePromise.js:804:4)
    at Rejected.when (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\node_modules\when\lib\makePromise.js:625:4)
    at Pending.run (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\node_modules\when\lib\makePromise.js:483:13)
    at Scheduler._drain (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\node_modules\when\lib\Scheduler.js:62:19)
    at Scheduler.drain (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\node_modules\when\lib\Scheduler.js:27:9)
    at _combinedTickCallback (internal/process/next_tick.js:132:7)
    at process._tickCallback (internal/process/next_tick.js:181:9)

#10

This is rather strange.
Do you have another PC you can use?
Try a fresh CLI install (via the Windows Installer with ticking the remove and install drivers checkboxes)

Then download the system binary and run

particle flash --usb tinker -v
particle flash --usb boron-system-part1@1.1.1bin -v
particle flash --usb tinker

If that doesn’t work it may be that the bootloader is borked.
With Gen2 devices you had to get into Listening Mode to flash the bootloader, I’m not sure if this is still the case with Gen3 - @rickkas7?


#11

Same issue as before (see below). I’ll try another machine but I doubt it is that as I reinstalled the CLI already. Maybe the only recourse is to get a debugger (see Boron stuck in DFU mode) although I have no clue yet how to use it.

C:\Users\rober\Downloads>particle flash --usb tinker -v
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 2b04:d00d
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 = 0x000d4000, size = 11412
Download        [=========================] 100%        11412 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Flash success!
C:\Users\rober\Downloads>particle flash --usb boron-system-part1@1.1.1.bin -v
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 2b04:d00d
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 = 0x00030000, size = 668192
Download        [                         ]   0%            0 bytesInvalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
dfuse_download: libusb_control_transfer returned -9
Error writing firmware: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
dfuse_download: libusb_control_transfer returned -9

VError: Error writing firmware: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
dfuse_download: libusb_control_transfer returned -9

    at Promise.resolve.then.then.then.then.then.then.catch.err (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\dist\cmd\flash.js:198:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
caused by: Error: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
dfuse_download: libusb_control_transfer returned -9

    at ensureError (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\dist\lib\utilities.js:670:14)
    at Promise.resolve.then.then.then.then.then.then.catch.err (C:\Users\rober\AppData\Local\particle\node_modules\particle-cli\dist\cmd\flash.js:198:24)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)

C:\Users\rober\Downloads

#12

Problem solved. It was a batch of bad USB cables.

Thanks for your help @ScruffR

Sorry for wasting everyone’s time.


#13

:wink:


#14

You were 100% right. I swapped out the cable for another bad cable from the same bad batch and ruled out a cable issue. The data connectivity was intermittent and varied from test to test and device to device. Lesson learned.