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

[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