Firmware release 1.7.1.b1
this.wiederkehr last edited by
@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?
livius last edited by
is this sample or you have really this wrong address?
ortbut should be
this.wiederkehr last edited by
@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_syncedwhich 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.
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.
@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.
this.wiederkehr last edited by 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!
robert-hh last edited by 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.
1.7.1.b2 is now released. It removes the unwanted
@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?
robert-hh last edited by
@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.
robert-hh last edited by
@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.
mcook last edited by
Thank you. I downloaded the latest compiler, removed all of my old stuff and re-installed it all, and now it builds fine.
i tested this self
and whithout file
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
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 :)
ha sorry misunderstood your comment. But if I do
dir(wifi)as you showed I get nothing.
livius last edited by
This is my custom file.
And it worked ok in previous firmware.
but now this name is registered by system for something. I see nothing about in docs and i do not see it in pycom sources, but maybe i miss something in pycom sources
As Jeroen explains do we need to build the toolchain from the xtensa-1.22.x-ext_ram_patch branch to compile the Pycom source correctly for the W01/L01 modules?
All seems a bit cutting edge :-) but to get 4MB RAM wow...
i have found problem :) And now have question.
wifiregistered as reserved unit name?
i have in my lib folder
but i see that when i call dir it list me some system objects?
>>> dir(wifi) ['Wifi', 'WLAN', '__name__', 'hexlify', 'sleep', 'Timer', 'exc_info', 'start_new_thread']
wifi.pyto different name and all its references
all work ok
jmarcelino last edited by
not sure if it helps but the latest toolchain is actually https://dl.espressif.com/dl/xtensa-esp32-elf-osx-1.22.0-61-gab8375a-5.2.0.tar.gz