Firmware release 1.7.1.b1

livius

@jmarcelino
what you got when you do?

import wifi
dir(wifi)

if above raise error
try to create empty wifi.py file in lib and back with result - i am really interested :)

livius

@jmarcelino
i tested this self
and whithout file wifi.py anywhere
i have interesting result

>>> import wifi
>>> dir(wifi)
['Wifi', 'WLAN', '__name__', 'hexlify', 'sleep', 'Timer', 'exc_info', 'start_new_thread']
>>>

can someone confirm this?
And maybe @daniel can bring light about purpose of that module

mcook

@jmarcelino

Thank you. I downloaded the latest compiler, removed all of my old stuff and re-installed it all, and now it builds fine.

Mike

robert-hh

@livius I created a brand new firmware, and loaded that: no module wifi.
BUT: If I update via the pycom updater, there is a module wifi included.
So it's sneaking in via the "official" image.

daniel

@livius and @robert-hh thanks for the help. We found the offending file and a release without the problem will be out within 1 hour.

robert-hh

@daniel I have another problem with the github distro:

It worked fine after I did an initial build an upload yesterday night, Both the MP repository and and esp IDF were freshly cloned. No own history whatsoever.
The (in the hunt for wifi.py) iI used the updater, and that worked.
After trying to reflash the firmware with my own build, the device would not start again.
I erased flash and reflashed it with my freshly build image.
Now the device boots again, BUT does not execute boot.py or main.py. It seems to believe, that it is in safeboot mode.
The image loaded via the updater tool runs main.py and boot.py
Steps 2 & 3 can be repeated. I cannot switch between the versions w/o an erase.

daniel

@robert-hh there were changes in the partition table on the latest release hence the need to erase. The updater tool only erases the necessary blocks of flash in order to remove any left over of the previous partition info. After erasing manually and flashing your own built image things should work as normal too. Is that not the case?

daniel

Hello,

1.7.1.b2 is now released. It removes the unwanted wifi.py script. Thanks.

Cheers,
Daniel

robert-hh

@daniel Sorry, no, that is not the case. After erasing flash and reloading my own image, that image boots, but does not execute main.py or boot.py. It behaves like in safeboot mode. If I comment out line 180 (the line below) of mptask.c, main.py and boot.py run.
safeboot = boot_info.safeboot;
It looks as if boot_info is set wrong. Nothing is connected to the Lopy, and with the standard image, main.py and boot.py are executed.

Update 1: I should add that the own built firmware now also does not print the version number on boot or Ctrl-B anymore. The message is:
MicroPython 88419a4-dirty on 2017-06-03; LoPy with ESP32
Manually adding a tag in with git fixed that, but not the main.py skip.

Update 2: Why are the partition tables of updater images and the github executables different. That's confusing & error prone.

this.wiederkehr

There are multiple issues with this release:

1. RTC time sync with ntp is not working correctly anymore with this release:

(sysname='LoPy', nodename='LoPy', release='1.7.1.b2', version='v1.8.6-642-g84447452 on 2017-06-03', machine='LoPy with ESP32', lorawan='1.0.0')

With the 1.6.XX I could easily sync with ntp server, e.g. rtc.ntp_sync("pool.ntp.org"). Some time after this call rtc.now() would return the current time. Now this is not happening any more time does not get synced at all even after minutes. No Idea why. There is also no way to know what is wrong...

2. Guru Mediation Error Load Prohibited

After a few minutes of running my app I get around 30 of the following exceptions with different backtrace and the board resets:

Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x400875b9  PS      : 0x00060033  A0      : 0x40088c47  A1      : 0x3ffbd5d0  
A2      : 0x00050023  A3      : 0x00000000  A4      : 0x00000001  A5      : 0x3ffc3dc8  
A6      : 0x000ee81c  A7      : 0x3ffc0df4  A8      : 0x00000005  A9      : 0x00000001  
A10     : 0x3ffc3e34  A11     : 0x00000000  A12     : 0x3ffc3e34  A13     : 0x00000000  
A14     : 0x00000000  A15     : 0x00000000  SAR     : 0x00000016  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000048  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x400875b9:0x3ffbd5d0 0x40088c47:0x3ffbd5f0 0x40088c01:0x3ffbd630 0x4013d1d7:0x000ee81c

3. Freeze The title says it all and I cant add any more information as on freeze it does not provide any more information ....

Please, please, please get out something which is stable!!! Right now this is not usable for anything more than doing TESTS!

daniel

@this-wiederkehr thanks for your post. I'm sorry about your frustration. We only release new software when all our automatic tests (more than 400) are passing. I'll check asap what's happening with the NTP sync and fix it, but if you can provide a minimal example to reproduce the crash I will appreciate it very much.

Thanks again.

Cheers,
Daniel

this.wiederkehr

@daniel indeed this is frustrating.. Thanks for showing interest in solving the issues:

Issue1: NTP SYNC

This is straight forward:

import utime

from machine import RTC
from network import WLAN

wl = WLAN()
wl.mode(WLAN.STA)

wl.connect('XX', auth=(X, 'XX'))



rtc = RTC()
rtc.init()
rtc.ntp_sync('pool.ntp.ort')

while True:
    print(rtc.now())
    print(wl.isconnected())
    utime.sleep_ms(1000)

What it does: Prints time tuple but stays in year 1970. :

(1970, 1, 1, 0, 25, 56, 158744, None)
True
...

I also saw examples where it jumped to a year far in the future: (62236, 1, 19, 7, 16, 53, 555967, None)
While on it: It would be great if the api for the rtc could be extended in order to know if a sync took place. something like last_synced which should return the time elapsed since the last sync or none if a sync never succeeded.

Actually it is not as easy for the second and third issue to provide a minimal example as the issue does not happen each time the same code path runs but arbitrarily, read on...

Something about my setup:

I'm using the expansion board with an sd-card populated
I'm using P10, P11 and P12 for spi communication and additionally P9 for CS (chip select) attached is an acceleration sensor with a fifo buffer
Several times a second I read the data from the fifo through spi and dump it to the a file on the sd card and call flush to persist the changes in a file.
Issue 2 and 3 both happen around flushing the write to the sd-card, either just during flushing or nearly after, however they do not happen each time! The app runs for as little as a few seconds before issue 2 or 3 occur or as long as about 20 minutes. However I did not see much longer durations.

dummy code:

f = open(file_on_sd, 'a')
f.write(data)
print('about to flush')
f.flush() # <-- Both issues are located here or right after that call
print('flushed') # <-- Sometimes even this line is printed and freeze occurs afterward

Issue 3: Freeze on sd flush
Issue 3 occurs during or right after flushing
I read the issue https://github.com/espressif/esp-idf/issues/569 which is about a race condition on reused pins for sd-card and something else. So I thought that the freeze is related to this and I probably should not use P9 for CS of the SPI device. Switching from P9 to P14 for CS seemes to solve the problem with freezing, still this seems like a workaround which should not be required in the first place.

While playing I found how you can make the interpreter freeze reproducible at that line, though this might be totally different issue or even expected:

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")

Issue 2: Load prohibited
Occurrence of this error is at the same location as the the freeze issue, however I did not have time to dig into it. It might be easier for you anyway by using the stack trace.

I also noticed freezes during gc collect but these seems quite rare.

livius

@this.wiederkehr said in Firmware release 1.7.1.b1:

pool.ntp.ort

is this sample or you have really this wrong address? ort but should be org

this.wiederkehr

@livius thanks for pointing out that typo! Even with the correct address the behavior is the same. Does ntp_sync work for you with this firmware?

daniel

@this-wiederkehr thanks for the extra details. We have found the issue with ntp_sync and it's being fixed. We will also add the method to query when that last sync occurred. Using your input we are also investigating the crash and freeze.

Cheers,
Daniel

daniel

@this-wiederkehr something I don't understand. P9 is not used by the SD card, it's P8. Also P14 is an input only pin, so how is that possible that you can use it to act as chip select?

Cheers,
Daniel

Strevens

@daniel Thanks for the prompt action on the NTP sync. looking forward to the new build.

could you clarify where the firmware versions are archived as the link on the web says page not found when following the link on quick start page.

https://www.pycom.io/support/supportdownloads/#firmware

daniel

@Strevens the updater tool is located here: https://www.pycom.io/downloads/

You can use the following link to the the latest release:

https://software.pycom.io/downloads/LoPy_868-1.7.1.b2.tar.gz

If you want a different version, just replace the version number/name on the link accordingly.

Cheers,
Daniel

this.wiederkehr

@daniel Thanks for the update and great you found the issue with ntp_sync.

P9 on the Lopy is labeld SD_DATA2 that is why I thought it might somehow be involved. I know it is not connected on the expansion board.

Sorry about P14 should read Pin 14, GPIO25 or P22.

I have a test going on and will report back if changeing the CS pin to that pin solved the issue with the freeze.

Strevens

@daniel Thanks!

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

Firmware release 1.7.1.b1

Pycom on Twitter