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.
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.
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
We’ve just released another bunch of firmware images with hopefully improved robustness, so [1] might make you happy.
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.
0.7.0 scheint fertig:
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/
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.
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.
Hallo zusammen,
danke für die vielen Rückmeldungen und Vorschlägen!
Meine konkrete Fehlermeldung habe ich heute am Bienenstand reproduzieren können. Ich benutze dazu zurzeit Ubuntu 18.04 LTS mittels des WSL in Windows 10. make setup
läuft soweit ohne Fehlermeldungen durch. make install
tut dann folgendes:
Auf dem LoPy4 ist LoPy-1.20.2.rc6-0.10.1-vanilla-squirrel
installiert.
Der Timeout tritt auf die selbe Art und Weise auf zwei verschiedenen System auf (Desktop PC + Laptop).
Danke noch mal für die Hilfe!
Viele Grüße, Jan
Nutzt du die presets.mk
abgeleitet von der presets-example.mk
? Soweit ich mich erinnere, zeigt der Schreibversuch nach /pyboard/, dass MPY_TARGET
nicht pycom
zugewiesen hat
In der Tat habe ich die presets.mk
nicht aus der presets-example.mk
erzeugt. Das war mir bisher nicht bewusst. Ich habe mich allerdings schon gefragt an welchem Punkt entschieden wird, welche Variante eigentlich ausgerollt wird… das wäre damit dann wohl auch beantwortet
Ich kann das jetzt leider nicht direkt testen, weil mein (einziger) LoPy4 gerade seit Kurzem am Bienenstand im Einsatz ist.
Ich bin da ja auch mal reingerannt und hatte schon ein neues update in Verdacht, weil gar nix ging. Weiß auch nicht für was wir alles die presets.mk
brauchen, wenn der COM-port bei mir falsch drin steht geht nichts, das hier aber steht noch so
# Pycom MicroPython
FWB_MICROPYTHON_PYCOM ?= /path/to/pycom-micropython-sigfox
FWB_ESPIDF_PYCOM ?= /path/to/pycom-esp-idf
in der presets.mk
hätte eigentlich erwartet, dass man das anpassen muss, funktioniert aber dennoch??!