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

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

[Butch]

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

[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