Photon web IDE "flash" stopped working [Resolved]

Cloud
41

There are no automatic system firmware updates for Photons. When you build firmware, it specifies a minimum system firmware version that can be used with it. If the system firmware is older than the target version, it will be automatically upgraded by the cloud, that’s the safe mode healer.

What version is targeted depends on the tool you use. Particle Build (Web IDE) has a popup menu for it. Particle Dev (atom IDE) always uses the latest release. Particle CLI uses the latest release, or a different one if you use the --target command line option.

I think up some more debugging code to try next week over the weekend.

42

OK, I kept working.

I think I got the 4.9 firmware in ok. “particle ident” says it’s 4.9

I went to “build”. Under devices, set the build against field to 4.9. (Right?)

No OTA flash.

Went to chip buttons to try Safe mode. I get breathing magenta which says it’s working. But flash does not work.

Unplugged chip and replugged in. Breathing blue. Well, appears to be blue not cyan. Breathing blue says no wifi.

Gotta run…… will check creds when get back.

43

Continuing from previous note…. Re flashed the tester.ino program. I figured if it ran, that meant creds were there.

It did run and interesting output: Last time this was run, it failed ping and connect to cloud. This time it DID work. The reference to CoAP I don’t understand what that is. Below, sometimes it connects and sometimes not. Huh! See output at end of this note.

Given that SOMETHING was successfully doing a cloud connect in the output below, I wondered if a flash over the web IDE would work. No, it didn’t.

Then I realized that your program uses MANUAL and maybe that was preventing the flash. (It should.) I got Safe mode to breath magenta. Tried a flash and, NO. It still did not flash.

Finally I wondered if a program in AUTOMATIC was in the Photon and THEN I did a flash, would the flash work? Answer: No. (To try this I created a dummy toy program in AUTOMATIC, dfu loaded it, and it ran. Then tried the flash.)

Entered INITIAL_WAIT and waited 5 seconds. GOTO WIFI_START
Entered INITIAL_WAIT and waited 5 seconds. GOTO WIFI_START
Entered INITIAL_WAIT and waited 5 seconds. GOTO WIFI_START
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 107.23.59.113
device.spark.io = 52.206.84.246
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 107.23.59.113
device.spark.io = 52.23.193.249
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.206.84.246
device.spark.io = 107.23.59.113
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 107.23.59.113
device.spark.io = 107.23.59.113
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 failure
api.particle.io = 52.206.84.246
device.spark.io = 52.206.84.246
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.206.84.246
device.spark.io = 54.172.247.72
connected to device server CoAP!       DID connect!
connected to the cloud!
disconnecting from cloud
44

That is a very interesting result, not one I would expect at all.

There are two main servers involved in cloud transactions, api.particle.io, the side used by web apps, the CLI, etc., and device.spark.io, the side used by Photons. Photons use the CoAP protocol over TCP port 5683 for all communications to the cloud.

What the last log is showing is that sometimes the DNS is resolving incorrectly. The device server is different, and whenever DNS returns the wrong address, “could not connect to device server by CoAP” is displayed. However, this is either a bug in my test program, or an oddity within the DNS implementation, because a cloud connection still succeeds after that.

When my test program runs and connects to the cloud, it also publishes and event. It would be interesting to know if that goes out correctly. You can use https://console.particle.io and open the Events tab before running the test.

1 Like
45

Saw your note and went to the console.particle.io page.

You used the phrase “event tab” and probably you meant “logs”. (RIght?) All it says is “Waiting for events”. I will re-run your program and again check this log page.

On the devices tab, it shows five Photons claimed by me. The one I am playing with is SnapShot-135jim5th". (My partner and I got confused on who’s on first, so we put some name convention in place which doesn’t really work that well.) It says “Last connection at Sept 30th 2016 at 11:16pm”. That jibes with when I did the latest test last night.

The 135 in the name refers to the static IP address for this photon. We use static in our project and I guess that means it stays static at 135 thereafter.

I ran it. I have serial output and I took a picture of the log page. I will try to stick the screen shot picture in here. Actually, let me put the picture in another reply message. Could be sticking a screen shot in will blow this editing session and I don’t want to lose that.

Comment: I let it run for 8 cycles. (Your tester program, that is.) 6 times it did NOT CoAP connect, 2 times it did. That tells me it’s random. So when I ran the program previously and we did not see a CoAP connect, I bet we didn’t let it run long enough to really understand the behaviour.

So here’s the serial output:

Startup …. in 'setup' now
Entered INITIAL_WAIT and waited 5 seconds. GOTO WIFI_START  [I fixed the program so it only prints this once.]
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.5.40.217
device.spark.io = 52.5.40.217
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.206.250.203
device.spark.io = 52.206.250.203
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.5.40.217
device.spark.io = 52.5.40.217
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.5.40.217
device.spark.io = 52.5.40.217
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.5.40.217
device.spark.io = 52.5.40.217
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.5.40.217
device.spark.io = 54.172.247.72
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.206.250.203
device.spark.io = 54.172.247.72
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.206.250.203
device.spark.io = 52.206.250.203
could not connect to device server by CoAP
connected to the cloud!
46

Here’s an attempt at the screen shot: Looks like it worked with drag/drop from desktop.

Screen Shot 2016-10-01 at 7.49.47 AM.png1194×604 45 KB

47

See: https://github.com/spark/device-updater/issues/13

It seems oddly similar.

BTW: It appears that users are directly entering bugs in github. I cannot believe this is condoned or encouraged! No?

Also, in looking over these buglogs (that’s what I call them, sorry), I don’t see anything regarding my cloud connect issue. FYI.

48

No entering bugs is not really appreciated, but bug reports are welcome :wink:

But an "issue" like the one you linked above is not quite the quality we'd expect to see there.
There is too little evidence that this actually is a bug on the Particle sida and strong indicators of a "user side" shortcoming - this would better be discussed here first to clarify all the user side issues (e.g. how to get to Safe Mode - which is not possible without antenna - or "what is dfu-util").

2 Likes
49

You have thousands (?) of users. Once they start entering bugs directly into your buglog system, you will have lost control of the process of dealing with bugs and feature requests. Allowing users to do bug reports, as you suggest, and having the forum weed out the user problems, sounds like a much better way to go. However, it appears that users can directly access and enter things in the buglog. Maybe I am misreading that guy who was having problems buffering and printing a lot of data; it seemed like he entered his issue directly into the buglog. In github.

Curious why you say there is a strong indicator of user side shortcomings. Here’s how I see it:

User has 6 Photons programmed to run his application. Application runs great. Use of web based IDE and flash works great. Two months go by because user had other things to do in life. (I know, always a surprise.) User now decides he wants to make a simple change. Photons still run user application correctly. But ‘build’ can no longer flash.

This is confirmed at two user development sites. Flash does not work. Safe mode also does not work. They used to work.

User rebuilds ‘keys’. No joy. User is asked to install different firmware. 0.4.9 instead of 0.5.2. User spends six hours performing all experiments and tests suggested by Particle. No joy.

Now you are correct with your implication that user is a novice. “What is dfu-util?” certainly ran through my head! But that’s because I never had to do that in order to get my job done. (The job being: Get my application to work.) We started using Photon because it was a clean, easy to use system. And it was/is. It’s great.

So, seriously, if you can think of something I may have done to cause cloud connect and safe mode to no longer work, I am eager to hear it. As I wrote software for 35 years, it was my first guess that it WAS my problem. (And, frankly, it still is.) But I didn’t change anything! All I did is suspend development for 2 months and when I came back, I could not flash.

I am not upset with your or your comments. I am just struggling.

BTW: What did you mean by your antenna comment: how to get to Safe Mode - which is not possible without antenna.

I hope that once the weekend is over, rickkas7 and I can continue pushing forward.

Thanks,
–jim

50

That's no problem yet, but once it would go the way you fear, there will be extra steps introduced to prevent flooding the issue tracker :wink:

This is not what I read in the link you provided above

But as it seems, we were talking about two different links :wink:
That also explains this, which was refering to that GitHub issue you linked above

I'd like to get my hands on one of the 6 Photons that seem to misbehave to get to the root of that issue, doing it via the forum is rather cumbersome once it falls out the usual suspects list.

51

If this problem keeps going on, I’ll be happy to ship one to you! Austria, right?

I am hoping rickkas7 will have some ideas tomorrow, Monday.

My reference to “https://github.com/spark/device-updater/issues/13” was because this user had a chip which previously Safe Mode worked, but then it stopped working. It seemed similar to my problem.

Sorry for confusing things with my poor references to user issues and github. I was saying that it APPEARED like a user had directly entered things in the buglog. And I said that seemed like a dangerous thing to allow customers to do directly. That reference was to entry “https://github.com/spark/firmware/issues/1131”.

Do you have a comment on the CoAP sometimes connected, sometimes not? This was some test code rickkas7 asked me to run. Output line in question from rickkas7’s test program:
could not connect to device server by CoAP

I have only a conceptual understanding of CoAP but it makes sense that it’s required for OTA “flash” to work.

52

For him the problem is the missing antenna. The device would try to get into Safe Mode, but SM is an AUTOMATIC mode and hence needs to get contact to the cloud to enter its final state of breathing (cloud connected) magenta - which obviously can't happen without antenna.

And I guess, when it previously worked for him, that was while the antenna was still intact.

The problem with the inability to connect to the CoAP server seems to be related to a flaky DNS resolution. I've no idea why you sometimes get a 52.206.250.203 as its IP, which is obviously wrong, since it's the same as for api.particle.io.
But since @rickkas7 has already commented on that odd DNS behaviour, I'm positive he'll be looking into that already.
I think to remember that there was a fix some time ago that addressed DNS glitches, but I think that was pre 0.5.2.
But to have all available fixes, you could try upgrading to 0.6.0-rc.2

53

I entered the phrase "safe mode" to the search engine on Particle support. I have to say I see many people who cannot go into safe mode with their chips. I am not positive of the commonality of these separate issues.

One unfortunate commonality goes as follows: The original poster lays out the problem. Then many people come in with suggestions, none of which work. Then several other people pile on saying THEY have the exact same problem. The unfortunate part is that none of the threads end in a solution. What happened to all these people? Did they simply give up? Did Particle fix the problems, somehow, but nobody published what the solution was?

This snip below resonates with me. The guy had a working system and, kaboom!, next day he cannot go into safe mode. I didn't add up the people who have this problem (either the OP or folks that piled in) but it looks to be a dozen or so.
--jim

54

I think one of the key aspects to why ScruffR is suggesting this may be a user side (rather than Particle side) problem is the fact that Safe Mode doesn’t do any thing fancy (meaning it is pretty robust and unlikely to fail due to programming errors) but still requires a reliable internet link. Results of the test code you’ve been asked to run seem to be pointing to the Photons not getting that for some reason. The reasons for that are many and varied, hence why it’s hard to diagnose.

Hence when the ‘don’t run any user code, and just connect to the Particle cloud for programming’ safe mode doesn’t work… more likely than not (especially since you haven’t updated the code) it is something in your wifi/network/internet environment that has gone wrong. It could be something as simple as something has gone stupid in your router, and it needs a reboot, maybe your ISPs DNS server is acting weird…

However, here is the strange thing… your screenshot is indicating that on that occasion at least, your Photon was connecting to the Particle cloud, enough so that it could submit publish messages. I would have be interested to see your results then if you tried to do a OTA flash whilst that code was running, and if the device attempted to acknowledge that update at all ( or completely ignored it ) - when looking both ad the device, and at the event logs.

and btw, on the topic of the ‘bug logs’ - the GitHub Issue Tracker- users introducing bugs is not appreciated, but bug reports - i.e. reproducible steps to demonstrate some flaw or unexpected in the Particle code-base - is usually perfectly fine and appreciated by the developers. They love it even more if you or someone else finds the cause of the bug, and submits a pull request allowing them to simply add it and test the fix. This is made possible as the particle code is provided under a open source license, allowing anyone to view, contribute to and re-purpose the code for their own usage. This allows other developers to submit pull requests with improvements or bug fixes, and also allows people to identify issues and report them. More heads (and eyes) on the code the better. That’s my 2c anyway.

4 Likes
55

I think I am understanding what you are asking me to do: Run the test program which flips in and out of particle connect. While it IS connected, try to do a OTA flash. How about if I were to put a, say, 15 second delay in there when the connection IS made. That gives me a better chance to do the OTA flash. While doing that, I should keep an eye on the log.

Not sure I can do that tonight though. Getting late in Boston.

Two things:

  1. There do seem to be several issues in the forums where safe mode is not functional. I counted perhaps a dozen people talking about this in 2 or 3 forum entries. It would be great if something simple like rebooting the router fixed things. And I will try that before the experiment above.
  2. My partner on this project lives 10 miles away. He and I have different Internet companies (Comcast and Verizon). So the DNS server weirdness may not be operative. His Photons and mine fail same way.

Please define “pull request”. Is this where the user actually grabs the source code, debugs it, and specifies the bugfix?

56

Basically yes, and adding a delay would certainly make life easier for you! :smiley:

Well, the different ISPs certainly knocks that off as a possible cause. Still, it’s certainly very curious that the Photon was hit and miss in connecting to the CoAP service, even though it was indicating it did connect. For starters, I’d probably add the delay in just after the code sends a particle publish message… so add a delay to the runCloudTests() function at the end of the code.

void runCloudTests() {
	Particle.publish("apiServerCheck", "passed", PRIVATE);
        delay(15000);
}

In GIT parlance, a pull request is where you have made changes to the code, and wish to let others know of that, usually the original project you got the code from. But we’ve missed a step by jumping right to pull request. The order of things is usually like this

  1. Project author writes some code and puts it on on something like github, bitbucket.
  2. A third party comes along, sees something that is buggy or could be improved, or simply to make changes for their own usage of the code. So they they ‘fork’ the code, and make whatever changes they want to their own copy of the code.
  3. If they think the original project / author would benefit from their changes, they submit a pull request, which automatically identifies all the changes they’ve made, and they do a little write up explaining why their changes are a good thing.
2 Likes
57

I'd say you should allow for at least 30sec for an OTA and don't use a delay(30000) but this code

for(uint32_t ms = millis(); millis()-ms < 30000; Particle.process());

this ensures maximum time for the background process.
With delay() the background process is only run once every second (unless you're using SYSTEM_THREAD(ENABLED))

2 Likes
58

Good point… thanks for that ScruffR! The test script that rickkas7 provided is configured with system threading, but I think these Photons are going to need all the help they can get to co-operate! :wink: So that code is much better, making the Particle.process function run nearly constantly for the 30 seconds, making it so all the background networking and cloud stuff can keep running and updating as fast as it wants to.

A brief question if I may - it is slightly off topic, but still sort of relates, and may also provide a little more light on how the Photon updates. I’ve come to the Particle ecosystem via the Digistump Oak, which uses the Particle system to do OTA updates, device management, etc. When I trigger OTA updates on an Oak, it actually halts the running user code, and lets the update process take over completely, and then reboots into the new code if the update is successful, or just reboots back into the old code. Does the Photon do the same? Or does it run the update in the background? If this is documented somewhere and I just haven’t looked… feel free to give me a link to read! :smiley:

59

OTA firmware downloads occur in the background while your code is running, so, yes, you can interrupt the process by failing to provide enough time for cloud processing.

Also, I have a new test program. I wanted to see what the IP address settings were.

#include "Particle.h"

// To build:
// particle compile photon --target 0.4.9 wifidebug.cpp --saveTo wifidebug.bin

SYSTEM_MODE(SEMI_AUTOMATIC);
STARTUP(WiFi.selectAntenna(ANT_INTERNAL));

const char *securityString(int value); // forward declaration
void wifi_scan_callback(WiFiAccessPoint* wap, void* data); // forward declaration

const unsigned long REPORT_PERIOD_MS = 15000;
const unsigned long CONNECT_WAIT_TIME_MS = 60000;
enum State { IDLE_STATE, WIFI_REPORT_STATE, CONNECT_WAIT_STATE, CONNECT_REPORT_STATE, CLOUD_CONNECT_WAIT_STATE, CLOUD_CONNECTED_STATE, DISCONNECT_STATE };
State state = IDLE_STATE;
unsigned long stateTime = 0;

void setup() {
	Serial.begin(9600);
	WiFi.on();

	// WiFi.useDynamicIP();
}

void loop() {
	switch(state) {
	case IDLE_STATE:
		if (millis() - stateTime >= REPORT_PERIOD_MS) {
			state = WIFI_REPORT_STATE;
		}
		break;

	case WIFI_REPORT_STATE:

		if (WiFi.hasCredentials()) {
			Serial.printlnf("configured credentials:");
			WiFiAccessPoint ap[5];
			int found = WiFi.getCredentials(ap, 5);
			for(int ii = 0; ii < found; ii++) {
				Serial.printlnf("ssid=%s security=%s cipher=%d", ap[ii].ssid, securityString(ap[ii].security), ap[ii].cipher);
			}
		}

		Serial.printlnf("available access points:");
		WiFi.scan(wifi_scan_callback);

		Serial.println("connecting to WiFi");
		WiFi.connect();
		state = CONNECT_WAIT_STATE;
		stateTime = millis();
		break;

	case CONNECT_WAIT_STATE:
		if (WiFi.ready()) {
			state = CONNECT_REPORT_STATE;
		}
		else
		if (millis() - stateTime >= CONNECT_WAIT_TIME_MS) {
			Serial.println("timed out connecting to WiFi");
			state = DISCONNECT_STATE;
		}
		break;

	case CONNECT_REPORT_STATE:
		{
			Serial.println("connected to WiFi!");

			Serial.printlnf("localIP=%s", WiFi.localIP().toString().c_str());
			Serial.printlnf("subnetMask=%s", WiFi.subnetMask().toString().c_str());

			IPAddress gatewayIP = WiFi.gatewayIP();
			Serial.printlnf("gatewayIP=%s", gatewayIP.toString().c_str());

			IPAddress dnsServerIP = WiFi.dnsServerIP();
			Serial.printlnf("dnsServerIP=%s", dnsServerIP.toString().c_str());
			Serial.printlnf("dhcpServerIP=%s", WiFi.dhcpServerIP().toString().c_str());

			byte bssid[6];
			WiFi.BSSID(bssid);
			//Serial.printlnf("BSSID=%02X:%02X:%02X:%02X:%02X:%02X", bssid[0], bssid[1], bssid[2], bssid[3], bssid[4], bssid[5]);

			if (gatewayIP) {
				int count = WiFi.ping(gatewayIP, 1);
				Serial.printlnf("ping gateway=%d", count);
			}
			if (dnsServerIP) {
				int count = WiFi.ping(dnsServerIP, 1);
				Serial.printlnf("ping dnsServerIP=%d", count);
			}

			{
				IPAddress addr = IPAddress(8,8,8,8);
				int count = WiFi.ping(addr, 1);
				Serial.printlnf("ping addr %s=%d", addr.toString().c_str(), count);
			}

			{
				IPAddress addr = WiFi.resolve("device.spark.io");
				Serial.printlnf("device.spark.io=%s", addr.toString().c_str());
			}

			Serial.println("connecting to cloud");
			Particle.connect();
		}

		state = CLOUD_CONNECT_WAIT_STATE;
		break;

	case CLOUD_CONNECT_WAIT_STATE:
		if (Particle.connected()) {
			Serial.println("connected to the cloud");
			state = CLOUD_CONNECTED_STATE;
		}
		break;

	case CLOUD_CONNECTED_STATE:
		break;

	case DISCONNECT_STATE:
		Serial.println("disconnecting from WiFi");
		WiFi.disconnect();

		state = IDLE_STATE;
		stateTime = millis();
		break;
	}

}

const char *securityString(int value) {
	const char *sec = "unknown";
	switch(value) {
	case WLAN_SEC_UNSEC:
		sec = "unsecured";
		break;

	case WLAN_SEC_WEP:
		sec = "wep";
		break;

	case WLAN_SEC_WPA:
		sec = "wpa";
		break;

	case WLAN_SEC_WPA2:
		sec = "wpa2";
		break;

	case WLAN_SEC_NOT_SET:
		sec = "not set";
		break;
	}
	return sec;
}

void wifi_scan_callback(WiFiAccessPoint* wap, void* data) {


	Serial.printlnf("SSID=%s security=%s channel=%d rssi=%d",
			wap->ssid, securityString(wap->security), wap->channel, wap->rssi);

}
1 Like
60

Gee, you guys have given me a bunch of homework assignments.

  1. First see if problem still exists.

Cannot remember what program is flashed now. Breathe white a bit, then green blink, then cyan blink. Serial terminal will not connect. Try ‘build’ and flash while breathe cyan. Nothing.

Try enter safe mode. After a flurry of colored flashes (green is involved, which makes sense), I get breathe magenta. Yeah! That’s safe mode. Again try ‘build’ and flash. Nothing.

Restart app currently in chip firmware. Now it DOES start. It’s the tester program which rickkas7 gave me. Now I get serial output. Goto point 2 below.

  1. Serial output follows. Sorry for lengthy output, but too much is better than too little. Similar output to that of a couple days ago. Now it seems CoAP connection is working >50% of the time.
Startup …. in 'setup' now
Entered INITIAL_WAIT and waited 5 seconds. GOTO WIFI_START
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 52.44.116.179
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.21.141.105
device.spark.io = 52.23.193.249
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 52.44.116.179
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 54.172.247.72
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 52.21.141.105
could not connect to device server by CoAP
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 52.23.193.249
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.21.141.105
device.spark.io = 52.23.193.249
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 52.91.48.237
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 success
api.particle.io = 52.44.116.179
device.spark.io = 52.91.48.237
connected to device server CoAP!
connected to the cloud!
disconnecting from cloud
  1. In looking at the tester program, rickkas7’s finite state machine already has some delays in it. I should be able to snatch the point in time that CoAP is connected and try then to do a build+flash. Let’s try.

No joy.

  1. Time to work on experiments posed by forum folks overnight. First pfeerick’s request:
    I would have be interested to see your results then if you tried to do a OTA flash whilst that code [rickkas7’s tester program] was running, and if the device attempted to acknowledge that update at all ( or completely ignored it ) - when looking both ad the device, and at the event logs.

This is essentially what I did in step 2 above but this time I will monitor the event log. OK, done. flash failed (again) and I don’t see anything of much interest in the event log.

Screen Shot 2016-10-03 at 7.43.24 AM.png1087×509 56.8 KB

  1. Reading more from pfeerick: Did not add delay because I thought the existing code had enough delay. Re ScruffR’s worry about Particle.process, because rickkas7 code continually leaves ‘loop’ and reenters, I don’t think this is a worry.

Am I wrong here?

  1. rickkas7 has a new test program to run. Named wifidebug.cpp. Recall that the firmware is still 0.4.9, as rickkas7 properly notes in the comment in the program. Program does not continually get data; stops when cloud connected. Output follows:
configured credentials:
ssid=BlueMoose_EXT security=wpa2 cipher=1
ssid=target21 security=unsecured cipher=0
ssid=BlueMoose security=wpa2 cipher=1
available access points:
SSID=HOME-4FC9-2.4 security=wpa2 channel=1 rssi=-45
SSID=xfinitywifi security=unsecured channel=1 rssi=-44
SSID= security=wpa2 channel=1 rssi=-45
SSID=BlueMoose security=wpa2 channel=11 rssi=-52
SSID=BlueMoose-guest security=unsecured channel=11 rssi=-52
SSID=BlueMoose_EXT security=wpa2 channel=11 rssi=-73
SSID=HOME-A9D2 security=wpa2 channel=6 rssi=-73
SSID= security=wpa2 channel=6 rssi=-79
SSID=xfinitywifi security=unsecured channel=6 rssi=-75
connecting to WiFi
connected to WiFi!
localIP=192.168.1.113
subnetMask=255.255.255.0
gatewayIP=192.168.1.1
dnsServerIP=0.0.0.0
dhcpServerIP=0.0.0.0
ping gateway=1
ping addr 8.8.8.8=1
device.spark.io=52.23.193.249
connecting to cloud
connected to the cloud