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

Butch

@daniel I updated my firmware yesterday afternoon to 1.6.8b2 (I think), and that solved my LoRa problem and all was good. This morning, I updated to 1.6.9b1 and I can not longer run the code:

$ pyboard --device /dev/cu.usbserial-DO003AJF --baudrate 115200 LoRaNanoGateway.py
b'\r\n>>> \r\n>>> \r\n>>> '
could not enter raw repl

It seems like something has gone awry with talking to a "friendly" or "raw" repl.

Suggestions?

Thanks!

Butch

Following up on my on reply, here's some additional information. If I connect to the LoPy and boot, here's what I see:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:QIO, clock div:2
load:0x3fff9010,len:8
load:0x3fff9018,len:248
load:0x40078000,len:4056
load:0x4009fc00,len:920
entry 0x4009fde4
I (1558) wifi: wifi firmware version: 90b1b8b
I (1558) wifi: config NVS flash: disabled
I (1559) wifi: config nano formating: disabled
I (1574) wifi: Init dynamic tx buffer num: 32
I (1574) wifi: wifi driver task: 3ffbd6b8, prio:23, stack:3584
I (1575) wifi: Init static rx buffer num: 10
I (1577) wifi: Init dynamic rx buffer num: 0
I (1581) wifi: Init rx ampdu len mblock:7

I (1584) wifi: Init lldesc rx ampdu entry mblock:4
I (1589) wifi: wifi power manager task: 0x3ffda798 prio: 21 stack: 2560
I (1595) wifi: sleep disable
I (1559) wifi: config nano formating: disabled
I (1574) wifi: Init dynamic tx buffer num: 32
I (1574) wifi: wifi driver task: 3ffbd6b8, prio:23, stack:3584
I (1575) wifi: Init static rx buffer num: 10
I (1577) wifi: Init dynamic rx buffer num: 0
I (1581) wifi: Init rx ampdu len mblock:7
I (1584) wifi: Init lldesc rx ampdu entry mblock:4
I (1589) wifi: wifi power manager task: 0x3ffda798 prio: 21 stack: 2560
I (1595) wifi: sleep disable
I (2584) wifi: wifi timer task: 3ffdb82c, prio:22, stack:3584
I (2606) wifi: Init ampdu: 0
I (2606) wifi: mode : softAP (24:0a:c4:00:b8:d1)
I (2686) wifi: Init ampdu: 0
I (2686) wifi: mode : sta (24:0a:c4:00:b8:d0)
I (2687) wifi: sleep disable
I (5771) wifi: n:6 0, o:6 0, ap:255 255, sta:6 0, prof:6
I (6758) wifi: state: init -> auth (b0)
I (6760) wifi: state: auth -> assoc (0)
I (6765) wifi: state: assoc -> run (10)
I (6776) wifi: connected with TP-LINK_4379, channel 6
I (16766) wifi: pm start, type:0

And then it just hangs there. This is the LoPy previously configured with LoRa Nano gateway code.

The other LoPy, previously configured with LoRa Nano node code and updated to the same firmware version as the gateway, shows the following output on boot:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:QIO, clock div:2
load:0x3fff9010,len:8
load:0x3fff9018,len:248
load:0x40078000,len:4056
load:0x4009fc00,len:920
entry 0x4009fde4
I (1570) wifi: wifi firmware version: 90b1b8b
I (1570) wifi: config NVS flash: disabled
I (1570) wifi: config nano formating: disabled
I (1586) wifi: Init dynamic tx buffer num: 32
I (1586) wifi: wifi driver task: 3ffbd6b8, prio:23, stack:3584
I (1586) wifi: Init static rx buffer num: 10
I (1588) wifi: Init dynamic rx buffer num: 0
I (1592) wifi: Init rx ampdu len mblock:7
I (1596) wifi: Init lldesc rx ampdu entry mblock:4
I (1601) wifi: wifi power manager task: 0x3ffda798 prio: 21 stack: 2560
I (1607) wifi: sleep disable
I (2596) wifi: wifi timer task: 3ffdb82c, prio:22, stack:3584
I (2617) wifi: Init ampdu: 0
I (2617) wifi: mode : softAP (24:0a:c4:00:b7:47)
MicroPython v1.8.6-536-gb84c3837 on 2017-03-24; LoPy with ESP32
Type "help()" for more information.
>>> 
>>> import os; 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')

As you can see, I get a repl and can verify the version of firmware installed.

Any ideas?

Thanks!

robert-hh

Hi @daniel , it looks like you are juggling with too many versions. The one that compiles at the end from the pycom-micropython-sigfox repository is 1.6.8.b1, however with frozen code support and framebuf).

>>> uos.uname()
(sysname='LoPy', nodename='LoPy', release='1.6.8.b1', version='b8220c0-dirty on 2017-03-24', machine='LoPy with ESP32', lorawan='1.0.0')

And I could see that adding the line:
#define MICROPY_PERSISTENT_CODE_LOAD (1)
indeed enables executing .mpy files from the file system.

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

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