Boron seems stuck in Blue Listen Mode and possibly flag reset after each flash

A Boron with Firmware 0.90 (assumed to be the most stable release) is possibly getting it’s initialization flag reset after being flashed or powered off. The device then has to be re-paired using the Particle iphone app to get it out of Listen mode. Any idea what is causing this? Could not starting “Wire.begin();” on an I2C port before reading a sensor possibly force this behavior, even after the problem code is corrected? During this blue listen mode, it one manually sends a compiled *.bin using CLI such as “particle flash --serial xxyy.bin”, the Boron will flash successfully, however the Boron will never exit listen mode and enter cyan. Additionally, any attempt to flash the Boron using the WEB IDE during this time will also fail.

The solution has bee to re-pair the Boron to the account and disable the setup flag using the iphone Paticle App. This worked a few times to bring this Boron back out of listen mode to Cyan, but now too this has stopped (iphone Particle App v2.8.2(1)) and the iphone app is stuck on the final step of “Activing Paticle SIM”, which I’m guessing is a server issue or protection mechanism from activating the same Boron SIM so many times in one day on the same account.

I would love to get this Boron back to factory state and flashed with stable firmware and bootloader binaries using the DFU mode, however I can’t get that DFU USB flash working and the online instructions don’t seem to match what I see during Win 7 x64 driver install. For instance, the only diver that installs in the yellow DFU mode is a “WinUSB Device”, which I then use Zadig to over-write the driver with linkusbK (v3.0.7.0). Sadly, any attempt to flash with CLI such as “particle flash -usb xxyyyy.bin” still fail and someone mentioned that Win 7 x64 flashing over DFU was not supported, so I’m a but confused how to upgrade firmware when the WebIDE doesn’t work and all you have if CLI serial.

Finally, there is one very trippy behavior while stuck in flashing Blue listen mode wherein you can get the Boron to enter safe mode using CLI on a machine not physically connected to the Boron. This is done by holding down the Boron Mode until yellow shows up (this mode is not likley DFU mode as the standard Boron COM port driver stays loaded despite showing yellow) and then if you send a CLI flash command that creates an error such as “particle flash -USB xxyy.bin” where -USB is erroneous because it is in all caps, something happens on the sever side and the Boron will change from yellow to SafeMode, despite that the Boron is not physically connected via USB to the CLI programming laptop. The trippy/buggy part is that a local error when flashing using CLI over USB should not send something to the Particle cloud server that causes a response in a remote Boron. This is with CLI version is 1.40 and Boron 0.90, if helpful.

Any suggestions to get this Boron back to factory state and avoid the blue blink of death would be greatly appreciated. Thanks.

Additrional Specs:
Version: 1.33.1 (user setup)
Commit: 51b0b28134d51361cf996d2f0a1c************
Date: 2019-04-11T08:27:14.102Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 6.1.7601

This would rather be --usb (two minus signs).
Have you used this driver installer and ticket the "remove old drivers"?
https://binaries.particle.io/drivers/windows/particle_drivers.exe

Falling into Safe Mode after DFU Mode may indicate that Safe Mode Healer has kicked in, which would indicate that the flashed application firmware requires a device OS update which SMH will try to perform.

Thank you for the driver link ScruffR, That is a very nice USB uninstall tool and kudos to whomever put that together to find old and hidden bad drivers. After running Particle Device Driver 1.0.0.0, the Boron in DFU mode did get installed and recognized as a Boron DFU Mode driver, however there was still no joy when attempting to “particle flash --usb xxyy.bin” with No DFU detected, even after a reboot.

I then attempted to run Zadig 2.4 and replaced the Boron DFU mode driver with Zadig libusbK 3.0.7.0 in case this step was still required. This moved the Boron DFU driver in device manager to a new device called libusbK USB Devices (shown below), however the result was sadly the same after replacing the driver with no DFU flash capability.

image

image

FYI, after installing the Particle Device Drive 1.0.0.0, when the Boron is placed in Listen (blue blink) mode, there is no longer a COM port but a WinUSBDevice 2012 by Microsoft that auto installs, so now flashing via serial and USB both don’t work. Crap.

C:\Users\jerry\Documents\Particle\Boron_I2C_scan\Boron_I2C_scan>particle flash --usb boron_firmware_1556779165306.bin

!!! I was unable to detect any devices in DFU mode…

Your device will blink yellow when in DFU mode.
If your device is not blinking yellow, please:

  1. Press and hold both the RESET/RST and MODE/SETUP buttons simultaneously.

  2. Release only the RESET/RST button while continuing to hold the MODE/SETUP button.

  3. Release the MODE/SETUP button once the device begins to blink yellow.

Error writing firmware: No DFU device found

C:\Users\jerry\Documents\Particle\Boron_I2C_scan\Boron_I2C_scan>particle flash --serial boron_firmware_1556779165306.bin
! PROTIP: Hold the SETUP button on your device until it blinks blue!
? Press ENTER when your device is blinking BLUE
Error writing firmware: No serial port identified

Update: The serial port can be found again by using Zadig to install the USB Serial (CDC) driver and I can successfully flash using --serial, but --usb is still not possible. Oddly, the Serial driver that installs with CLI or Particle Workbench appears better than the one in the driver install package above called Particle Device Drive 1.0.0.0 as the final COM port for serial shows up as Boron (COM 29) instead of WinUsb Device (COM29)

image

If DFU Mode doesn’t work it might be that you have a bad bootloader and/or SoftDevice.
Maybe @rickkas7 or support.particle.io can assist with that.