P1 setup fails on App, CLI + interactive Listen mode

I have a problem with a series of a product I have that is based on P1 modules. The error is the same for all PCB’s in this batch, but no change have been made to the PCB layout for the P1 module in this iteration.

When setting up via App (both Android or iOS) it never gets past “Connecting to Photon”. Using CLI (1.29.0 and 1.30.0), I will sometimes get this error:

{ Error: connect ENETUNREACH 192.168.0.1:5609 - Local (0.0.0.0:58288)
at Object.exports._errnoException (util.js:1022:11)
at exports._exceptionWithHostPort (util.js:1045:20)
at connect (net.js:884:16)
at net.js:973:9
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)
code: ‘ENETUNREACH’,
errno: ‘ENETUNREACH’,
syscall: ‘connect’,
address: ‘192.168.0.1’,
port: 5609 }
Your Photon encountered an error while trying to scan for nearby Wi-Fi networks. Retrying…

In some rare cases, setup via CLI works after getting a few of these errors and the scanning suddenly works. Using the Listen Mode Commands, I can input the wifi settings but upon saving it says:

“Derp. Sorry, we couldn’t save the credentials.”

What can cause this behaviour? It’s a crisis for the company if this happens once the devices have been shipped to customers all over Europe…

Another possible error is that via CLI we almost set it all up, but once we send the wifi password, we get this:

! Something went wrong: Serial timed out
Potentially unhandled rejection [3] Serial timed out (WARNING: non-Error used)
Potentially unhandled rejection [4] Serial timed out (WARNING: non-Error used)

Update: This might be related! When running “particle identify”, it does not identify properly. Instead of showing the full UID, it only shows the first 8 numbers of it like this:

$particle identify
Your device id is 24004900
Your system firmware version is 0.7.0

The number is obviously much longer, so this is definitely wrong…

Another update: device doctor fails in step 2:

Flash success!
The Doctor didn’t complete sucesfully. undefined
Please visit our community forums for help with this error:
https://community.particle.io/

It successfully flashes, but then fails to do what it should and just hangs. If I skip this stage and go straight to the wifi setup, I get another error:

? Select how the device will be assigned an IP address Dynamic IP
Serial err: Error: Error: No such file or directory, cannot open /dev/tty.usbmodem14611
Serial problems, please reconnect the device.
The Doctor didn’t complete sucesfully. undefined

Clearing EEPROM data also fails:

Clear all data in EEPROM storage
? Select Continue when ready Continue
The Doctor didn’t complete sucesfully. “path” is not defined: undefined

Have you inspected the boards? How well are they (is the P1) soldered on? I’ve ran into an issue whereby shoddy solder paste was used (stored outside the fridge!) and left me with really wonky behaviors including non-functional USB/serial ports. If its not the solder, do you know the heat profile they ran on the boards? Perhaps they are just not handled right.

1 Like

The boards were done by Eurocircuits and they really know their stuff. I’ve actually never had a failed board from them, but I can of course not be 100% sure… I guess I could reflow the P1 on one of the boards to see if it makes any difference, but this is kind of similar for all the boards, and I would guess that shoddy soldering would make the boards behave somewhat randomly?

Well if the boards look OK, try to get a dfu-util going on the USB port and relfash your OS. If that too does not work, bad P1 modules? (Something i have never had).

You sad that a previous batch (same design) worked alright so no layout changes are likely to blame, how about any build up under the P1? Any chances that a via or solder blob might interfere? It would be strage to see that happen on a whole series of boards though. But if reflash fails, perhaps pull one of the P1s of the board and see whats going on underneath.

Oh, you do have ample power going to the board right?

I have it confirmed now. The hardware is solid. If I flash with Tinker, I can always set the board up so this is something related to our firmware. I’ll start a separate thread for that.

@jenschr, no doubt you have solved the issue.

Did you start another thread on this topic as you stated? If so, can you point to it from this ticket?

Am suffering with exactly the same behaviour you have found:

Your device id is nnnnnnnnnnnnnnnnnnnnnnnn
SSID: UMDHOTSPOT2
Security 0=unsecured, 1=WEP, 2=WPA, 3=WPA2, 4=WPA Enterprise, 5=WPA2 Enterprise: 3
Security Cipher 1=AES, 2=TKIP, 3=AES+TKIP: 3

Password: XXXXXXXXX

Thanks! Wait while I save those credentials...

Derp. Sorry, we couldn't save the credentials.
Your device id is nnnnnnnnnnnnnnnn

This was for a special build of my firmware - which has some code added for a specific test that we are performing.

I simply overcame the issue by setting unit into SAFE MODE, and was only then able to set the WiFi credentials in the normal way.

Aside from the inability to set the WiFi parameters, the special build is having other weird side effects when it cannot connect to the Particle Cloud (but can connect to the WiFi access point).

I think that the two issues are related and it is most definitely user code that is the cause. The question is what? [Smells of stack / timer issues]

@UMD I did. If I remember correctly it was this thread Listen Mode (possible bug) I basically ran out of memory and that caused setup to fail.

@jenschr, I will continue my investigations and report back. Could be a while… Am chasing a few theories …

@jenschr, I have raised a ticket for my specific issue: P1 - no WiFi forces P1S6 input port HIGH. Have a look at it if you are curious!

That’s really odd. I’m following in case this can cause other problems. I have many products based on the P1 - one of them is CE/UL certified and a potential firestarter. I checked and this behavior on this device would only make it turn off power, so it should be safe :slight_smile:

@jenschr, great to hear that you have a hot product ready to go!

Would like to understand what you meant by “I checked and this behavior on this device would only make it turn off power, so it should be safe”

Remember, the issue is only when there is no WiFi… (and there is a Particle Disconnect in play???)

Sure. This pin is used to listen for the rotation of one of the brushless fan motors in the machine. It’ll be pulled down or up externally by the motor driver, depending on the commutation of the motor. If we’re not getting this signal as expected, the machine will turn off all heat since running without fans is a fire risk.

Cutting wifi while operating is one of those things we’ve tested a lot since it’s a very real situation for some users. You probably know this, but the P0/P1 will connect to the network with the correct name. No other checks done against Bssid or such. In corporate settings with many APs with the same name, you can easily end up with a terrible signal since the Broadcom chip holds on to the last used, rather than using the one with the best signal…