Please note: If you are looking for more recent releases based on Pycom’s 1.20.2.rc3 and 1.20.2.rc6 complemented with additional features, you might want to follow up at Squirrel firmware for Pycom/ESP32.
Introduction
We’ve built upon many aspects researched within Investigating random core panics on Pycom/ESP32 devices and will follow up on this with an extensive report and an attempt to mainline this ASAP, as soon as we are able to confirm it will really make things more robust. In all other cases, this is just us fantasizing about possible improvements.
For now, we would like to get this into the hands of more people and will be happy about any feedback.
The firmware images referenced within this post are all based on Pycom’s 1.20.1.r1. On top of that, these builds also include noteworthy patches from the community you might enjoy.
These images called VERSION-BUILD-vanilla-dragonfly are inofficial firmware images for testing built with VARIANT=BASE. They are available from https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/. The most recent releases are:
These images called VERSION-BUILD-pybytes-dragonfly are inofficial firmware images for testing, built with VARIANT=PYBYTES. They are available from Index of /hiveeyes/foss/pycom/pybytes/. The most recent releases are:
Please be aware that when upgrading from a lower firmware version to the current 1.20.1.r1 development release these builds are based upon, you will have to erase your device completely before flashing in order to keep things straight [1]. Hint: Use a command like [2]
Please also be aware that this procedure will also erase the LoRa MAC as well as the Sigfox ID and PAC identifiers stored on the device.@robert-hh thankfully outlined the procedure to restore it appropriately:
I have installed a Dragonfly build for FiPy and manually populated the device with both the Hiveeyes firmware and the BOB firmware, however without having attached any sensors for now. With both firmwares, I did not observe any core panics / Guru meditation errors during a short time of testing.
Also, I did not observe any broken upload through Atom/Pymakr so far. I was able to download the whole large Hiveeyes firmware from the board to the local computer without any issues.
Only thing what is not working: From a running FiPy device a newly initiated upload does not work. You will have to stop the running program first – what works not always – but this was the case before also.
Uploading the Hiveeyes firmware via Atom was – again – not possible on a first attempt. I’ve still seen messages like that:
[17/65] Writing file dist-packages/microWebSocket.py (11kb)
[18/65] Writing file dist-packages/microWebSrv.py (35kb)
Failed to write file, trying again...
Failed to write file, trying again...
Failed to write file: no module named 'logger
[19/65] Writing file dist-packages/microWebTemplate.py (13kb)
Failed to write file, trying again...
Failed to write file, trying again...
Failed to write file: no module named 'logger
[20/65] Writing file dist-packages/mqtt.py (6kb)
Failed to write file, trying again...
However, the process succeeded on a second attempt after pressing the upload button in Atom.
@sita also had troubles with a program running on a LoPy4 device using one of the original firmwares. Running the same on the Dragonfly firmware seems to work though.
Ich wollte das Loggen auf SD-Karte näher untersuchen und habe die BOB-Software (FiPy-master), die seit Monaten auf einem FiPy mit
1.20.1.r1-0.7.0-vanilla-dragonfly-onwire 2019-11-17 gut läuft auf einem zweiten Fipy mit neuem
1.20.2.rc10 2020-06-26 geflasht.
Jetzt gibt es den Fehler “_onewire” not defined oder ähnlich und das Programm stürzt ab.
Wenn ich auf die alte Firmware 1.20.1.r1-0.7.0-vanilla-dragonfly-onwire 2019-11-17 zurück gehe, läuft alles.
Kann mir jemand die Feinheiten der Firmware-Versionen erklären?
Du kannst die Dragonfly Builds verwenden, oder auch deren Nachfolger Squirrel firmware for Pycom/ESP32, welche immerhin auf Pycom’s 1.20.2.rc6 aufbauen.