Wifi Creds getting reset

photon
Tags: #<Tag:0x00007fe2202c8148>

#1

So I have been working with a photon and it was previously working on version 0.6.2
However, I recently updated the base OS to 1.1.0 and reflashed my old code. However, everytime I flash my old code, it’s wifi creds are getting wiped out and it is going in setup mode. I don’t have any WiFi.ClearCredentials() line in my code and it is the same code which has been working fine with the 0.6.2 version. Is there something that needs to be changed when migrating from 0.6.x to 1.x version?


Serial err: Error: Opening COM1: File not found
#2

And I always wanted to ask, what happens if you flash an application for an older version of OS on a device with a newer version?
I see that the tinker that is getting flashed is still compiled for the 0.4.5 from the particle serial inspect. Does it mean that I can also flash a code built for an older OS version to a device with a newer OS?


#3

@moz, posting your code would be helpful. And yes, you can target older versions of DeviceOS and have them run on devices running newer versions. Do note, however, that some DeviceOS functions may not behave as they did in older versions.


#4

Hi @peekay123, thanks for replying. However, I cannot share my code as it is not my IP.
Here is the serial inspect output with the new OS and the old application.
image

Also, is there a list to the things that gets changed or needs attention when moving from one version to another? Or as to how is the interaction with wifi different in newer and older versions?


#5

@moz, if you can’t share your code, can you create a minimal test program that produces the same results?

You can look here for firmware release details:

https://prerelease-docs.particle.io/reference/device-os/firmware/photon/?fw_ver=1.2.0-rc.1&cli_ver=1.41.0&electron_parts=3#device-os-versions


#6

Hey. So I was doing tests on my photon regarding the wifi creds drop and found out that the command buttonMirror() was resetting it. It was going to setup mode in loop and I can’t find any changes made to the API to make this happen. Also, the photon with the updated OS is not able to detect my network wifi. I have to use my mobile hotspot even though the older versions were able to connect to it.


#7

Are you sure it’s the command and not the button (or how it is setup).
When you keep the button (on-board or mirrored) activated for 10+ seconds the WiFi creds will be wiped.
When you chose the wrong pull-resistor/mode combination for the mirror then that would be expected.

https://docs.particle.io/tutorials/device-os/led/photon/#wi-fi-network-reset


#8

I had similar doubts regarding this. However, after testing some more, it doesn’t seems to be the case. The board is still going into setup mode with the buttonMirror absent.
And also, I would like to ask on how to downgrade the device OS version except from the web IDE because that is not working.


#9

That doesn’t actually prove anything.
If you had set the buttonMirror() call store the setting to be active on boot-up that setting is sticky and just removing the call won’t undo that. You’d have to actively disable the morroring.

Have another read in the docs about buttonMirror()
https://docs.particle.io/reference/device-os/firmware/photon/#buttonmirror-

You cannot downgrade the device OS version via Web IDE.
To actually downgrade you need to download the respective device OS binaries and flash them via CLI.


#10

I absolutely forgot about that. I’ll try that right away.

And also can you please tell me where in the repo can I find the OS binaries?


#11

In this thread you’ll always find the links to the individual releases (and upgrading/downgrading instructions)
Particle Device OS Updates Thread

And this is where the releases can be found by tag


#12

The code seems to be working after disabling the button mirror. However, I’m still not sure how can they both be connected. I’ve assigned it as Pinmode(D1, INPUT) and the mirror is set as buttonMirror(D1, FALLING)
I don’t see any connection and reason for it to get activated on it’s own.


#13

If you have no external pull-up resistor applied you must use INPUT_PULLUP to avoid the floating pin to be read as LOW.


#14

I was going to do that next and it seems to be working now. I guess in the newer OS versions they have updated the Floating pin and Falling signal definition. Nevertheless, things seems to be in control now. Thank you so much for your support.