1. Home
  2. Announcements & News
  3. New firmware release 1.6.9.b1 (frozen code support and framebuf)

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

New firmware release 1.6.9.b1 (frozen code support and framebuf)

  • D

    Hello,

    We have just released a new firmware version (1.6.9.b1). Here's the change log:

    As usual, the update can be applied via the tool that is available here:
    https://www.pycom.io/resources/

    We have released new sources up to date with support for the SiPy: https://github.com/pycom/pycom-micropython-sigfox

    There's no history in order to avoid making the closed source files from Sigfox public. Since Espressif merged yesterday (https://github.com/espressif/esp-idf/pull/444) the changes that we needed in order to move forward with the steps to merge our code with the official MicroPython repository, we will go full throttle on that next week.

    Cheers,
    Daniel

    4 B R A 3 Replies
  • robert-hh

    @Butch See this link about downgrade: https://forum.pycom.io/topic/517/downgrading-firmware-advanced-users
    V1.6.8b2 links are canonically derived according to the list:
    https://software.pycom.io/downloads/LoPy_868-1.6.8.b2.tar.gz or
    https://software.pycom.io/downloads/LoPy_915-1.6.8.b2.tar.gz or
    https://software.pycom.io/downloads/WiPy-1.6.8.b1.tar.gz

    0
  • B

    @daniel said in New firmware release 1.6.9.b1 (frozen code support and framebuf):

    @Butch, this firmware release is pretty much the same as before 1.6.8.b2 only that it adds 8KB of extra heap. Can you try a safe boot, format the file system of the problematic LoPy and put the scripts back again after a normal reset?

    Is it possible to revert to the earlier version? This version seems to be not very useful right now, and I need to get back to making progress. I'd really like to go back to 1.6.8b2.

    Thanks!

    0 robert-hh 1 Reply
  • S

    @daniel Thanks, that corrected the behavior. All previous revisions had this disabled by default. Why the change?
    O wait, I see the answer existed before my question in your post below. :-)

    This revision still keeps freezing solid after some time though.
    I hope you can find the issue before the new release tomorrow.

    0
  • D

    Hi @shaun you can override that by putting this inside your boot.py:

    import os
os.dupterm(None)

    Let me know if that's OK in your case.

    The idea behind the new behaviour is to make the UART REPL accessible during safe boot.

    0 S 1 Reply
  • S

    @daniel
    Evening Daniel.
    I would also like to report that this revision is sending all REPL text to UART0 as well, even though I have not configured it this way in my boot.py file. I have always been using UART 0 for my application and using Telnet over WiFi for my REPL interface.

    0
  • N

    @daniel Missing branch 'github' in the URL for Frozen code. Should probably be 'master'

    https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/README.md

    0
  • jmarcelino

    @arneme
    I happen to have a Polar H7 HR monitor and can confirm that the connection gets dropped almost immediately after establishing, there's no chance to retrieve services so the code terminates with a 'connection already closed'

    I don't have my BLE sniffer setup at the moment but did a quick trace of a typical connection using another BLE tool (http://pastebin.com/HwDsWffG) and can see the H7 may expect some features the LoPy isn't ready for yet. If the H7 gets anything it doesn't expect (like a rejection for it's request to update connection parameters) it simply drops the connection - that may be what's happening.

    If you have a BLE sniffer you may be able to see it. I'll try to return to this when I get some time. I suspect once BLE supports pairing this would also resolve itself, but that may be further out.

    0
  • R

    @jmarcelino Interesting! Using P21 for SCL does work, and I2C Init does assign P21 with alt=-1. P9 still gets assigned with alt=198 but works okay for SDA. After I install Daniels next update I'll revert back to using P8 for SCL to see if it works again.
    Thanks for the advice!

    >>> i2c = I2C(0, I2C.MASTER, baudrate=400000, pins=("P9", "P21"))
>>> i2c.scan()
[96, 112]
>>> Pin.exp_board.G8
Pin('P21', mode=Pin.OPEN_DRAIN, pull=Pin.PULL_UP, alt=-1)
>>> Pin.exp_board.G16
Pin('P9', mode=Pin.OPEN_DRAIN, pull=Pin.PULL_UP, alt=198)
>>> Pin.exp_board.G15
Pin('P8', mode=Pin.OPEN_DRAIN, pull=Pin.PULL_UP, alt=198)
>>> 
Running SI1145.py  <<----- I2C UV Light Sensor 
memfree 39392
Vis: 263
IR: 287
Prox: 256
UV: 3
UVIndex: 0.03
memfree 39072
    0
  • A

    @jmarcelino My bad, the bytes are all there when printing like this:
    print("Try to connect to the H7 with mac:", binascii.hexlify(bytes(adv.mac)))

    Still not able to connect though.

    0 jmarcelino 1 Reply
  • jmarcelino

    @arneme
    Can you post an example of your print() result please?

    For example I get:

    MAC: b'\x14X\x02\x00\x00\xa9'
    MAC: b'gFb\xd0\xc1\xf5'
    MAC: b'\x14X\x00\x03\x01k'
    MAC: b"\xc2f\xf7'\xec\xc0"

    all 6 bytes long, though difficult to read because print only shows hex for non-printable characters.

    0 A 1 Reply
  • A

    @daniel While trying to do some rudimentary testing of the Bluetooth functionality in version 1.6.9.b1 I noticed something strange. The adv.mac seems to be incomplete (i.e. in the print("Try to connect to the H7 with mac:", adv.mac) line only a few of the bytes in the mac is printed out) and thus I am not able to connect to discovered peripherals.

    from network import Bluetooth
import time
bt = Bluetooth()
bt.start_scan(-1)

# Code to connect to Polar H7 Bluetooth heartrate sensor
# The detected Heartrate is "published" over the LoRaWAN network

while True:
    adv = bt.get_adv()
    if adv:
        name = bt.resolve_adv_data(adv.data, Bluetooth.ADV_NAME_CMPL)
        if name is not None:
            if name.startswith("Polar H7"):
                print ("Found: " + name)
                bt.stop_scan()
                
                try:
                    print("Try to connect to the H7 with mac:", adv.mac)
                    conn = bt.connect(adv.mac)
                    print("Connected...")
                    services = conn.services()
                    print("Got services...")
                    for service in services:
                        time.sleep(0.05)
                        # According to specification from Polar, service.uuid = 0x180D is Heart Rate and char.uuid = 2a37 is value in beats per minutes
                        if service.uuid() == 0x180D:
                            print('Reading from service %x' % service.uuid())
                            chars = service.characteristics()
                            print("Print chars found")
                            for char in chars:
                                print('char %x' % char.uuid())
                except Exception as ex:
                    print("Exception caught...")
                    print(ex)
    0 jmarcelino 1 Reply
  • livius

    Now i2c work for me back in 1.6.9 :)

    0
  • D

    Here's the fix: https://github.com/pycom/pycom-micropython-sigfox/commit/195813d432d9f41314ef9923104b21db1282edf8

    0 S 1 Reply
  • D

    Guys, I found the bug, I'll push to github and we'll release again tomorrow.

    1
  • D

    @jmarcelino and @rdixey thanks for the investigation. We'll check what's the problem with pins P8 and P9 here.

    Alt=198 doesn't look correct at all.

    Cheers,
    Daniel

    0
  • jmarcelino

    @rdixey
    The problem seems to be reassigning SCL to P8. Maybe something related to SD cards changed as P8 is also used there.

    Other pins I tried - the default P10, P21 or P11- work so try changing it to another pin if you can.

    Other than that I2C is working fine, I have it extensively driving a Si4703.

    0 R 1 Reply
  • R

    @daniel I2C Bus finds no device address after update to 1.6.9.b1. All of my code had run fine under 1.6.7.b1 but after this update I get I2C Bus Error from my scripts.
    I found that i2c.scan() finds no addresses. I notice that the I2C Init defines the SDA & SCL pins with alt=198 but in prior releases it was alt=-1. I don't know what the alt values mean or if it is the cause of my problem?

    >>> os.uname()
(sysname='LoPy', nodename='LoPy', release='1.6.9.b1', version='v1.8.6-536-gb84c3837 on 2017-03-24', machine='LoPy with ESP32', lorawan='1.0.0')
>>>
>>> i2c = I2C(0, I2C.MASTER, baudrate=100000, pins=("P9", "P8"))
>>> i2c.scan()
[]
>>> i2c.scan()
[]
>>> i2c.scan()
[]
>>> Pin.exp_board.G15
Pin('P8', mode=Pin.OPEN_DRAIN, pull=Pin.PULL_UP, alt=198)
>>> Pin.exp_board.G16
Pin('P9', mode=Pin.OPEN_DRAIN, pull=Pin.PULL_UP, alt=198)
>>>

    To troubleshoot this:

    1. Rechecked all of my jumper connections. - No Resolution
    2. Formatted the file system - No Resolution
    3. Downgraded to firmware version 1.6.0.b1. - I2C worked flawlessly again.
    4. Updated again to firmware version (1.6.9.b1). - No I2C devices found on I2C bus same as first time.

    Now I suspect there is a change in the new firmware causing the problem.

    What should I do next?

    0 jmarcelino 1 Reply
  • D

    @Shaun OK thanks for the info, we'll investigate.

    0
  • S

    @daniel
    This revision is broken for me as well.
    If I leave my application running for some time, with Telnet connected with a 36 hour time out, and come back in an hour or 2, the Telnet terminal has disconnected on the 1st occasion and on the 2nd occasion the WiPy2 had frozen solid and required a hard reset.

    0
firmware 175
Log in to reply
 

Pycom on Twitter