ESP32 and LVGL - Guru Meditation Error after reboot if network initialized

[spookyrufus]

Hello! I am experiencing issues with the Micropython + LVGL firmware (compiled with all default settings) on an ESP32 Wroom chip.
Things seem to go terribly wrong every time I try to instantiate a network.WLAN object.
I am not able to debug any further, but I was able to reliably reproduce the error I get through a simple procedure:

(1) Install fresh firmware
(2) Run following code:

Code: Select all

	import network
	wlan_sta = network.WLAN(network.STA_IF)

(3) The code seems to run fine...:


(4) ...until I reset the board (either through machine.reset() or via the hardware button), after which all I see is:



And to my best knowledge, all I'm left with is to have to erase_flash the chip, and to re-deploy a fresh firmware.
It looks like initiliazing a WLAN object causes some sort of permanent damage which prevents the board to ever reboot correctly, but I don't seem to have the skills to pinpoint the reason, and Google has not been my friend on this issue.

I would appreciate if someone could help me pointing this sinking ship towards the land

[spookyrufus]

One more thing to add is that the issue happens independently from how good the power supply to the esp is..

[marcidy]

I'm not familiar with that port, but it sounds like a pretty bad bug with the build, like the partitioning is off or something. usually there's a dedicated partition to store wifi calibration. If it's storing the wifi params to the partition it's trying to boot, might end up with this kind of behavior.

[spookyrufus]

Thanks for the reply.
I figured it must be something to do with that, but couldn't still pinpoint the origin of the problem.
As far as I know, the micropython wrapper for LVGL should be relatively stable and I still think I am doing something wrong, possibly not configuring the build properly.
I have cross post in LVGL forums hoping to get some insight from there, but they are not quite as active as MicroPython's forum.

[marcidy]

Can you post your partitions.csv and the output from `idf.py partition_table`?

[spookyrufus]

I cross-posted to LVGL forums at this address https://forum.lvgl.io/t/esp32-and-lvgl- ... zed/4807/2, and was able to solve the issue by re-making LVGL using ESP-IDF v4 instead of v3.3, and by adding the proper parameters to the make command, in order for the build to support the ILI9341 display that I am using.
Interestingly enough, the ILI9341 never was an issue, with- or without- the following specific parameters, but I experienced the Meditation Errors described above, without them:

Code: Select all

make -C mpy-cross
make -C ports/esp32 LV_CFLAGS="-DLV_COLOR_DEPTH=16 -DLV_COLOR_16_SWAP=1" BOARD=GENERIC_SPIRAM deploy

The problem is now resolved and I can successfully instantiate a WLAN object across reboots, without Meditation Errors and without any filesystem corruption.

[vlasoveqn]

Hello everyone, first post here!

Like the OP, I also am having similar trouble with 'network.WLAN(network.STA_IF)'.

First, a moment of context/background: I first used this version of MicroPython sometime in mid-2019, but rapidly decided to switch to the LoBo fork due to restrictions on the use &/or size of SPI ROM and SPI RAM. Since then, I've been developing ESP32 firmware with that flavor of fork, but recently switched back to the main fork (terminology?) because LoBo was not actively being developed, did not (truly) support BLE, and looked as if the fork had been abandoned.

So, it took just a bit of effort to reinstall ESP-IDF, the xtensa toolchain, etc. (on Ubuntu Linux), but now have everything working properly. And, boy, do I like the new ease of firmware building!

Anyway, I'm very impressed by the breadth of support for most ESP32 internal hardware. HOWEVER, in the process of beginning to port my modules, I encountered the dreaded Guru Meditation Error -- when instantiating a network.WLAN object! MicroPython rebooting occurs regardless of whether the argument of network.WLAN is network.STA_IF or network.AP_IF. I have also temporarily removed all my custom modules, so there's no possibility that any custom additions to the firmware might be causing this issue. The behavior persists. This is extremely problematic, because I was planning on using two of the ESP32 units together to test BLE integration (one as GATT client, one as GATT server)--but this requires me to interact with one unit via telnet over WiFi, and now I can't do that despite BlueTooth working (!!). I'm also using a custom PCB that doesn't use USB, Ethernet, etc. and it's only easy to use direct serial communication with one unit at a time (I have to use a specially made jig, of which I only have one).

For the record, I'm using ESP-IDF v4.1.1, CPython 3.9.2 on Ubuntu, and a fork of the master MicroPython branch from git. Before you ask or assume anything, I'm definitely not a professional programmer, and have never used git until recently--I'm still stuck in the Subversion world of 20 years ago (it still works now, for local work!!). If anyone needs information about which MicroPython branch I'm using, as of which date, you'll have to suggest the specific git commands to get that info... until I get more comfortable with it.

As I have never done any language development of MicroPython--and don't plan on doing any in the near future--it's a bit tricky to troubleshoot any cause of the 'kernel panic' phenomena by looking at C code, as I'm not a C expert and at this time don't know much about MicroPython interpreter innards, operation, or implementation in C. So, if anyone wants to jump in and help me here, I would _greatly_ appreciate it! Has anyone else other than the OP encountered this behavior?

Thanks!

By the way, the OP seemingly solved the problem by erasing the flash and reflashing, I think, but this did not work for me.