lopy4 firmware, pymakr sync

[g0hww]

Hi,

Happy to say that my pair of LoPy4s arrived today. I swapped one of them with an old LoPy on my ExpBrd2 and had a go at syncing my existing project with Atom/Pymakr, but it wasn't playing ball, though the REPL is working ok.
I thought that I might need to do a FW upgrade but pyupgrade (from pycom_firmware_update_1.1.4.b1.tar.gz) doesn't seem to have anything for the LoPy4.
My old LoPy is on FW 1.10.2.b1 and the new LoPy4 is on 1.9.2.b2. I haven't yet looked at the 2nd LoPy4 but I imagine that is the same as the one I have looked at.
I note that both the original LoPy and the new LoPy4 both report the same value for gc.mem_free() + gc.mem_alloc() of 67008 bytes.

Am I doing something wrong, or should I wait for the dust to settle and wait for solutions that are imminent?

[g0hww]

Just managed to update my pair of LoPy4s using lopyupdate from pycom_firmware_update_1.10.0.b2.tar.gz on Ubuntu 16.04 x86_64 and all is good. Now running 1.14.0.b1. My code using PyTrack GPS, wifi, MQTT, LoRa.LORA with socket.SOCK_RAW and AES with HMAC-MD5 all working as before with the old-fangled LoPys.

I guess the dust has settled :)

Edit: One LoPy4 was programmed on the Exp Brd 2 with jumper cable and the other on a PyTrack.

[RodgerG]

@robert-hh thanks for tracking this down. I had assumed that the firmware had serious issues as my application kept crashing, but simply changing uos.uname to uos.uname()[2] in the micropython script now allows it to run, so I can continue with debugging:-) The lorajoin() now also works with the LoPy4 version of the firmware.

[robert-hh]

@rodgerg Meanwhile I found the bug and could verify it and how to fix it (see https://github.com/pycom/pycom-micropython-sigfox/issues/119). I hope that Pycom will soon publish a fixed version.

[RodgerG]

@robert-hh thanks for prompt response. I couldn’t find uos, but os.uname()[2] returned ‘1.13.0.b1’, and as you quite rightly predicted, did not crash. BTW os.uname()[1] returned ‘LoPy4’.

[robert-hh]

@rodgerg I have my doubts about the version you actually loaded. Try to execute
uos.uname()[2]
That should tell you the version number and should not crash.

[RodgerG]

My LoPy4's arrived too:-)

But ...... I tried loading FW version 1.13.0.b1 on the device, and keep getting crashes and Core Dumps???

I am still using updater.py (rather than the new tool), so don't know if this could be contributing.

The LoPy 4 runs fine on LoPy_868-1.13.b.1.tar.gz (although it won't join to my LoRaWAN gateway).

However, the it crashes after loading LoPy4_868-1.13.b.1.tar.gz and trying a simple os.uname(). I tried downloading the firmware twice to make sure it wasn't corrupted.

Does anyone have any suggestions?

[g0hww]

For Linux, pycom_firmware_update_1.1.6.b0.tar.gz seems to be the latest updater utility available. I've been able to update both of my 1st gen LoPys to FW version 1.13.0b1 with it but the updater won't find either of the LoPy4s.
On the plus side, FW version 1.13.0b1 seems to have fixed a LoRa problem I was having with my 1st gen LoPys when fitted to an ExpBrd2 (the problem was not evident when they were fitted to a PyTrack).
More puzzling is that I couldn't update either of the 1st gen LoPys when fitted to the PyTrack board, even after updating the PyTrack to FW version 0.0.8.dfu.
I'd say the dust is still settling ;p

[robert-hh]

@ssmith Since this moring CET there is a version 1.13.0b1 already in the guthub repository.

[ssmith]

I was able to update mine to 1.12 with the latest update tool. My code wouldn't load on the 1.9FW, memory error. I don't think 1.9 used the extra memory.

[jmarcelino]

@g0hww
Please wait for the dust to settle, our manufacturing partners produced the boards faster than the firmware team could cope!

You'll be able to upgrade the firmware and get all the features very very soon.

Thank you for your patience.