Firmware release 1.7.1.b1

[daniel]

Hello,

A new firmware version 1.7.1.b1 has been released.

Here's the change log:

• Add support for LoRaWAN class C devices.

• Fix issue with Bluetooth client not using the correct connection id.

• Add support to select the RTC source clock.

  The options now are the internal 150KHz RC clock or an external 32KHz crystal.

• Add TX_FAILED_EVENT for LoRa

  Also, the TX_EVENT for confirmed packets is only raised when the
  acknowledge is received, otherwise the TX_FAILED_EVENT is raised.

• Allow to send packets with more than 64 bytes on raw LoRa.

• Register LoRa and Timer Alarm callback handlers with the GC root pointers.

• Remove all logs messages from the IDF sent to UART0.

• Add all IRQ handlers to the GC root pointers.

• Set the correct stack limit on the IRQ thread to (stack_size - 1024).

• Update to the latest IDF and add support for the 4MByte pSRAM on the OEM modules.

• Fix timer alarm memory allocation bug during initialisation.

All the sources have been pushed to the github repository as well: https://github.com/pycom/pycom-micropython-sigfox

Cheers,
Daniel

[livius]

@robert-hh
I see that in current 1.7.2 it is fixed - all calculations are cast to uint64 and also constants are with ull suffix
https://github.com/pycom/pycom-micropython-sigfox/commit/3284efccc8e4488a56c4cc93a494a58d6b348908

[robert-hh]

@livius I do not know the excat reason. I did not look it up in the source code yet. But it look like a overflow counter & signed/unsigned mismatch error.

[livius]

@robert-hh
I do not know but long under esp32 is 4 bytes? I suppose that yes.
because timeval fields are long
if yes than calculations like this in sources should be casted as unit64 before

 return mp_obj_new_int(((tv.tv_sec * 1000000) + tv.tv_usec)

[robert-hh]

@Frida @peekay123 I observed the same behaviour as @Frida . @peekay123, you have to let it run until 2146, if you read @Frida's comment properly. Then it should look like:

Time:  2141
Time:  2142
Time:  2143
Time:  2144
Time:  2145
Time:  2146
Time:  -140464758
Time:  -140464757
Time:  -140464756
Time:  -140464755
Time:  -140464754
Time:  -140464753

2146 times 1 million is a little bit less than 231, 2147 times 1 million is a little bit larger than 231 . So it looks as if there the overflow in a microseconds counter is not properly treated.

[peekay123]

@Frida, on firmware 1.7.1.b2, on a fresh reset, I get:

Time:  572
Time:  573
Time:  574
Time:  575
Time:  576
Time:  577
Time:  578
Time:  579
Time:  580
Time:  581
Time:  582
Time:  583
Time:  584
Time:  585

So it seems to be working. However, I have the same issue as @sthomson regarding the wifi connectivity. The LoPy doesn't think it's connected but I can connect to it via ftp. Also, ntp is not working as we all know.

[Frida]

import time

while 1:
    print("Time: ",time.time())
    time.sleep(1)

Why is the time going to count from 1 to 2146, and then the next nummer is
negative and it count's down to -140462611, and repeats it self over and over.

Time: 0 to
Time: 2146 then the next is
Time: -140464759 and down to
Time: -140462611 and then start over again
Time: 0
Time: 2146
Time: -140464758
Time: -140462611
Time: 0
Time: 2146
Time: -140464758
Time: -140462611
Time: 0

>>> os.uname()
(sysname='WiPy', nodename='WiPy', release='1.7.1.b1', version='v1.8.6-640-g585ac892 on 2017-06-02', machine='WiPy with ESP32')
>>> 

[sthomson]

@daniel I changed it to time.sleep(1) and I have the same issue. I also tried it with a couple of different wifi networks.

When I log onto my router, it actually sees the device as connected, it's just the LoPy that doesn't seem to realize it's connected.

Thanks.

[daniel]

@sthomson I just tried your script and everything seems to work normally. Does it change anything if you replace the machine.idle() line with time.sleep(1) ?

[sthomson]

Hi,
I have used the updater tool to flash 1.7.1.b2 to my LoPy board. I am running the following:

wlan = network.WLAN(mode=network.WLAN.STA)
wlan.connect(ap.ssid, (ap.sec, mypassword))
    while not wlan.isconnected():
        machine.idle() # save power while waiting

This was working without problems with the previous firmware (1.6.7.something), but now it is stuck in the machine.idle() loop and never seems to connect. Is this related to one of the bugs discussed here?

[this.wiederkehr]

Thanks @daniel for letting me know. Is this behavior documented somewhere. It's not basically what I would expect ;-)

Here is a script to reproduce the crash. I could reproduce the crash on address 0x40087eb9 with it. Though, it does not trigger on the first instance but you might have to run it for several minutes till the exception occurs. I'll try further and see if it also triggers the other exceptions I got...

import machine
import os
import utime

sd = machine.SD()
os.mount(sd, '/sd')

f = open('/sd/test', 'a')
t1 = utime.ticks_ms()
while True:

    print('about to initialize buffer')
    k = bytearray(1024)
    print('about to write to file')
    f.write(k)
    print('about to flush to file')
    f.flush()
    t2 = utime.ticks_ms()
    print("I'm done %i"%(t2-t1))
    t1 = t2

Update: Yes, this also triggers the other exception at address 0x400875b9.
Update2: It also reproduces the freeze or at least I can see a slow down of the python interpreter by factors. I just see cycle times which are usually in the range of 10 - 500 ms (500 most likely during gc) going up to ~20000 or even 30000.

Let me know if you can reproduce those issues...

[peekay123]

@daniel, rtc.local() worked fine before. However, I'll use time.localtime() in the future.

[daniel]

@peekay123 I guess that you mean: time.localtime() this is related to the same ntp sync issue which has already been solved internally. Thanks.

[Innocenzo]

@daniel I've found some other bugs in this release:

• the disconnect() function of the Bluetooth class does not work!

bt = Bluetooth()
conn = bt.connect(b'\x00\x15\x83\x00\x4A\x67')
services = conn.services()
for service in services:
    time.sleep(0.050)
    if type(service.uuid()) == bytes:
        print('Reading chars from service = {}'.format(service.uuid()))
    else:
        print('Reading chars from service = %x' % service.uuid())
    chars = service.characteristics()
    for char in chars:
        if (char.properties() & Bluetooth.PROP_READ):
            print('char {} value = {}'.format(char.uuid(), char.read()))
conn.disconnect()

the WiPy returns in REPL, but the BLE peripheral does not detect the disconnect (the peripheral remains cennected to WiPy and cannot be detected by other devices).

• The ssl socket server side causes a core dump or throws an exception!

newsocket, fromaddr = bindsocket.accept()
connstream = ssl.wrap_socket(newsocket,server_side=True, certfile='/flash/cert/cert.pem', keyfile='/flash/cert/key.pem')

[peekay123]

When I ran the Firmware Udpater last night, it installed 1.7.1.b2 (on LoPy) which still has the ntp_sync issue. I also noticed that rtc.local(), which worked on 1.6.7.b1, no longer works on 1.7.1.b2. The following no longer runs (from my boot.py file):

# We are here because wifi connected so set the RTC time
from machine import RTC

rtc = machine.RTC()
rtc.ntp_sync("pool.ntp.org")
utime.sleep_ms(750)
time.timezone(-14400)
print(rtc.local())

[daniel]

@rdixey no, that fix is not out yet. The release will be out tomorrow together with other fixes and new features (like the WDT).

[rdixey]

@daniel Does the current updater tool for release LoPy_868-1.7.1.b2.tar.gz incorporate the fix for the ntp_sync issue?

I want to be sure before installing the update. Please confirm.

[daniel]

@this-wiederkehr this:

import machine
import os

sd = machine.SD()
os.mount(sd, '/sd')

f = open('/sd/test', 'a')

while True:
    f.write('blabla')
    print('about to disable irq')
    machine.disable_irq()
    print('about to flush to file')
    f.flush() # <-- freezes reproducible at that call
    print('about to enable irq')
    machine.enable_irq()
    print("I'm done")

is expected to freeze as the SD card uses interrupts. If you disable them before flushing the SD card driver stays waiting for the operation to finish, which never happens as the interrupt doesn't trigger.

Still working on the other crash...

Cheers,
Daniel

[Innocenzo]

@robert-hh I check it. Now It works.

[daniel]

@this.wiederkehr we are investigating this now.