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
