New firmware release version v1.8.0.b1

[daniel]

A new firmware release is out. The version is v1.8.0.b1. The github sources have been updated as well. Here's the change log:

• esp32: PWM refactoring, added init method. Corrected 100% duty cycle behaviour.
• esp32: Fix memory leakage caused by the callback handlers. Thanks to @robert-hh for his contributions here.
• esp32: Move the LoRa time callback handler to IRAM.
• esp32: Re-implement the timer alarm_heap management to make it simpler and more robust.
• esp32: Enable persisten code load. Thanks to @robert-hh.
• esp32: Fix bug when setting the NTP server name to None.
• lib/lora: Increase symbol timeouts to avoid lost downlinks on the 2nd Rx Window.
• esp32: Define maximum LoRaWAN join data rates.
• esp32: Allow machpwm to work with frequencies up to 78KHz.
• esp32: recvfrom() with LoRa sockets return port 0 when no data received.

Cheers,
Daniel

[rdixey]

@rdixey When placing the jumper for the update I was disconnecting the USB but forgetting to disconnect the battery. Sometimes I do silly things :-). But after I realized this I have updated both of my LoPy's.

[robert-hh]

@betterauto It allows executing pre-compiled Python files from the file system. The files will be pre-compiled on your PC with mpy-cross, creating .mpy files (bytecode), copied to you xxPy and then imported as usual. No RAM is needed for compiling, allowing larger scripts. This is an intermediate step between Python source scripts and embedded bytecode.

[BetterAuto]

@daniel said in New firmware release version v1.8.0.b1:

esp32: Enable persisten code load. Thanks to @robert-hh.

What's that do, @robert-hh ?

[mgranberry]

I'm experiencing a lot of missed downlinks/acks on RX1 for a USA device. RX2 works almost every time. It seems to have worked better before this update. In raw mode the device receives them every time, so I suspect it is a timing issue.

[marek]

@daniel I can replicate the issue that @rdixey reported.

celine% cat /etc/lsb-release|grep DESC
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
celine% whoami
marek
celine% egrep dialout /etc/group
dialout:x:20:marek,root
celine% ls -lh /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Sep 9 10:22 /dev/ttyUSB0

celine% ./update # running the update (as a user who is in the required dialout group) throws the error "Connecting to the device to get it's information, please wait. Something failed trying to connect to the device."

celine% sudo ./update # running the update using sudo (, or root) works fine

[robert-hh]

@virtualguy There's still the Ctrl-C issue pending, in that Ctrl-C does not raise an KeyboardInterrupt immediately. This happens eventually after the next char, or in case if input() not before the next 'enter'.
See the old bug: https://github.com/pycom/pycom-micropython/issues/49

[virtualguy]

Is your device sitting idle with a REPL prompt? If you have a script running with long sleeps the ctrl-c the updater sends may not stop your executing code. Just a theory...

[daniel]

We haven't changed anything in the updater tool for this release. Is anyone else having similar issues like @rdixey ?

[rdixey]

I deleted all previous versions of the Update Tool from my Ubuntu 16.04 system. Then downloaded the New Firmware Update tool v1.8.0.b1 from pycom.io Pycom upgrader Linux link.
When I run it on my Ubuntu sys I get the messages:

"Connecting to the device to get it's information, please wait."
"Something failed trying to connect to the device."

I had the same problem with the prior Linux Updater 1.1.2.b1 and Daniel identified that it was caused because of the slow baudrate (38400) used before for the initial connection with the board. Increasing it to 57600 fixed it.

Is there a similar issue with the v1.8.0.b1 Update Tool?