I couldn’t categorize this post under “Troubleshooting” or “General” so here it is.
I have 3 photons that eventually all ended up in the same state. These were used in different projects.
They all fail in the setup process at the “Verify Device Ownership” and from boot they fast blink green, fast blink cyan, and then two yellow blinks.
So far I have tried:
Setup mode with iPhone 11 Particle app.
DFU mode with CLI using the “particle flash --usb tinker”
Resetting to DHCP uploading a bin file via DFU. The file was success in the upload, photon restarted but still stuck.
I’ve done the keys doctor thing.
particle keys server
particle keys doctor YOUR_DEVICE_ID
That might be 2 orange blinks, which means the Photon could not reach the Internet. The most likely cause of this is that a firewall is blocking all access from the Photon, a static IP address is incorrectly configured, or other similar network issues.
1 orange blink: Decryption error.
2 orange blinks: Could not reach the internet.
3 orange blinks: Connected to the internet, but could not reach the Particle Device Cloud (This sometimes is seen as yellow or red and indicates bad server keys).
1 magenta blink: Authentication error.
1 red blink: generic handshake error (device could have the wrong keys or has just encountered a generic error in the handshake process)
The issue may have been caused with a static IP being assigned to the particle’s Wi-Fi controller.
Note: before proceeding to the additional steps below, I tried flashing the resetsettings.bin to the photon. This didn’t resolve my issue until I first went and specifically flashed version 0.5.5 firmware to the photon.
[SOLVED] – What I did to resolve the issue:
1.) Download system-part1-0.5.5-photon.bin & system-part2-0.5.5-photon.bin
Paste them in the location “C:\Users\yourusername\AppData\Local\particle”
2.) Open the particle software console, create new app and call it “resetsettings”, paste the contents of the Resetsettings.ino file into the code designer. Click save. Click the download icon to download the resetsettings.ino.
Paste the resetsettings.ino file in location “C:\Users\yourusername\AppData\Local\particle”
3.) Download Particle CLI Windows CLI Installer, install the application (it will take several minutes and might look like it is freezing up, but just let it run until it’s finished. Click ok and yes to any promts.)
4.) Connect particle photon to your computer via USB
5.) Put the particle photon into DFU mode.
6.) Open CMD prompt on windows and type: “cd C:\Users\yourusername\AppData\Local\particle”
7.) Type: “particle flash --usb system-part1-0.5.5-photon.bin”
8.) Type: “particle flash --usb system-part2-0.5.5-photon.bin”
9.) Type: “particle compile photon --target 0.5.5 resetsettings.ino --saveTo resetsettings.bin” into the CMD. Run it and it will create a Hex file that can be flashed to the photon. (resetsettings.bin)
10.) Type: “particle flash --usb resetsettings.bin”
11.) At this point the particle should reboot and the D7 pin LED should light up.
12.) Proceed to putting the particle in setup mode and continue with setup as normal.
I don’t know if this is the best thread to use, but the reference to “two orange” blinks certainly applies. I have two Photons at a site and they’ve stopped pushing data to the cloud and are exhibiting the two orange blink pattern (cycling through listening, connecting to WiFi, etc.). I have flashed the photon.bin WiFi debug application which yields the following output (snippet):
0000035789 [hal.wlan] INFO: Bringing WiFi interface up with DHCP
connected to WiFi!
localIP=10.187.64.56
subnetMask=255.255.248.0
gatewayIP=10.187.64.1
dnsServerIP=10.193.100.2 (often 0.0.0.0)
dhcpServerIP=10.193.100.160 (often 0.0.0.0)
ping gateway=1
ping dnsServerIP=1
ping addr 8.8.8.8=1
device.spark.io=3.216.239.14
0000035878 [wiring] TRACE: TCPClient socket=200092c8
could not connect to device server by CoAP
connecting to cloud
0000060889 [hal.wlan] TRACE: connect cancel
0000060891 [hal] TRACE: 20015a54 socket list: 0 active sockets closed
0000060892 [hal] TRACE: 20015a5c socket list: 0 active sockets closed
0000061425 [hal.wlan] INFO: Using external antenna
Does ping 8.8.8.8=1 indicate it successfully pinged the Google DNS server? This would at least mean that traffic is making it to/from the Internet.
I’m rather at a loss, as the network manager at the site is insisting they are not blocking any traffic at the firewall. I’ve most recently asked if there’s a chance the WiFi controller is blocking, as I experienced that at another site a few weeks ago. This was a revelation to me as well as the network manager. So, others should be aware of this possibility.
Any thoughts would be greatly appreciated as I have an Argon at yet another site that’s also having similar problems, but was previously communicating just fine. It simply looks to me that TCP traffic on 5683 is being blocked.
indicates that when a test TCP connection was made to 3.216.239.14 port 5683, it failed. That typically means a firewall is blocking outbound TCP access to that port. That’s just a raw TCP connection in cloud debug, so it’s not device keys or anything like that. A TCP connection can’t be made at all.
@rickkas7, that’s what I’ve conveyed to them. Let’s hope they will take a closer look at their WiFi controller. He did indicate all he can see is it pinging Google’s DNS IP at their firewall. I’m guessing the WiFi controller also has some form of firewall capability as well and it’s stopping the 5683 traffic. At least that’s where it was surprisingly stopped at another customer’s site.
