I have a Xenon which I am trying to re-connect to a mesh network because it just keeps flashing blue. The process proceeds normally until the last step when it goes to “Adding Xenon to Mesh Network”, that is when it starts flashing red then after a little it goes back to flashing blue again.
That same Xenon on powering up also flashes blue (as if in listening mode). BTW, that same device was on the network I am trying to rejoin …
What is causing that?
I experienced a similar thing changing the mesh gateway from an Argon to a Boron, and having to set up a new network and re-install all the units via the mobile app. What might be relevant here is that, two times a Xenon would not join while behaving as you described.
Both times it seemed to be solved by using the gateway as the already joined unit instead of another Xenon, and having the unjoined Xenon and the Gateway and the mobile (app) with in a few meters of each other during the whole process. Reason unknown.
thank you @thrmttnw, I did just that but the problem persists …
Hey Jimmie,
What device OS version is your Xenon and gateway running on? You should be able to find this by putting the devices into listening mode and running the CLI command particle serial inspect.
Hello @mstanley,
Please see below:
Platform: 14
Modules
Bootloader module #0 - version 215, main location, 49152 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 326, main location, 671744 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Bootloader module #0 - version 101
undefined module #0 - version 0
User module #1 - version 5, main location, 131072 bytes max size
UUID: 3A85FBCF04592CACB2EF44730B9ECF962E6E7B5AFED1B1B0EC2608B3122D0B91
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 326
undefined module #0 - version 0
empty - factory location, 131072 bytes max size
Did you have a chance to see my response to your question?
Hey Jimmie!
Sorry about that! I’d been meaning to check up on this.
I sincerely apologize, it looks like I asked you to run particle serial inspect and had intended for particle serial identify. If you could give that a quick go for me, I’ll be sure to check back in on this ASAP.
Sorry about that! We’ll get you taken care of, I promise! 
Hello @mstanley
Thank you. here is what I got:
C:\Temp>particle serial identify
Your device id is e00fce686e26076932750834
Your system firmware version is 0.8.0-rc.27
The device is still blinking blue.
I also followed the sequence described here by @Scruffr.
After updating the bootloader, were you still experiencing the same issues?
Your other Xenons are connecting correctly, yes?
My recommendation is across the board, to go flash tinker for rc27 for your gateway and this Xenon and attempt another setup. Should it still remain stuck, I recommend filing a support ticket referencing this topic.
Yes.
Your other Xenons are connecting correctly, yes?
Yes
My recommendation is across the board, to go flash tinker for rc27 for your gateway
My recommendation is to read my post where I have indicated that it is already flashed with tinker. I CANNOT GET THE XENON OUT OF LISTENING MODE.
Hey Jimmie,
Perhaps I misunderstood. But I do not see anywhere that you tried and were unable to get your device into DFU mode at any point. While the device does power on in listening mode, this should not prevent it from entering DFU mode.
If this was attempted at any point and the device refused to enter into DFU mode, it is likely a replacement will be required.
Hello Mattyhew:
I did mention in my post that was able able to do the steps mentioned in this link (which includes getting into DFU mode).
The problem is that after this is completed, the Xenon goes back to staying in a listening mode.
Basically, there is no was to get it out of listening mode despite updating the firmware AND bootloader.
Believe me, I would like to find out what is causing this behavior as it should not happen because it causes the micro to be "locked out".
You could try to flash this to your Xenon and see whether it then manages to get out of LM then
SYSTEM_MODE(SEMI_AUTOMATIC);
void setup() {
const uint8_t val = 0x01;
dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);
// This is just so you know the operation is complete
pinMode(D7, OUTPUT);
digitalWrite(D7, HIGH);
}
Thank you. I tried it but no luck. The led turns magenta and just stays magenta.
C:\Temp>particle flash --serial resetxenon.bin
! PROTIP: Hold the SETUP button on your device until it blinks blue!
? Press ENTER when your device is blinking BLUE
sending file: resetxenon.bin
Error writing firmware: TimeoutError: timed out after 70000ms
Can you check whether the binary is actually a Xenon binary via
particle binary inspect resetxenon.bin
Also you should rather flash that binary via DFU Mode and
particle flash --usb resetxenon.bin -v
Hello @ScruffR,
Before I read your reply, I tried again by putting the Xenon in Safe mode. Of course this should not work as the Xenon is stuck in listening mode but I tried it anyway.
I then flashed the Xenon again with your code and this time it worked!
Thank you for reviving it but why did this happen in the first place?
The device’s persistence to stay in Listening Mode would suggest that the device never got properly setup to joind a mesh network hence the setup-done flag was never set.
The code above overwrote that flag to trick the device into believing it was already setup once before. A fresh attempt to join a new mesh network after the system/bootloader update may have done the same thing tho’.
That same Xenon was working and was on a mesh when all of a sudden it started flashing blue. I do not remember though if this coincided with a firmware cloud upload to that unit …
Is it possible that somehow the firmware that was on it corrupted that flag?
Unlikely, but failed updates don’t always care for expectations 