WiPy 2.0 Using boot.py to go into Station mode

[jgmdavies]

Has anyone managed to create a boot.py that puts a WiPy 2 into Station mode, similar to section 3.2 in here ?

Thanks,
Jim

[pwest]

@abilio
I can confirm that my boot.py survives rebooting and that I'm running the most recent version of the firmware. Indeed, it appears that my boot.py is running, and that I had a syntax error on the line:
server = Server(login=('user', 'password'), timeout=60)
where I had specified a new user/pwd pair. I had thought that my boot.py wasn't running because the device came up with a server running with uid, pwd = 'micro', 'python', the default. Strange.

[abilio]

@pwest, if you connect to the board, you can do:

import os
os.uname()

There you'll find the release number. Currently, the latest version is 0.9.2.b2.

[pwest]

@abilio
I'm nearly certain that I've verified the file contents survives the reboot, but I'll re-verify tonight.

I certainly attempted to update the firmware to latest version (first attempt linux, fail, second attempt Windows 7, success), but HOW DO I VERIFY FIRMWARE VERSION, and what is the most recent?

Thanks,
Phil

[abilio]

@pwest, can you confirm the file content is still there after reboot? Did you upgrade your firmware to the last version?

[pwest]

I've been trying to get this to work, and it seems that no matter what changes I make to boot.py, the system boots into AP mode and appears with its telnet/ftp server running at 192.168.4.1.
I'm editing boot.py locally and then ftp'ing it up to the /flash directory. Under the ftp application, I can view the file and verify that my new file has been uploaded, but when I reboot, it's always back in AP mode.
Could it be the case that I'm running in one of the factory recovery modes instead of running the intended user code?

[jgmdavies]

@AgriKinetics

Thanks . That looks like what I was doing, in essence,, so I'll try again! I'm using firmware updated this morning.

[AgriKinetics]

We had the problem with wlan.ifconfig failing until the latest firmware was installed correctly. Our quick and dirty boot.py now works fine thus:

import machine# boot.py -- run on boot-up
import os

from machine import UART

uart = UART(0, 115200)

os.dupterm(uart)

import machine

from network import WLAN

wlan = WLAN() # get current object, without changing the mode

wlan.init(mode=WLAN.STA)

wlan.ifconfig(config=('ip address', 'mask', 'gateway', 'dns'))

wlan.connect('SSID', auth=(WLAN.WPA2, 'key'), timeout=5000)

[jgmdavies]

@dhallgb

Many thanks.

I got mine going in Station mode by dropping the 'wlan.ifconfig' completely, and accepting the IP address that it comes up with for now, so I can work fairly reliably in Station mode.

By the way, I also got it to survive a soft reset (control+D) by changing the line that read:

if machine.reset_cause() != machine.SOFT_RESET:

for my boot.py for the WiPy 1.0 to simply:

if wlan.mode() != wlan.STA:

for the WiPy 2.0.

As you say, there seem to be some differences in the calls, and I'm pretty sure the online docs aren't quite correct.

And where on earth is 'machine.ADC' or its new equivalent?

(And how are you doing your lovely code formatting please? I'm not used to this forum yet!)

Jim

[dhallgb]

I got mine working by dropping that test. Instead of a fixed IP I used dynamic and gave a fixed address from my DHCP server, like so: wlan.ifconfig(config='dhcp'). I also thought that the wlan.init may have changed, I had to include the mode= as part of the function call. My full boot.py looks thusly:

import os
import machine
from network import WLAN
wlan = WLAN()
wlan.init(mode=WLAN.STA)
wlan.ifconfig(config='dhcp')

if not wlan.isconnected():
    wlan.connect('xxxx', auth=(WLAN.WPA2, 'xxxx'), timeout=5000)
    while not wlan.isconnected():
        machine.idle()

from network import Server
server = Server()
server.deinit()
server.init(login=('xxxx', 'xxxx'), timeout=6000)

[jgmdavies]

I find it doesn't work if I attempt to set the IP address with something like:

wlan.ifconfig(config=(IP, SUBNET, GATEWAY, DNS_SERVER))

Also, is there a workaround for the non-availability of 'machine.SOFT_RESET'?

Thanks,
Jim