I’m having some issues with two different Particle boards flashing yellow but not responding to DFU commands and being unresponsive to attempts to reset the device or change modes.
A few days ago I began having issues putting a xenon board into listen mode in order to flash to the device over serial. My typical workflow is to put the device into listen mode (flashing blue) and then flash over serial, but I’ll sometimes use the Web IDE if that process has hiccups. However, a few days ago I began having trouble flashing to the device (either over wifi or serial). The web IDE would claim that flash was successful, but the device status LED would remain breathing cyan and attempts to put the device into listen mode didn’t seem to work (pushing “MODE” for any amount of time wouldn’t cause the typical blue flashing).
After a few resets of the device I tried powering the device into safe mode before turning it to listen mode as some other posts suggested for similar issues. This seemed to work as the device began flashing blue after holding “MODE” while it was in safe mode. Unfortunately though, when I attempted to flash to the device over serial, it began to flash yellow and would not respond to any of my commands or reset attempts (even a factory reset).
Since I had another Xenon around I decided I would move over to that device, but quickly after setting it up I ran into the same issue. It seemed to be working at first, but had the same issues when trying to put it into listen mode. I did a factory reset of the device and reconnected to my mesh network. After doing that the device seemed to be having trouble even entering listen mode still. When I attempted to go from safe mode to listen mode I ran into the same issue–flashing yellow and unresponsive.
I’ve tried factory resetting it as well as starting in safe mode, but both of these processes just end with the device flashing yellow. They seem to work for a second (flashing purple to indicate safe mode is starting up, then immediately going back to flashing yellow. Same thing with factory reset for the white led signal).
My issue seemed similar to this community post, however when I use dfu-util -l my device does not show up and running particle serial list doesn’t list the device even though it is connected to my computer via USB.
Is this a known issue or something that’s been seen in other scenarios? I apologize if this is a repeated post, but the only other similar issue seemed to be the other post I mentioned which I couldn’t use to resolve my issue.
Any help would be appreciated or explanation as to how I may have messed things up.
I’m using an Ubuntu VM on a Windows10 host for all CLI operations. On the windows host I don’t see the xenon in the device manager and running lsusb doesn’t bring up the xenon currently.
Regarding DFU Mode I don’t believe that I can put it in DFU Mode. When I follow the steps to put the device in DFU Mode it flashes yellow after a brief magenta flash, but running dfu-util -l seems to just display the program version and license:
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
After doing this the device similarly doesn’t show up in Device Manager or through the command line on the guest OS (particle list). Also when I try to flash via usb (particle serial flash __.bin) the device doesn’t respond and the flash fails. Running particle list shows the xenon as offline as well.
Here’s a screenshot of my device manager ports section. The Boron that I’m using for the mesh network shows up fine, but the xenon isn’t there.
Good idea to get things sured up on the host OS first.
Switching the Boron and the Xenon USB ports, I’m able to see the Boron show up in the device manager, but the Xenon still doesn’t show up unfortunately. That makes me think that the ports themselves are fine. Same result when I switch the cords they’re using. The issue seems pretty specific to the Boron itself.
My current machine doesn’t have speakers and I don’t have access to headphones at the moment so I’m not sure if it’s making the new device connected sound. Is there another way I might be ale to check that internally?
The device also still flashes yellow after disconnecting and reconnecting it so I’m not sure if it’s in DFU Mode, but I’m quite sure it’s not since I was able to get the dfu-util -l command to work the other day using the same device before it was giving me issues and now I only see the program version.
Let me know if there’s any other information I can provide or anything else I should try.
@smithmick14, this may sound silly, but in the instance that the device is stuck in something akin to DFU mode, it won’t present elsewhere as a USB device (as established by @ScruffR) - I don’t see any DFU CLI commands above (only flash --serial, which is not the same thing). Before moving on to a support ticket can you please:
attempt particle update and particle flash --usb tinker on the device?
Further, can I better understand why/what exactly you are flashing to the device over serial? It is my understanding that this is not the ideal mode for firmware flashing (instead reserved for the bootloader, which I further believe will be moved to DFU in the nearterm as well).
@ScruffR :
I apologize. I made a typo and meant to say it seems specific to the Xenon. The Boron does show up in Device Manager regardless of cord or USB port, but the Xenon does not show up regardless of configuration.
@marekparticle :
When trying to troubleshoot this specific issue I’ve just been using the blink.ino example to try to flash a simple program, but in general I’ve been flashing most of my code to the Xenon over USB for the past few weeks.
Currently when I try particle update I’m met with this message:
!!! 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.
And when I run particle flash --usb tinker I’m met with the same message and an additional line:
Error writing firmware: No DFU device found
As for why I was flashing over serial–I didn’t realize that it wasn’t the ideal method for flashing firmware. I was trying to ultimately avoid some data costs and thought it might be a more reliable way to flash the device as sometimes flashing from the IDE doesn’t complete.
It’s not impossible that something got corrupted with the Xenon’s ability to handle serial if you are flashing application firmware over serial, especially if threading was enabled (meaning that some process would occur concurrently with a flash, leading to some odd behavior).
@marekparticle :
I don’t have one, no. Is it possible that something like this could be resolved with a factory reset? I’ve tried factory resetting the Xenon but it simply flashes white once or twice and then returns to flashing yellow repeatedly.
Hello Smithick14
I had similar problem, I was able to recover my Xenon by doing factory reset few times in a row.
There are two ways to set the Device in DFU mode one is using the mode button
Other is from particle usb dfu (when only 1 Xenon is connected to the computer via usb)
So now you see how it is going into DFU mode automatically. Either the Firmware update has failed due to packet delays or fragmented packets and it is trying to complete the firmware update or upload
VM ware is not supported platform for Particle-CLI only MacoS, Linux and Windows work best and factory Reset few time to recover the device worked for me. I hope it does for you as well !! Sorry I forgot to mention update you CLI bu using particle update-cli first and do not use VM, VM is best for Software only projects
HI,
I’ve had similar problems with a Pycom LoPy4. It seemed to me that the device was ‘flapping’ between normal and DFU mode and Windows wasn’t seeing either state long enough to load the ‘right’ drivers. I went through their ‘Updating Firmware’ process to re-install the DFU code.
All OK since then, but interesting that this is a Xenon.
Dave
