Oh, sorry about that. Since I believe you have the CLI installed already, it should just be a matter of copying and pasting that into a file, say, tester.ino and saving the file on your computer.
Connect the Photon by USB and put it in DFU mode, blinking yellow.
Then, open a command prompt window, cd into the directory you saved the file in, and issue the command:
particle compile photon tester.ino --saveTo firmware.bin
particle flash --usb firmware.bin
The test program is not being executed.
Initially I thought, hey!, Iām not getting the terminal program running quick enough after I power up the Photon after flashing it. I put a print statement in the setup function, which didnāt help. Then I added some code to blink an LED on my PC board for a couple seconds; again that was in setup. No joy, no blinks.
Here are the terminal shell commands and output, below Not sure thereās anything much there.
When it executes, or rather, SOMETHING, executes, it immediately starts blinking the RGB light. Cyan blinks for maybe 20 seconds, red blinks 3 times (āCannot connect to Cloudā) and green blinks for 20 seconds. Not sure of the exact order there.
I note you are using SYSTEM_THREAD(ENABLED). I know not what this does. Sure you meant to use it?
Hey! Let me take out the SYSTEM_MODE(MANUAL) and see what happens! No joy. Removal of that line has same behaviour. And if I change it explicitly to AUTOMATIC, same thing.
Last thing to try: Remove SYSTEM_THREAD directive. No joy. Same bad behaviour of the test program not running.
=======
hahn:desktop jimhahn$ particle compile photon tester.ino --saveTo firmware.bin
Compiling code for photon
Including:
tester.ino
attempting to compile firmware
pushing file: tester.ino
downloading binary from: /v1/binaries/57eea320b9b2d0db4bd04fa1
saving to: firmware.bin
Memory use:
text data bss dec hex filename
7596 8 604 8208 2010
Compile succeeded.
Saved firmware to: /Users/jimhahn/Desktop/firmware.bin
hahn:desktop jimhahn$ particle flash --usb firmware.bin
running dfu-util -l
Found DFU device 2b04:d006
checking file firmware.bin
spawning dfu-util -d 2b04:d006 -a 0 -i 0 -s 0x080A0000:leave -D firmware.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2b04:d006
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x080a0000, size = 7604
Download [=========================] 100% 7604 bytes
Download done.
File downloaded successfully
Flash success!
hahn:desktop jimhahn$
=======
Interesting. It seems like itās going into the safe mode healer, which it shouldnāt have done because I thought you had 0.5.2 on the Photon. You could try using this command instead:
particle compile photon tester.ino --target 0.4.9 --saveTo firmware.bin
particle flash --usb firmware.bin
Sorry for the difficulties,
Rick
This says I have 0.5.2:
particle identify
Your device id is 360033001347353236343033
Your system firmware version is 0.5.2
Someday (not now) you can explain what a Safe mode healer is. I could guess, but Iād be wrong.
OK, letās try a build against 0.4.9. Nope. Same behaviour. What you call Safe mode healing.
That was with AUTOMATIC and no SYSTEM THREAD.
That code has to be run the way I wrote it, with MANUAL mode and SYSTEM_THREAD(ENABLED) or it wonāt work properly.
give me a minuteā¦
We got something! My LED blinks and we have serial output. I said I put a printstatement in the INITIAL_WAIT code and I see I did not look carefully enough at flow of control. I have a slew of GOTO WIFI START lines. Ignore them.
But, hereās the output:
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 failure
failed to resolve api address
failed to resolve device address
failed to connect to the cloud
connecting wifi
connected to Wifi
ping 8.8.8.8 failure
failed to resolve api address
failed to resolve device address
That was agains 0.4.9ā¦SYSTEM THREADS and MANUAL>
For some unknown reason, your Photon is able to connect to Wifi, but once connected it unable to do anything. Itās behaving as if the Wifi access point is on but not connected to the Internet, though there are other reasons this could occur.
The test program pings 8.8.8.8 (the Google DNS) and also tries to look up the DNS address of api.particle.io and device.spark.io, and all of these things fail, which is why you canāt get to the cloud.
Very useful information, but Iām still thinking about the next step.
Let me give you a tiny bit of background.
We run MANUAL because our project will run where there is no wifi and no 4G or phone service at all. We have many sensor boards, each of which has a Photon. All Photons communicate with a central server, a laptop, feeding it their data streams. How? We manufacture a local WIFI via Nano2 Loco stations.
This works great. Now, the Photon I used to do your experiments is no longer running our app, but all the other Photons are.
In order to debug back in our basement, we implemented a command which tells our app to do a Particle.connect. This gets us the cloud and we can flash code in and debug. This used to work and is the core problem we now have. That plus the probably identical issue of Safe Mode doesnāt work.
Did cloud software change in the last couple months which might have something to do with all this? Is there something out code could have done to memory in the Photon which gronked it?
When was the last time an automatic firmware download was initiated from Particleās end?
Thanks,
ājim
EE 1969, same school as you. In Boston suburbs now.
Is it possible that the Photon is connecting to the wrong WiFi, the isolated one, not the one connected to the Internet?
Hold down the SETUP button while it blinks blue until it blinks blue rapidly to clear the WiFi credentials. Release the SETUP button and it should go back to blinking blue slowly.
Then issue the command particle serial wifi to reconfigure your Wi-Fi configuration.
That isolated wifi is not running right now. Only my home wifi router.
I have wifi creds for my remote wifi (itās named target21), plus my main home router plus a wifi extender in the other room. (It has a different SSID of course.) I am happy to unplug the wifi extender and try again. But I donāt see how that affects things; it has full Internet access.
Creds must be kept somewhere else in memory and available to the firmware itself.
Do you want me to run the particle serial wifi command or something else? Like unplug the wifi extender.
Not sure. I guess you could try this program and see what the Photon thinks is configured and visible:
#include "Particle.h"
// To build:
// particle compile photon --target 0.4.9 wifidebug.cpp --saveTo wifidebug.bin
SYSTEM_MODE(MANUAL);
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 reportPeriodMs = 10000;
unsigned long lastReport = 0;
void setup() {
Serial.begin(9600);
WiFi.on();
WiFi.useDynamicIP();
}
void loop() {
if (millis() - lastReport >= reportPeriodMs) {
lastReport = millis();
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);
}
}
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);
}
exactly what I had started to do! give me a minute. obviously this is agains 0.4.9.
Output against 4.9 below.
Just what I expected. Three creds. BlueMoose and BlueMoose_EST are mine. target21 is my Nano wifi I use in the boonies.
The available wifiās are mine (the above plus BlueMoose-guest, a captive portal for guests. Then the rest are from neighbors.
I donāt think this is gonna be causal because my partner, 10 miles away, sees the same bad behaviour: Cannot cloud connect.
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=-34
SSID=xfinitywifi security=unsecured channel=1 rssi=-36
SSID= security=wpa2 channel=1 rssi=-36
SSID=BlueMoose security=wpa2 channel=11 rssi=-53
SSID=BlueMoose-guest security=unsecured channel=11 rssi=-47
SSID=BlueMoose_EXT security=wpa2 channel=11 rssi=-74
SSID= security=wpa2 channel=6 rssi=-71
SSID=xfinitywifi security=unsecured channel=6 rssi=-70
SSID=HOME-A9D2 security=wpa2 channel=6 rssi=-72
One other thing. I am thinking maybe our app is gronking some important place in memory. The only place we play games is in the EEPROM, which I think is simulated. If thereās a problem with what we do and stuff gets stomped on, maybe thatās the problem.
These are the only places we write to EEPROM (a temperature correction offset):
EEPROM.update(1, 255); // EEPROM position ONE. MARK AS UNUSED
tOffsetCode = (uint8_t)round(tOffset); // 'round' returns INT
EEPROM.update(1, tOffsetCode); // EEPROM position ONEHas the non-functioning Photon been battery powered? Thereās a thing where some low-voltage condition causes corruption of the flash. Sometimes the entire boot loader can be erased. This should never happen because the hardware should prevent it, but it does occur. Just throwing out random possibilities here.
While you canāt connect to the cloud, itās not so much a cloud issue as you canāt connect to anything at all over Wi-Fi. The end result is the same but the cause is different. Since youāre not even getting off the Photon we can for now rule out everything on the cloud side, since the Photon canāt even see the Google DNS 8.8.8.8, let alone connect to the Particle cloud.
As this is completely uncharted territory, Iād probably start by rolling back the firmware to 0.4.9 and a good baseline and see if that works.
If that doesnāt work, then try clearing the WiFi credentials and setting them again, in case something in the configuration is corrupted.
Then start adding things back in, as at this point weāre well beyond the normal set of known troubleshooting steps.
Sorry for the difficulties,
Rick
Two questions from you, replies combined here.
We power only through the micro-USB on the Photon board. The 5v then flows through the board to OUR board which has a half dozen ICās on it and a bunch of resistors and RJ11 telephone connectors. The total current draw is 110ma.
During debugging we almost always power from the laptop. We need the serial output. In the field we run off USB spare batteries. You probably have one - it can recharge a dead iPad or iPhone.
We noted a problem with one type of USB battery: Every once in a while vOut would droop from 5v nominal down to about 4.5v or so. I donāt think thatās what you are talking about. We found these problem batteries because it phantom tripped some voltage comparator circuits on our PC board, erroneously signaling a sensor event.
So enough on volts and amps. You said: āWhile you canāt connect to the cloud, itās not so much a cloud issue as you canāt connect to anything at all over Wi-Fi.ā
Thatās not exactly true. After we found this problem of Cannot Cloud Connect, we tried our system out. The software we flashed into the Photon six weeks or so ago works just fine. That is to say, our Photon listens for a specific socket connection from the laptop. When it gets it, the bidirectional data stream works just fine. So we CAN do stuff over wifi, just not Internet stuff.
The steps to stick in new software apps was real easy. Just the two commands you gave me were needed. Now I need to learn how to load new firmware. If you have a few handy instructions to do that, pass them on!
I said above that our app still works although it cannot cloud connect. One of the keyboard commands we can issue to us is to tell us a ton of status information. Namely, what wifi nets are seen and which we have creds for. Given that our apps DO work, it must be that the creds themselves are not corrupted. However, once I flash 0.4.9 I will check that. It WAS 0.4.9, right? That you wanted?
But having said all that, if there is a deep bug in my stuff or the firmware or the cloud software, Iād expect whatever corruption exists to immediately happen again. Remember, all of our Photons have this problem. (Thatās not true, we checked 3 of them and I assume all 6 have the problem.)
Can you tell me when the last automatic download of software took place? Firmware.
Also, do you know when any new cloud software was released. All our junk worked, say, two months ago and now itās not working. Did something change in Particle-land in that period.
i gotta do other stuff now. I will get back to this either very late tonight or tomorrow. (Friday) Thanks for all the help. I bet you have a full time job over and above customer helper for Particle. I, on the other hand, am retired.
ājim