Serial UART / Firmware upgrade

[Pete]

Hi guys,

I received my WiPy 2.0 today, with the aim of rapidly implementing a semi-official project for work (a kind of test device for internal use with one of our actual products). I need to accept serial input, and I'd prefer to do it on the second UART so that the first remains free for debugging and backup access in case the wifi config gets messed up (my application needs to change the wifi config to do its job, so messing up is a real possibility :-) ).

Trying to open the second UART doesn't respond as I'd expect, according to the docs:

[pete@Panorama:~]$ telnet 192.168.4.1
Trying 192.168.4.1...
Connected to 192.168.4.1.
Escape character is '^]'.
MicroPython 1f7bdfd on 2016-10-09; WiPy with ESP32
Login as: micro
Password: 
Login succeeded!
Type "help()" for more information.

>>> from machine import UART
>>> port2 = UART(1, 4800)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: resource not available

Uh-oh - "resource not available"?

Try the first port, which I know works as I've previously used the REPL through it:

>>> port1 = UART(0, 4800)
>>>

Ok, success (or at least, no error). Let's send a load of random characters over the serial link and see if they show up...
<tappity tappity tappity, kill screen to make sure any buffers are flushed...>

>>> port1.any()
0

Oh. We're not receiving them for some reason. Lets try some other stuff...

>>> UART.init(bus=1, baudrate=4800, pins=(P3,P4))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'UART' has no attribute 'init'
>>> port1.init()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'UART' object has no attribute 'init'
>>> help(UART)
<class 'UART'>  any -- <function>
  read -- <function>
  readall -- <function>
  readline -- <function>
  readinto -- <function>
  write -- <function>
  EVEN -- 0
  ODD -- 1
  RX_ANY -- 2

This doesn't seem to match the docs. Maybe it's out of date...

>>> os.uname().release
'0.9.0b'
>>> 

Ok, not current, let's see about upgrading.

I downloaded and ran the OSX firmware upgrade tool. It seems to run ok, though gives very little feedback. It accepts my selection of FTDI adapter, and claims to have retrieved some info (current version, I guess?) from the board. Then it says "Please wait, firmware download in progress...", and stays at the this point forever. Wireshark shows that it isn't actually downloading anything once in this state, although it does make some connections earlier in the process (can't see what, of course, thanks to TLS). I assume something's gone wrong in a separate download process, with no provision to bubble the error back up to the UI.

My goal here is to be able to read serial input, wrangle wifi connections, and emit UDP packets. As a general principle I'd like to do that at the latest version, but that's not essential if 0.9.0b can do what I need. Your urgent help with either half of the problem would be much appreciated, I have a project manager to make happy...

Pete

[Pete]

Ok, success.

I didn't persist with the GUI installer, but I suspect the problem is that the Python install it brings with it is looking in some OpenSSL directory for the set of CA certs to trust. On OSX this is empty because MacOS keeps such things in its Keychain, and the normal OS tools (including the stock Python) are configured to look there instead: http://stackoverflow.com/a/24694579/326838

Major fail for just hanging the UI instead of reporting the error though. WTF? It's not as if calling out to a Web server is some infallible operation that will always succeed.

Anyway, the CLI python updater that @jmarcelino pointed to above worked fine for me. OSX Sierra, 10.12.3 (16D32). I did install pyserial first (I assumed it was needed, didn't actually check what happened without it). The quickest way to do that was to grab the Rudix installer for pip and then do sudo pip install pyserial.

Thanks for the pointer to the commandline updater and the firmware image; I hope this post helps others in the same boat.

Pete

[Pete]

OK, so here's one clue - I've just tried to wget the tarball you linked, and wget doesn't like the certificate:

[pete@Panorama:~/wipy]$ wget https://software.pycom.io/downloads/WiPy-1.5.1.b1.tar.gz
--2017-02-08 19:15:43--  https://software.pycom.io/downloads/WiPy-1.5.1.b1.tar.gz
Resolving software.pycom.io (software.pycom.io)... 104.18.44.76, 104.18.45.76, 2400:cb00:2048:1::6812:2d4c, ...
Connecting to software.pycom.io (software.pycom.io)|104.18.44.76|:443... connected.
ERROR: cannot verify software.pycom.io's certificate, issued by ‘CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB’:
  Unable to locally verify the issuer's authority.
To connect to software.pycom.io insecurely, use `--no-check-certificate'.
[pete@Panorama:~/wipy]$ 

Seems likely that this is the problem for the GUI downloader too. I wonder where the GUI gets its list of trusted CAs from?

Pete

[Pete]

@jmarcelino Thanks. I'll give that a try tonight. It looks like someone has successfully used it on MacOS in the last three weeks, which is promising.

Presumably the updater just treats the firmware tarball as an opaque image, so the update behaviour shouldn't depend on what version you're deploying?

If it doesn't work, do you have any pointers to help debug the GUI updater? It must write a log file somewhere, surely?

Thanks,

Pete

[jmarcelino]

@Pete
A while back it possible to run this for a more "manual" install

https://forum.pycom.io/topic/517/downgrading-firmware-advanced-users

but of course you'd download the latest image from:

https://software.pycom.io/downloads/WiPy-1.5.1.b1.tar.gz

Not sure if it'll still work since there's been some changes.

[Pete]

Thanks - no explicit proxy involved, just a normal domestic Internet connection (100Mbit cable, Virgin Media for any UK readers here). Using my browser (Chrome) I was able to download Pymakr and the firmware update tool itself, which seem to come from the same server.

I won't be able to try again until this evening (UK time, about 9 hours from now) but I did try repeatedly over several hours last night.

Is there an easy way to run the underlying tool more directly, so that any errors are more likely to be visible (or is there a log for the GUI tool being written somewhere?). I will say that my Mac at home is not really set up for development work (I use Fedora in the office, but the thing with the WiPy is more of a personal project at home) - so I think it only has the stock OSX python which I believe is 2.7, and there's no pip in my $PATH (didn't look into that at all).

Pete

[jmarcelino]

You'll definitely need to update as there have been many critical changes to UART (right from 0.9.1.b1, "Complete the UART and Pin classes.")

The update process should work though, do you happen to be behind a proxy?

It could also have been a temporary network problem, have you tried again?