1. Home
  2. Announcements & News
  3. New release New firmware release 1.2.2.b1

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

New release New firmware release 1.2.2.b1

  • D

    Hello everyone,

    Here we are with an early week release that improves the interrupt functionality and fixes some bugs that were present in the previous release. These are the release notes:

    • When a thread dies remove it from the linked list. Also release the memory it had allocated. Fixes #39 (https://github.com/pycom/pycom-micropython/issues/39)

    • Kill the interrupts tasks during a soft reset.

    • Enable the finalizer for Alarms.

    • Release the GIL before blocking

    • Test for possible handler=None in queued callbacks.

    • Move functions called by ISRs to RAM to fix gurus on Alarms and Pins.

    • Pass the correct stack size when creating threads.

    • Correct pins P13 and P14 that were inverted.

    As usual, the new firmware can be flashed using the updater tool found in: https://www.pycom.io/support/supportdownloads/

    Cheers,
    Daniel

    1 F 1 Reply
  • M

    @minkley
    Still struggling to get the firmware upgrade to work on linux.

    Note, I'm not using an expansion card but a Serial USB cable which powers the device up and allows me to connect to the wifi
    I'm also able to connect to the serial port with minicom and I get the following python version:

    >>> print(sys.version)
3.4.0
>>>

    When I try and update the firmware I get the following error.

    Namespace(file=None, port='/dev/ttyUSB0', speed=115200, tar='/tmp/tmp.zR12S6HK0s/update.tar.gz')
Connecting...
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 115200
Changed.
Exception: empty file, on line 131

    This what I am doing exactly:

    As root Downloaded and extracted pycom_update_1.0.0.b3.tar.gz

    • cd into pyupgrade

    • run ./update

    • select WiPy 2.0

    • Disconnect device from USB

    • Put G23 into GND

    • Plug in USB cable

    • Press and hold the the reset button for about 3 seconds

    • Press enter on the update

    • Type in the serial path :-> /dev/ttyUSB0

    • Deselect high speed

    Then it fails with the "Exception: empty file on line 131.

    Just to be sure my EMS32 connectivity is good, whilst connected via minicom, if I plug in G23 to GND hit reset, I see the device is waiting for a download

    >>> ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

    Perhaps someone can point me to the firmware file and a command line script I can use to test the install. I really would like to complete the upgrade and get on with using the device :)

    0
  • F

    @iber Thanks Iber. I thought I was losing it. I Just went threw the trouble of putting the nodes 100 meters apart. Still no luck. Does your nanogateway also crash? putting in a little wait between receiving and sending the ACK message fixed this for me. Still the code shouldn't be crashing. @daniel Is this bug going to be fixed in the upcomming update?

    0
  • iber

    I have to stand corrected, now that I'm running 1.2.2.b1 I can't get it working either...

    0 F 1 Reply
  • bmarkus

    @iber said in New release New firmware release 1.2.2.b1:

    For me, the example code runs fine.
    Although, I have noticed that your LoPy shouldn't be to close to eachother.
    Maybe the long LORA wave has something to do with it?

    Personal experience is with LoRa devices and gateways that it is easy to override receiver if they are very closed to each other equipped with antenna. In this case you exeperince a high packet error rate, lost packets.

    Place them in few meter distance and disconnect antenna. It will not damage your chip but if you afraid use a dummy load or an attenuator between LoPy and antenna,

    0
  • iber

    For me, the example code runs fine.
    Although, I have noticed that your LoPy shouldn't be to close to eachother.
    Maybe the long LORA wave has something to do with it?

    0 bmarkus 1 Reply
  • F

    In attempt to fix the NanoGateway code I tried locating the problem.
    I used the next client code:

    import os
import socket
import time
import struct
from network import LoRa

# A basic package header, B: 1 byte for the deviceId, B: 1 bytes for the pkg size
_LORA_PKG_FORMAT = "BB%ds"
_LORA_PKG_ACK_FORMAT = "BBB"
DEVICE_ID = 0x00


# Open a Lora Socket, use tx_iq to avoid listening to our own messages
lora = LoRa(mode=LoRa.LORA, tx_iq=True)
lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
lora_sock.setblocking(False)

while(True):
    DEVICE_ID += 1
    # Package send containing a simple string
    msg = "Device %d Here" %DEVICE_ID
    pkg = struct.pack(_LORA_PKG_FORMAT % len(msg), DEVICE_ID, len(msg), msg)
    print("send message %s" % msg)
    lora_sock.send(pkg)

    # Wait for the response from the gateway. NOTE: For this demo the device does an infinite loop for while waiting the response. Introduce a max_time_waiting for you application
    waiting_ack = True
    timeout = time.time() + 20
    while(waiting_ack and timeout > time.time()):
        recv_ack = lora_sock.recv(256)

        if (len(recv_ack) > 0):
            device_id, pkg_len, ack = struct.unpack(_LORA_PKG_ACK_FORMAT, recv_ack)
           # if (device_id == DEVICE_ID):
            if (ack == 200):
                waiting_ack = False
                # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                if (device_id == DEVICE_ID):
                    print("ACK")
                else:
                    print("Ack with wrong device_id: %d" %device_id)
            else:
                waiting_ack = False
                # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                print("Message Failed")
    
    if waiting_ack:
        print('no ACK received')
        
    time.sleep(5)

    This gives the next Console output:

    Running node.py
Soft resetting the LoPy
send message Device 1 Here
no ACK received
send message Device 2 Here
no ACK received
send message Device 3 Here
no ACK received
send message Device 4 Here
Ack with wrong device_id: 1
send message Device 5 Here
Ack with wrong device_id: 2
send message Device 6 Here
no ACK received
send message Device 7 Here
no ACK received

    Using the code nanogateway code from the tutorial found here gives the next console output:

    Running nano_gateway.py
Soft resetting the LoPy
Device: 1 - Pkg:  b'Device 1 Here'
Device: 2 - Pkg:  b'Device 2 Here'
Device: 3 - Pkg:  b'Device 3 Here'
Traceback (most recent call last):
  File "<stdin>", line 28, in <module>
OSError: [Errno 11] EAGAIN

    The package is received on the gateway side after the timeout is reached on the client side. Also the Ack for device 1 is received after the Gateway crashed.
    Also after stopping the client and soft resetting then restarting the Gateway. There are still messages received:

    Running nano_gateway.py
Soft resetting the LoPy
Device: 4 - Pkg:  b'Device 4 Here'
Device: 5 - Pkg:  b'Device 5 Here'
Traceback (most recent call last):
  File "<stdin>", line 28, in <module>
OSError: [Errno 11] EAGAIN

    The receive buffer doesn't seemed to be reset with a soft reset. The sending of the ACK package from the server results in the OsError. After removing the

    lora_sock.send(ack_pkg)

    the gateway runs finds, however no Ack package is send.

    Of course I used the latest firmware 1.2.2.b1. Can someone confirm my findings? I hope the problem can be fixed. I really need this code to run for a project.

    0
  • F

    Of course I used

        while(waiting_ack and timeout > time.time()):
        recv_ack = lora_sock.recv(256)

    On the NanoGateway side the package is received after timeout = time.time() + 20 is reached.

    0
  • F

    @daniel Here's my code. It's the same as in the example I added a timeout.

    import os
import socket
import time
import struct
from network import LoRa

# A basic package header, B: 1 byte for the deviceId, B: 1 bytes for the pkg size
_LORA_PKG_FORMAT = "BB%ds"
_LORA_PKG_ACK_FORMAT = "BBB"
DEVICE_ID = 0x01


# Open a Lora Socket, use tx_iq to avoid listening to our own messages
lora = LoRa(mode=LoRa.LORA, tx_iq=True)
lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
lora_sock.setblocking(False)

while(True):
    # Package send containing a simple string
    msg = "Device 1 Here"
    pkg = struct.pack(_LORA_PKG_FORMAT % len(msg), DEVICE_ID, len(msg), msg)
    lora_sock.send(pkg)
    
    # Wait for the response from the gateway. NOTE: For this demo the device does an infinite loop for while waiting the response. Introduce a max_time_waiting for you application
    waiting_ack = True
    timeout = time.time() +20
    while(waiting_ack and timeout < time.time()):
        recv_ack = lora_sock.recv(256)
    
        if (len(recv_ack) > 0):
            device_id, pkg_len, ack = struct.unpack(_LORA_PKG_ACK_FORMAT, recv_ack)
            if (device_id == DEVICE_ID):
                if (ack == 200):
                    waiting_ack = False
                    # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                    print("ACK")
                else:
                    waiting_ack = False
                    # If the uart = machine.UART(0, 115200) and os.dupterm(uart) are set in the boot.py this print should appear in the serial port
                    print("Message Failed")

    time.sleep(5)

    The socket is not blocking.

    0 F 1 Reply
  • D

    @Feiko have you by chance made the socket blocking?

    lora_sock.setblocking(True)
    0 F 1 Reply
  • F

    Nano Gateway example doesn't work anymore https://forum.pycom.io/post/1210

    It seems that calling lora_sock.recv(256) after lora_sock.send(pkg) is blocking the lora_sock.send function. The package is only send after the receive function is timed out. This kind of defeats the purpose of sending an ACK package. Does anyone have a solution?

    Keep up the good work!

    0 D 1 Reply
  • D

    @minkley have a look here: https://www.pycom.io/wp-content/uploads/2016/11/wipy_pinout.pdf

    You should connect 5V from the USB and GND. You also need to connect Rx and Tx on the program port. Don't forget to wire P2 to GND and reset to enter flashing mode as instructed by the updater tool.

    Cheers,
    Daniel

    0
  • M

    @daniel
    Thanks Daniel
    I installed pyserial it's getting past that now but failing with the following message

    Namespace(file=None, port='/dev/ttyUSB0', speed=115200, tar='/tmp/tmp.nBBvLQ6mbC/update.tar.gz')
    Connecting...
    Exception: Failed to connect to ESP32: Timed out waiting for packet header, on line 121
    root@pecan:/home/mink/pyupgrade#

    So I guess the ESP32 is not live , perhaps you clarify something for about the firmware upgrade process. As I don't have an expansion but am using a USB serial cable, where does wipy2 get it's power from?

    As an FYI, I'm using the same USB serial cable I connect to various other devices eg my CubieTruck3, so I know it works

    Any guidance would be appreciated.

    thanks

    0 M 1 Reply
  • D

    Ok, it looks like only the Windows and OS X updater tools come with pyserial bundled. Please install pyserial manually and run the updater again:

    http://pyserial.readthedocs.io/en/latest/pyserial.html#installation

    We will add this to the docs. Thanks.

    Cheers,
    Daniel

    0
  • M

    Traceback (most recent call last):
    File "./bin/updater.py", line 3, in <module>
    from esptool import ESP32ROM
    File "/home/mink/pyupgrade/bin/esptool.py", line 25, in <module>
    import serial
    ImportError: No module named serial

    0
  • D

    @minkley the updater now connects to the internet every time to get the latest files. Normally the updater prints an error message with the reason of the failure. Could you try again and copy paste the message here? Thanks.

    0 M 1 Reply
  • M

    I think the latest firmware for Linux is borked :) It's my first hands-on with the wipy2 and the upater failed. Digging around I noticed there are no firmware files in the tgz.

    There is no firmware directory as per the previous v 0.9.7.. version. I used this link https://software.pycom.io/findupgrade?product=pycom-firmware-updater&type=all&platform=unix&redirect=true

    Here are the extracts so you can see what I am talking about.

    tar -tvzf pycom_update_1.0.0.b2.tar.gz
    -rw-r--r-- abiliojr/staff 247 2016-12-17 04:17 pyupgrade/README
    drwxr-xr-x abiliojr/staff 0 2016-12-19 12:38 pyupgrade/bin/
    -rw-r--r-- abiliojr/staff 0 2016-12-17 04:17 pyupgrade/bin/init.py
    -rw-r--r-- abiliojr/staff 92013 2016-12-17 04:17 pyupgrade/bin/esptool.py
    -rwxr-xr-x abiliojr/staff 4046 2016-12-17 04:17 pyupgrade/bin/updater.py
    -rw-r--r-- abiliojr/staff 22135 2016-12-17 04:17 pyupgrade/lopyupdate.py
    -rw-r--r-- abiliojr/staff 44124 2016-12-17 04:17 pyupgrade/spinner.gif
    -rwxr-xr-x abiliojr/staff 7316 2016-12-19 19:14 pyupgrade/update

    tar -tvzf pycom_update_0.9.7.b1.tar.gz
    drwxr-xr-x abiliojr/staff 0 2016-11-26 08:44 pyupgrade/bin/
    -rw-r--r-- abiliojr/staff 0 2016-10-27 20:13 pyupgrade/bin/init.py
    -rw-r--r-- abiliojr/staff 92032 2016-11-26 08:19 pyupgrade/bin/esptool.py
    -rwxr-xr-x abiliojr/staff 2408 2016-11-26 08:44 pyupgrade/bin/updater.py
    -rwxr-xr-x abiliojr/staff 210 2016-12-03 05:12 pyupgrade/._firmware
    drwxr-xr-x abiliojr/staff 0 2016-12-03 05:12 pyupgrade/firmware/
    -rw-r--r-- abiliojr/staff 210 2016-12-03 04:31 pyupgrade/firmware/._bootloader.bin
    -rw-r--r-- abiliojr/staff 5520 2016-12-03 04:31 pyupgrade/firmware/bootloader.bin
    -rw-r--r-- abiliojr/staff 210 2016-12-03 04:44 pyupgrade/firmware/._lopy_0.9.7.b1_868.bin
    -rw-r--r-- abiliojr/staff 828448 2016-12-03 04:44 pyupgrade/firmware/lopy_0.9.7.b1_868.bin
    -rw-r--r-- abiliojr/staff 210 2016-12-03 04:43 pyupgrade/firmware/._lopy_0.9.7.b1_915.bin
    -rw-r--r-- abiliojr/staff 828272 2016-12-03 04:43 pyupgrade/firmware/lopy_0.9.7.b1_915.bin
    -rw-r--r-- abiliojr/staff 210 2016-12-03 04:32 pyupgrade/firmware/._partitions.bin
    -rw-r--r-- abiliojr/staff 3072 2016-12-03 04:32 pyupgrade/firmware/partitions.bin
    -rw-r--r-- abiliojr/staff 210 2016-12-03 04:46 pyupgrade/firmware/._wipy_0.9.7.b1.bin
    -rw-r--r-- abiliojr/staff 820400 2016-12-03 04:46 pyupgrade/firmware/wipy_0.9.7.b1.bin
    -rw-r--r-- abiliojr/staff 14383 2016-11-26 08:43 pyupgrade/lopyupdate.py
    -rwxr-xr-x abiliojr/staff 5765 2016-11-06 03:32 pyupgrade/update

    Or am I mistaken :)

    Thanks guys

    0 D 1 Reply
  • D

    @livius haha :-)

    0
  • livius

    @daniel
    sorry for spam but good date "Friday 13" :)

    0 D 1 Reply
  • D

    @mohpor the release is going to be out tomorrow (Friday 13), we still need one more day to complete all the features that we are targeting for this next release. Apologies for the delay...

    Cheers,
    Daniel

    0 livius 1 Reply
Log in to reply
 

Pycom on Twitter