With the latest wifidebug I made it stay in cloud connected mode, so you should be able to try OTA flashing and see what it does.
No joy. Sequence of events:
I had forgotten to do one other experiment from last night: Reboot router at home. Did that and, since the laptop got confused, we got a free MacBook reboot also.
Tried build/flash. Did not work.
Then saw your email. Re-ran your latest program. Concur it stops when cloud connected. Tried build/flash. Nothing.
I am sure you are frustrated but, believe me, so am I! Thanks for the continued help on this, to everyone.
BTW: I have gotten several messages from KyleG, the forum moderator, asking about whether I have entered a support ticket. I keep saying I HAVE; he keeps saying he has no record of it. Go figure.
–jim
What is the error you are getting when you try to cloud flash? I presume this is from the Particle Build (Web IDE).
Does the Photon blink magenta at all when you trigger the OTA flash?
What if you do a CLI cloud flash?
particle flash YOUR_DEVICE_NAME tinker
This part of the output shows a problem even though it connected.
The system firmware had a rule in earlier releases that if the cloud host could not be reached by name, a default IP address was used. But this caused problems now that things are scaled up so the default address was removed, but only very recently (merged on 26 Aug 2016 so I don't think it is 0.6.0). Interestingly the cloud IP address above is not the default address hardcoded in system firmware, so I am not sure this is in play.
I do not know how you are getting DNS service with a 0.0.0.0 DNS server.
Can you describe your DNS and DHCP setup? Most people have their WiFi router as their local DNS server and DHCP server but many other ways are possible. If you network is configured in a way such that your WiFi router is not your DNS and DHCP servers, that would be a big clue.
For readability of that I've taken the liberty to wrap up your output blocks of some posts into a set of these
```text
your text here
You could also have a look at some other [Forum Tips and Tricks](https://community.particle.io/t/forum-tips-and-tricks/3999) for future postsIn previous experiments, the symptom when I do a Build/flash is that there is no magenta flashing on the Photon.
Will now try “particle flash YOUR_DEVICE_NAME tinker”. Never done this before but do says it will flash to orig firmware. I think that would be 0.5.2. Remember, 0.4.9 is in there now.
Says it worked:
particle flash SnapShot-135jim5th tinker
attempting to flash firmware to your device SnapShot-135jim5th
Flash device OK: Update started
I kinda wish the documentation said what mode the device needed to be in for all these particle commands to work. Listening and dfu mode did not work. Safe mode did.
Your notes says this is a cloud flash. I have difficulty believing that happened as I saw no magenta flashes.
Will try dfu mode and try again. Times out, which I guess is reasonable if dfu mode does not allow for cloud connections.
I did a particle identify and it’s still 0.4.9.
Now moving on to bko’s note:
Gee, I have no idea how to describe my DNS and DHCP setup. Not meaning to be sarcastic. I do know we set our Photon to “static”, not “dynamic”. (I can get into WHY if needed.) “Static” somehow gets remembered by the device when it’s powered down/up.
Note in screen shot below that everything is grayed out. I have Comcast Xfinitiy as my Internet supplier.
For an OTA flash you need cloud connection and Listening or DFU mode are not cloud connected.
Much of the time when one of you guys puts something in this forum topic, I do NOT get an email telling me there’s something new for me. Sometimes yes, but sometimes no. So I have to keep refreshing the support page. FYI only.
This may go hand in hand with my “Do you have another question?” submissions getting lost in space.
Feel free to SMS or even call if you think I have dropped off the planet. USA 617-921-5226 Email: hahn_02493@yahoo.com.
@jim_hahn I should have explained particle flash YOUR_DEVICE_NAME tinker must be done either in breathing cyan (normal operating mode) or safe mode (breathing magenta). Also, it changes the user firmware, not the system firmware.
I wanted Tinker on there so you could see if the Photon is responding to cloud function calls. You could then try, with the Photon breathing cyan:
particle call YOUR_DEVICE_NAME digitalWrite "D7=HIGH"
The D7 blue LED should go on and the call should return 1.
Tinker works. I can use your code to make D7 go on or off. Return code = 1.
Quite interesting. When this command executes, to what extent is cloud connectivity needed? (Yes, probably a dumb question.) And to what extent is CoAP in the loop?
Mysterious! There’s only one cloud connection and it’s used for everything, functions, publishes and OTA flash. I need to think about this some more.
@jim_hahn (maybe an explicit ping is required to trigger a notification mail), just to clarify your setup:
You have set static IP and also set the appropriate gateway and dns IPs like this
void setup() {
IPAddress myAddress(192,168,1,100);
IPAddress netmask(255,255,255,0);
IPAddress gateway(192,168,1,1);
IPAddress dns(192,168,1,1);
WiFi.setStaticIP(myAddress, netmask, gateway, dns);
// now let's use the configured IP
WiFi.useStaticIP();
}
To be on the safe side, can you add that section in @rickkas7's test program too (with your respective addresses of course 
)
Could it be that your routers DNS (your inital 192.168.1.1) got some "amnesia" issues?
Also make sure that no other device requires your static IP (disable DHCP on your router or block out the static IP range - if you haven't already).
I know you are frustrated but these are complex systems with many links in the chain and a failure at any link can cause problems. I am just trying to point out an obvious problem that needs to be fixed. It may or may not be your main problem.
You Photon should report 192.168.1.1 as its DNS server address but it does not.
If you are using a static IP when connected to your Comcast router and setting your Photon 192.168.1.113 as its IP address, then you are likely not setting the DNS host properly (the fourth argument to WiFi.setStaticIP() ). On the other hand, if you are getting your 192.168.1.113 address from a DHCP server on your router (which seems more likely to me), then it seems likely that your router is not doing the right thing.
The doc for static and dynamic address setup is here:
https://docs.particle.io/reference/firmware/photon/#usestaticip-
Have another dollop of ‘mysterious’ for your plate:
Build & flash just worked!
I loaded a small checker program we have for our PC board and it is happily blinking lights.
HOWEVER: Just cause I am sorta up now, should not be a reason to say all is well. We don’t know what is going on.
Gee, I wonder if my OTHER Photon I have on my desk will flash? More mystery ensues:
I plug my other board and Photon in. It begins running my big application which has been loaded in it for months. Good.
I issue my keyboard command to “connect to cloud”. This was put in so I could do flashes and debug. This command fails just like it originally did on my other Photon.
(This photon has nomenclature 138 which is the last 3 digits of the static IP address. 135 is the Photon that, a few minutes ago, successfully did a flash. These numbers are written on small tags affixed to the physical Photon so we can keep track of them.)
I try to go to safe mode. It fails. Just like 135 did originally.
All I did to 135 is issue your command to make D7 go high or low. At some point I should try that with 138.
Let’s look at where we are.
-
Did some magic bit in a mapping table get set properly on the Cloud side which now allows 135 to communicate. But 138’s bit is still gronked.
-
Is there a secret bit INSIDE the Photon which is now properly set in 135 and is not yet reset in 138?
-
Does the command particle call 360033001347353236343033 digitalWrite "D7=LOW" cause such a bit to get properly set?
We are working more than one issue at once so I gotta try not to get confused.
None of rickkas7’s programs deal with anything like myAddress or anything like that. That’s kinda obvious but I wanted to say it.
MANY months ago (six) we put in code to shift to “static”. We executed that code one time only. The first snip below is the action routine initiated to goto static.
oid setStatic(char *inBuf, int inLen, char *outBuf, int outMax)
{
char *s1; // FROM ptr
char *s2; // TO ptr
int index = macIndex(myMACaddrS);
String stringIP = mac2ip[index].ip;
IPAddress staticIP = string2ipa(toCharStar(stringIP));
WiFi.setStaticIP(staticIP, mySubnetMask, myGateway, myDNS);
WiFi.useStaticIP();
myIPaddr = staticIP;
s1 = ipa2string(myIPaddr); // to char *, actually
s2 = &myIPaddrS[0];
strcpy(s2,s1);
replyBegin();
reply("setting the IP address to "); replyln(myIPaddrS);
replyEnd(outBuf, outMax);
}
Turns out our big application, now running in 138, spits out a lot of setup info we found useful for debugging. (DNS is ominous.)
VERSION: target photon v0.6b17 -- MANUAL -- trim temperature msgs. Add time from last bullet event. 60ms compiled on Aug 16 2016 00:09:36 (GMT)
System version: 0.5.2
Wifi connected
'myMACaddrS' = 6C:0B:84:59:65:7D
my IP address: 192.168.1.138
subnet mask: 255.255.255.0
SSID = ''
DNS: 0.0.0.0
SSID = 'BlueMoose'
WiFi ready
# access points found: 7
SSID: HOME-4FC9-2.4
Security: 3
Channel: 1
RSSI: -44
SSID: xfinitywifi
Security: 0
Channel: 1
RSSI: -45
SSID:
Security: 3
Channel: 1
RSSI: -44
SSID: BlueMoose
Security: 3
Channel: 11
RSSI: -63
SSID: BlueMoose-guest
Security: 0
Channel: 11
RSSI: -62
SSID: HOME-A9D2
Security: 3
Channel: 6
RSSI: -70
SSID: xfinitywifi
Security: 0
Channel: 6
RSSI: -69
Where do we get the DNS value printed above?
myDNS = WiFi.dnsServerIP();
s1 = ipa2string(myDNS);
s2 = &myDNSS[0];
strcpy(s2,s1);
Serial.printf("DNS: %s\r\n", myDNSS);
Just to remind folks, all this code worked perfectly on 16 Aug 2016 (see date in printout above) and Build/flash worked fine.
Would it be possible to flash my big application into the now-sorta-working Photon 135 and see what IT thinks the DNS values are?
[I am getting burned, but not giving up.]
Just to lock this into my mind.
My wifi is reporting 0.0.0.0 for the DNS server address. And that’s wrong; I got that part.
That also explains why Safe Mode didn’t work, right? It would have used the same bogus DNS values.
I have to go with "maybe" as my answer. It seems likely that it is related but there is no smoking gun. I do not know how any Internet related activity can succeed without DNS unless you already know the IP address.
I am starting to think that DCT area on these Photon are corrupt. DCT is a protected area in which certain boot time parameters are stored on the CPU chip. If @mdma had time to look at a dump of the DCT area (which can done using dfu-util) it might be helpful.
Tell me how to get a DCT dump using dfu-util. Or any other method!
Grasping at straws: On Aug 16, 2016 our team (my end, not yours!) loaded a new app into our Photons. The app works fine, just as the previous version did. Now, here comes the supposition: SOMETHING we did in that Aug 16 release blew something in DCT memory. What or how, who knows? So from then on, the app still runs but we cannot connect to cloud.
A test of this theory would to take the 135 Photon that now APPEARS to be able to flash. Flash the August 16 app back into into it. Verify the app works. Then see if the DCT has been corrupted. Not positive I can get the EXACT version of 16 Aug but it will be close. If you want that experiment done, ask. It’s a pretty wild shot in the dark though.
I see no reason a command like particle call 360033001347353236343033 digitalWrite “D7=LOW” would cause the DCT to repair itself though.
** New and amazing information follows! **
We have found a workaround. That’s good news. The bad news, perhaps you will agree, is that nobody understands the behavior we are seeing. From Particle’s point of view, there is still a bug inside, somewhere.
Here’s the workaround:
-
I run our application. It runs fine, doing it’s primary job managing our sensor board. The code has a command for ‘static’ and one for ‘dynamic’.
-
We issue the dynamic command.
-
We reboot the Photon. (== Unplug and replug the USB.)
-
Now our command, “cloud”, works. It successfully does a cloud connect.
-
Build/flash now works.
My partner, Randy, found the workaround. I enclose his email on this below. I do not personally subscribe to his “part 2” that the ISP’s changed the DNS server. Randy and I have separate ISP’s.
There is one proviso to this ISP comment. Following is from a Xfinity web site:
As of August 30, 2016, the agreement between Comcast and Verizon Wireless has expired. Therefore, both companies will no longer market or sell each other’s services.
August 30 is a hell of a coincidence because that’s just about when things stopped working. I cannot really believe it’s causal, but it’s interesting.
Note also that the app in Randy’s Photon came up with a version string of 13 July 2016. That kills my theory that something we accidentally did for the 16 August version triggered the problem, perhaps corrupting DCT.
As Particle continues to work on the underlying issue, we on our end stand ready to help with any debugging or test code needed.
Randy Enger Today at 4:37 PM
To 'Jim Hahn’
CC 'Randy Enger’
To re-cap what we talked about on the phone just now:
I powered up my Photon via the serial cable, connected the terminal program to it, and got the following information:
our version 0.6c, 13-July-2016
system version 0.5.2
Jim’s editVersion: 111
DNS: 0.0.0.0
I did a “cloud” command and it hung. (This command is one of ours. It does a ‘Particle.connect()’ call. Our code keeps trying every time through ‘loop()’ until it succeeds. But it never does. But ‘loop()’ IS running … when the ‘Particle.connect()’ call returns we just instantly get to the next call to it.) Flashing doesn’t work … of course: we’re not connected to the cloud.
I then powered the Photon down and back up, and gave the “dynamic” command. (This command is one of ours. It does a ‘WiFi.useDynamicIP()’ call. That’s it.) At this point, I did a “cloud” command and it hung as before.
I powered down and back up. I did another “cloud” command. IT WORKED.
I flashed the latest code; it worked.
our version 0.6c7, 18-July-2016
system version 0.5.3
Jim’s editVersion: 111
DNS: 0.0.0.0
Note that the DNS IP address is still 0.0.0.0. I think this is because we’re behind the home router. (NB: WE FETCH THE DNS ADDRESS ONLY AT BOOT UP. IT MIGHT BE THAT SOMETHING ISN’T SETTLED WHEN WE ASK FOR IT. EARLY ON, THE SSID IS blank, BUT THEN IT GOES TO “VLZBF”. AT THIS TIME, WE DON’T HAVE A COMMAND TO READ AND PRINT OUT THE DNS ADDRESS. I’LL TRY TO ADD SUCH RIGHT NOW, BUT I DON’T WANT TO HOLD UP THIS E-MAIL FOR THAT.)
My hypothesis, part 1 of 2, is that the “static” command is “fixing” not only the IP address of the Photon but also the IP address of the DNS server. Here’s the two lines from the “static” command which are relevant:
WiFi.setStaticIP(staticIP, mySubnetMask, myGateway, myDNS);
WiFi.useStaticIP();
I’ll have to go check the doc here, but I think there’s no interface routine that lets us just set the Photon’s IP address, and that’s why the DNS arg is passed in.
Part 2 of my hypothesis is that our ISPs – or something in the capital-I internet – changed the DNS server address, but we were (are) fixed to the old one. And so our Photons can’t connect to the Particle cloud.
Glad you have it (sort of) working!
That sounds vaguely like what I was thinking. That’s why I added the calls to dump out all of that information, but unfortunately, I think something is getting stuck inside the Wi-Fi code when you switch from static to dynamic, and unfortunately I don’t have access to that code (licensing issue) so that makes it more complicated to debug.
I will add a task to take a look at what happens when you switch from static to dynamic, but at least you have a workaround for now.