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

daniel

@robert-hh thanks, the problem when checking out was due to the default branch not being master. I have just fixed that and also pushed the commit that bumps the firmware version to 1.6.9.b1.

daniel

@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?

robert-hh

@daniel Thanks, it works.

Shaun

@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.

daniel

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

rdixey

@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:

Rechecked all of my jumper connections. - No Resolution
Formatted the file system - No Resolution
Downgraded to firmware version 1.6.0.b1. - I2C worked flawlessly again.
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?

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.

daniel

@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

daniel

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

daniel

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

livius

Now i2c work for me back in 1.6.9 :)

arneme

@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)

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.

arneme

@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.

rdixey

@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

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.

nevercast

@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

Shaun

@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.

daniel

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.

Shaun

@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.

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

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

Pycom on Twitter