Firmware release 1.7.1.b1

[daniel]

@Innocenzo have you rebuilt the bootloader? The command is erase instead of flash

[robert-hh]

@Innocenzo I had the same trouble (see my posts below): After using the updater tool once, you have to erase the flash BEFORE you use you load youe own-built firmware. You can do that with:

make erase

HOWEVER, after doing that, the board does not run boot.py or main.py any more. It considers itself in the safeboot mode. This is a software fault.
I'm interested if that happes to you too? If yes, you could still call boot.py and main.py from frozen/_boot.py, which is called always.

[Innocenzo]

@daniel said in Firmware release 1.7.1.b1:

@Innocenzo have you rebuilt the bootloader? The command is erase instead of flash

yes.

• I have erased the old repository ;
• I have downloaded the new pycom-micropython-sigfox and pycom-esp-idf;
• git submodule update --init in all repository
• in pycom-micropython-sigfox/mpy-cross make all
• in pycom-micropython-sigfox/esp32:
• make BOARD=WIPY TARGET=boot;
• make BOARD=WIPY TARGET=app;
• make BOARD=WIPY flash.

[Innocenzo]

@robert-hh Yes. The boot.py and the main.py present in /flash/ dir, do not start after flashing my own firmware.

[robert-hh]

@Innocenzo Before the step:
make BOARD=WIPY flash
you have to do:
make BOARD=WIPY erase
In order to erase the flash memory on the device. Obviously, all content on the device will be lost!

[Innocenzo]

@robert-hh Yes. I do it and now I can flash my own firmware, but the file main.py and boot.py do not start "on boot".

[daniel]

Issue with the safeboot fixed here: https://github.com/pycom/pycom-micropython-sigfox/commit/f29075e4b0a1f713af1d2579465ffd35e360eb12

[robert-hh]

This post is deleted!

[robert-hh]

@daniel Thanks. That looks like the right place. I cannot check it before this evening, by innocenzo may do so.

[this.wiederkehr]

@daniel: Any ideas why I get those LoadProhibited exceptions? Any hint where I should start searching. I'm just lost on these ...
The first two seem very low level which makes me wonder .... the third might be related to the issue with ntp_sync.

[daniel]

@this.wiederkehr we are investigating this now.

[Innocenzo]

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

[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

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

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

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

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

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

[peekay123]

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

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