Saying this kiddingly, I strongly believe this issue is more likely related to Random memory corruption faults on ESP32-WROVER rev.1 and rev.2 when running in dual-core mode.
Coming back from there, we built firmware images for the FiPy and the LoPy4 using
#define CONFIG_FREERTOS_UNICORE 1
I can’t tell for sure whether this makes any difference at all as the FiPy on my workbench has been running pretty stable even before without that setting.
- https://packages.hiveeyes.org/hiveeyes/foss/pycom/LoPy4-1.20.1.r1-vanilla-unicore-0.1.0.tar.gz
- https://packages.hiveeyes.org/hiveeyes/foss/pycom/FiPy-1.20.1.r1-vanilla-unicore-0.1.0.tar.gz
Please also pull from our latest master as this will bring you Improve WiFi robustness on first connection attempt · hiveeyes/terkin-datalogger@d3ae518 · GitHub.
2 Likes
The AttributeError comes up, when bus-onewire-0 in settings.py is disabled
"id": "bus-onewire-0",
"family": "onewire",
"number": 0,
"enabled": False,
"pin_data": "P11",
1 Like
Thanks for letting us know. Are you sure you are running the latest version from master or did you make some modifications locally? At line 329, we are seeing an empty line there.
However, we just added [1] and [2] to mitigate all conditions when accessing a sensor object connected to a bus object which has been disabled through the configuration settings.
1 Like
Again I saw these core panics also with the unicore firmware. It starts happening after about 10 times flashing the device after PWRON. After dis/reconnecting the device from/to power the error is gone, likely until the next 10 flash procedures.
1 Like
Thanks for letting us know.
Uploading raw source code through raw REPL is a rather heavy process which contributes to memory fragmentation on the device most probably leading to subsequent crashes, most probably caused by Random memory corruption faults on ESP32-WROVER rev.1 and rev.2 when running in dual-core mode.
If you are getting sick of this, we might want to go for more advanced and efficient methods bringing the source code to the device with less overhead.
I am using the one-stop
make recycle-ng MPY_CROSS=true MPY_TARGET=pycom MPY_VERSION=1.11
these days and would never look back. The background about why this is way more efficient is that it’s using FTP instead of raw REPL for transferring the files and that it will compile the sourcecode to bytecode before, reducing the overall size of stuff to be shipped to the device significantly.
$ du -sch dist-packages terkin
596K total
$ du -sch lib-mpy-1.11-pycom
352K total
How to
This currently requires a network connection over WiFi with the IP address of the device stored in .terkin/floatip like
$ cat .terkin/floatip
192.168.178.40
For automating this, I am using
make terkin-agent action=maintain macs=80:7d:3a:c2:de:44 # libero
to find the device’s IP address and
make connect-wifi ssid=GartenNetzwerk password=<redacted>
to actually get the device into the network if required.
2 Likes
this revealed the following modules missing from the environment:
- netaddr
- netifaces
- scapy
Do you mind adding these to the requirements files?
These guys are listed in requirements-terkin-agent.txt already. Just run
make setup-terkin-agent
Sorry that we haven’t documented each and every bit of these details yet. You are probably one of the first people running Linux who would like to use that infrastructure.
We followed the instructions on PSRAM Cache Issue stills exist (IDFGH-31) · Issue #2892 · espressif/esp-idf · GitHub thoroughly and just made another wave of releases. If we are lucky, [1] might be even more stable for you.
Dear @Thias,
we just released [1]. It includes some additional fixes on the ESP-IDF level and might also add some improvements on stability. For more details, enjoy [2].
With kind regards,
Andreas.
[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/LoPy4-1.20.1.r1-0.5.0-vanilla-butterfly-csfix.tar.gz
[2] Pycom firmware bakery
1 Like
We’ve just released another bunch of firmware images with hopefully improved robustness, so [1] might make you happy.
1 Like
Hallo zusammen,
bei meinen Versuchen den Terkin-Datalogger auf meinem LoPy4 zum Laufen zu bekommen (hier noch per Atom+Pymakr) bin ich mit der Releaseversion 2019-08-19 0.6.0 auf folgenden Fehler beim Upload auf den LoPy gestoßen, den @clemens auch schon mal hier angesprochen hat:
Auf dem LoPy4 habe ich dafür bei meinen Versuchen diverse Firmwares probiert, von der neuesten LoPy4-1.20.2.rc6-0.10.1-vanilla-squirrel.tar.gz bis zu einer 1.20.1.r1, alle mit dem selben Fehler.
Meine ersten Versuche mit der Sandbox dann endeten mit einem Connection Timeout zum LoPy, sobald ich make sketch-and-run gestartet habe.
VG,
Jan
Die Squirrel Firmware ist schon mal eine gute Idee.
Wir machen bald ein neues Release. @Andreas wird dich informieren, wann das geschehen ist.
Hast du mal RESET gedrückt, wenn du in der Sandbox auf die Verbindung wartest. Selbst dann dauert die Übertragung meist eine ganze Weile.
Das letzte “offizielle” release ist leider recht alt, ich schicke dir mal (per PM) eine Kopie des codes meines aktuellen LoPys. Den habe ich mit Matthias ttn-branche erzeug, quasi ein “dirty-release”, der läuft mit der 1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig firmware … nur falls du nicht warten magst, bis das offizielle auf git ist.
Leider ist es so, dass im GIT-Repo nicht der code liegt, der dann 1:1 auf den LoPy kommt, sondern die Maschinerie “Sandbox” bastelt da einiges zusammen.
1 Like
0.7.0 scheint fertig:
3 Likes
Ich habe es bisher leider nicht geschafft die Terkin Sandbox zum Laufen zu bekommen mit der WSL (Ubuntu 18.04 LTS), bzw der Upload zum LoPy4 klappt nicht wegen timeouts. Ich habe es auch mal mit WSL und Ubuntu 20.04 LTS versucht, aber die virtualenv wird mit make setup nicht erstellt/gefunden, ich glaube die heisst in den neueren Python Versionen 3.8.x jetzt venv… sicher bin ich mir allerdings nicht.
Gibt es sonst noch eine Möglichkeit, wie eine zum LoPy hochladbare Version erzeugt werden kann, z.B. auch ohne angestecktem LoPy? Das wäre hilfreich, um die im Feld befindlichen LoPys mit einem Laptop am Bienenstand updaten zu können.
VG, Jan
Du kannst Python 3.7 idR auch übers System nachinstallieren (sudo apt install python3.7) und zum systemweiten Default machen, zB [1]. Dann würde make setup eine darauf basierende venv erstellen.
hast du den LoPy4 steckbar auf deinem Board? Dann könntest du ihn zum Beschreiben in ein Expansion-Board von Pycom [2] umstecken und dafür den USB Anschluss verwenden.
[1] https://linuxconfig.org/how-to-change-from-default-to-alternative-python-version-on-debian-linux#h2-change-python-version-system-wide
[2] https://pycom.io/product/expansion-board-3-0/
1 Like
Bei mir läuft das ganze unter WSL mit Ubuntu 18.04.3 LTS, daran sollte es also nicht scheitern! Hast du eine genauere Fehlermeldung?
Du könntest dir das neueste Release runterladen, gerade z.B. terkin-datalogger-0.9.0-pycom-mpy-1.11.zip, das lokal entpacken, ggf. die settings.py anpassen, wenn noch keine auf dem Gerät ist und dann per expansion board und Atom-IDE hochladen. Auch per FTP via WLAN kann man Daten hochladen, dazu muss allerdings der LoPy im WLAN (!) sein! Mit deep sleep ist das allerdings tricky, Andreas hat dafür einen maintanence mode gebaut, aber auch da muss das Gerät im WLAN sein. Siehe dazu auch Remote via WLAN (telnet, FTP) auf den WiPy / FiPy zugreifen
P.S. Meistens geht es im Feld aber nicht darum, die komplette Firmware zu tauschen, sondern nur einzelne Konfigurationsparameter zu ändern. Thias hat z.B. schon implementiert, dass man mit TTN das Updateintervall verändern kann.
P.P.S. Theoretisch ist auch ein (automatisches) OTA- update des kompletten codes möglich, wegen der Menge aber nur per WLAN / LTE, der link zeigt aber nur ein proof of concept, und es ist in produktiver Software weder bei Terkin noch bei BOB implementiert.
1 Like
Hi Jan,
danke für Deine Rückmeldungen.
Hast Du denn die aktuellste Squirrel firmware for Pycom/ESP32 auf dem Gerät?
Die Sandbox braucht derzeit sowohl Python2 als auch Python3. Wenn alles glattgeht, erstellt make setup zwei virtualenvs direkt im Hauptverzeichnis: .venv2 sowie .venv3.
Bei Setup MicroPython sandbox — Terkin Datalogger 0.14.0 documentation haben wir
apt install make patch wget git python python3 python-virtualenv lftp
vorbereitet. Ggf. müssen wir die genauen Paketangaben für ein neueres Ubuntu-Release anpassen.
Viele Grüße,
Andreas.
P.S.:
Während die Sandbox ja hauptsächlich zum Entwickeln gedacht ist, ist die anvisiert benutzerfreundlichste Variante die Annapurna firmware images for Pycom/ESP32. In diesem Fall ist alles komplett lauffähig in einem einzigen Firmware-Image enthalten und man muss nur noch die settings.py (derzeit auch noch main.py und boot.py) hinzufügen und es kann losgehen.
Wenn Du vorhast, viele LoPy’s damit auszurollen, sollten wir dieses Pony mal wieder neu satteln – also mal wieder in die Hand nehmen und auf einen aktuellen Stand bringen, das dort verlinkte 0.7.0er Release ist veraltet (Stand November 2019).
P.P.S.: Trotzdem fände ich es gut, wenn wir auch die Sandbox bei Dir zum Laufen bekämen.
Diese kleine Anpassung könnte es besser machen:
Die Dokumentation bei Setup MicroPython sandbox — Terkin Datalogger 0.14.0 documentation wurde damit ebenfalls aktualisiert.
1 Like