Firmware release 1.7.1.b1



  • 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



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



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



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


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



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



  • 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')
    >>> 
    


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



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



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



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



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



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



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


  • 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())
    


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



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



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



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



  • @this.wiederkehr we are investigating this now.


Log in to reply
 

Pycom on Twitter