ESP32 - M5Core2 board - ili9XXX LVGL init fail - no "esp.esp_clk_cpu_freq()" function

Hello!
There is a misconfiguration somewhere in build, because running latest ESP32 firmware on M5CORE2 device, I get this error:

File "ili9XXX.py", line 468, in ili9XXX
AttributeError: 'module' object has no attribute 'esp_clk_cpu_freq'

Firmware build info:
‘lv_micropython’ commit: 10ed6da4 (master branch)
Port: ESP32
Board: M5CORE2
ESP version: 4.2 (tag: v4.2, commit: c40f2590)

Terminal messages from M5Core2 device:

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4
load:0x3fff0034,len:5608
load:0x40078000,len:13156
load:0x40080400,len:4356
entry 0x400806b0
Initialising M5Core2 power management
  Vbus limit off
  Speaker amplifier off
  RTC battery charging enabled (3v, 200uA)
  ESP32 power voltage set to 3.35v
  LCD backlight voltage set to 2.80v
  LCD logic and sdcard voltage set to 3.3v
  LED on
  Charge current set to 100 mA
  Battery voltage now: 4.1228v
  Power key set, 4 seconds for hard shutdown
  Enabled all ADC channels
  USB / battery powered, 5V bus on
  LCD and touch reset
Traceback (most recent call last):
  File "boot.py", line 12, in <module>
  File "ili9XXX.py", line 72, in <module>
  File "ili9XXX.py", line 468, in ili9XXX
AttributeError: 'module' object has no attribute 'esp_clk_cpu_freq'
Traceback (most recent call last):
  File "main.py", line 1, in <module>
NameError: name 'lv' isn't defined
MicroPython v1.15-825-gdb540aded-dirty on 2021-07-19; M5Stack Core2 with ESP32

ili9XXX.py line 468:
cycles_in_ms = esp.esp_clk_cpu_freq() // 1000

This line is in source code for a long time, so the root cause of the issue must be somewhere in build scripts, because ~20 days ago (~2021-07-01) the firmware was working on the device, and LVGL was successfully initiated.

Thank you for your help!

By the way would it be possible to enable “Issues” feature/tab in Github for lv_micropython repo for bugs & issues, instead of creating new topic here in LVGL forum?

Hi @PGNet, thank you for reporting this!
Fixed. Please try latest version.

Most problems, this one included, are not related to lv_micropython but to lv_binding_micropython.
You can open an issue there instead of posting to the forum.

Fixed. Please try latest version.

Hi @amirgon,
I can confirm that the fix works on device (tested with my MP program).
Thank you!
Only M5Core2 → inisetup.py needs to be fixed, but I can do it, test it on real device, and then create PR.

1 Like

Not OP, but using the Core2. Build appeared to work properly, Getting the following output from the uC repeatedly after the make deploy (with specifying board type): lv_micropython rebooting on m5core2 repeatedly · GitHub

This is after pulling a fresh git clone, latest commit dae3f0ab94ff703deeb6f841f0642f423dba2e34.

Hi @aseelye,
Yes, that is the problem what needs to be fixed.
The firmware crashes in main.pyscr = lv.obj() (search this inside ports/esp32/M5CORE2/modules/inisetup.py file), because LVGL is not initialized.
This needs to be fixed in inisetup.py:
when it creates main.py, then it should call lv.init() first:

import lvgl as lv
lv.init()
scr = lv.obj()

… or at least that is the fix (still not tested), because I tested it only in my own program, where I call lv.init() right after display init.

Previous (deleted) reply was after not altering the inisetup.py file properly. I’ll delete this comment with a response once I’m back at the M5 to test properly.

Small update, the crashes are caused by the lcd initialization. The code for the Core2 is using parameters for an ILI9341, which IIRC was used on the original Core, perhaps others. The Core2 uses an ILI9342 which I recall behaved the same once initialized properly. I should be able to submit the fixes tomorrow if it’s as easy as it was six months ago.

Ok, I was able to test with the other parameters I had for the 9342, but found the same problems cropping up. Further, talking to another engineer who has dealt with this stuff a bit more than me, it sounds like the 9341 and 9342 are rather similar, so not much else needed in the code.

As it is, I’m getting that error still, you can see the output at lv_micropython lcd crash · GitHub. This was built on the dae3f0ab94ff703deeb6f841f0642f423dba2e34 commit. I’ve updated to the latest since then (now version ddda82575388ff316d5ce74d0652e36d1f0ca71a), still getting the same reload loop.

Is there a way I can enable more verbose errors? I’m seeing lots of hex addresses on the register dump, as well as the backtrace, but I’m not familiar with how to utilize that to track this down further.

Looks like a crash after initializing the display driver.

Did you remember to update submodules? (git submodule update --recursive)
There was a small fix in lv_binding_micropython that might be related, I want to make sure everything is up to date on your side.

Please parse the backtrace and send it here.
You parse it by passing the backtrace hex values to xtensa-esp32-elf-addr2line, like this:

xtensa-esp32-elf-addr2line -aipfC -e ./ports/esp32/build-GENERIC_SPIRAM/application.elf 0x... ... ..

Just to be sure I’m on the latest/correct everything, I spun up a new debian buster build, installed IDF 4.2, and pulled the latest lv_micropython (commit c7b749f5f148ba1dc4f7bff875485de680c30404). Still getting the crash. I used the micropython.elf file, as that was the only *.elf file in the build directory. If I’m meant to do another one, please let me know.

serial output: m5core2 crashing, screen output · GitHub

backtrace output: m5core2 backtrace output · GitHub

@aseelye you didn’t confirm you’ve updated submodules (git submodule update --recursive).
This is required after you pull lv_micropython.
The commit id of lv_micropython by itself is not enough to confirm you are up to date.

Your backtrace looks very much like this one, which was related to a missing lv.init().

  • Please check what is the commit id of lv_bindings submodule (git submodule status -- lib/lv_bindings)
  • Please try adding lv.init() before initializing the display driver.

Hi @aseelye, @amirgon,
The fix for the device crash is in this PR:

The problem is, that - as I noticed since LVGL 8.0 - LVGL should be initialized BEFORE display driver init.
(in my previous post I was wrong: LVGL should be initialized before, and not after display driver)
Please make sure to ERASE device flash first, because flashing firmware will not erase internal FS, and inisetup.py will not run.
(… and sorry for the late fix, what I’ve promised days ago…)

@aseelye, please confirm, whether it works.
Thank you!

Ok, looks like it was the import of lvgl first, initializing that, and then the power & lcd after that is the winning formula. Erasing the files created by inisetup.py and then running

import lvgl as lv
from m5core2_power import Power
from ili9XXX import ili9341

lv.init()
power = Power()
lcd = ili9341(mosi=23, miso=38, clk=18, dc=15, cs=5, invert=True, rot=0x10, width=320, height=240, rst=-1, power=-1, backlight=-1)
from ft6x36 import ft6x36
touch = ft6x36(width=320, height=280)
scr = lv.obj()
btn = lv.btn(scr)
btn.align(lv.ALIGN.CENTER, 0, 0)
label = lv.label(btn)
label.set_text("Button")
lv.scr_load(scr)

runs properly, no crashes, and puts the expected blue button in the center of the screen. Thank you both!