ESP32 Micropython build errors... LOTS

Micropython
1

I hope there is enough here for someone to identify the problem.
Tool versions and comments below.

(bild-lvgl) rich@RG-x360:~/lvgl/lv_micropython$ make V=1 -C ports/esp32 LV_CFLAGS="-DLV_COLOR_DEPTH=16 -DLV_COLOR_16_SWAP=1" BOARD=GENERIC PYTHON=python2 deploy
make: Entering directory ‘/mnt/c/tpi-dev/lvgl/lv_micropython/ports/esp32’
Building with ESP IDF v4
find: ‘/home/rich/lvgl/esp/esp-idf/components/xtensa-debug-module/include’: No such file or directory

… loads of errors

/home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp:24:5:
printf("%s%s\n", FATAL_EXCEPTION, msg);
^~~~~~
/home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp: In function ‘void __cxx_fatal_exception_int(int)’:
/home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp:35:5: error: ‘printf’ was not declared in this scope
printf("%s (%d)\n", FATAL_EXCEPTION, i);
^~~~~~
/home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp:35:5: note: ‘printf’ is defined in header ‘’; did you forget to '#include '?
Makefile:770: recipe for target ‘build-GENERIC//home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.o’ failed
make: *** [build-GENERIC//home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.o] Error 1
make: Leaving directory ‘/mnt/c/tpi-dev/lvgl/lv_micropython/ports/esp32’
(bild-lvgl) rich@RG-x360:~/lvgl/lv_micropython$

Using Windows Subsystem for Linux…

BOARD is Adafruit HUZZAH32 – ESP32 Feather Board

$ printenv (not all)
HOSTTYPE=x86_64
LESSCLOSE=/usr/bin/lesspipe %s %s
LANG=C.UTF-8
OLDPWD=/home/rich/lvgl/lv_micropython
WSL_DISTRO_NAME=Ubuntu
VIRTUAL_ENV=/mnt/c/tpi-dev/lvgl/lv_micropython/bild-lvgl
IDF_TOOLS_PATH=/home/rich/lvgl/esp/esp-idf
USER=rich
IDF_TOOLS_EXPORT_CMD=/home/rich/lvgl/esp/esp-idf/export.sh
PWD=/home/rich
HOME=/home/rich
NAME=RG-x360
IDF_TOOLS_INSTALL_CMD=/home/rich/lvgl/esp/esp-idf/install.sh
OPENOCD_SCRIPTS=/home/rich/lvgl/esp/esp-idf/tools/openocd-esp32/v0.10.0-esp32-20190313/openocd-esp32/share/openocd/scripts
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
SHELL=/bin/bash
TERM=xterm-256color
SHLVL=1
IDF_PATH=/home/rich/lvgl/esp/esp-idf
LOGNAME=rich

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

$ git describe esp-idf version
v4.0-beta1

$ xtensa-esp32-elf-gcc --version
xtensa-esp32-elf-gcc (crosstool-NG esp32-2019r1) 8.2.0

$ cmake --version
cmake version 3.10.2

$ python -V
Python 2.7.17

$ python3 -V
Python 3.6.9

I am totally exhausted with trying to build these binaries.
I’ve been on other fourms. see PM-TPI
https://forum.micropython.org/viewtopic.php?f=3&t=7307
it says it all.

I would like to see the LittlevGl team make YouTube videos starting with installing and running ESP-IDF and LittlevGl tools.
Especially using WSL on Windows that is becoming very popular and easy.

Thanks

2

Hi @GC-RmG!

What you call the “LittlevGL team” consists mostly of volunteers who spend their free time building and improving this excellent open source library.
If someone volunteers making some videos it could be nice, but I don’t think this is a priority. At least not for me.

It’s easy if you have Windows installed.
For many of us who only use Linux - it’s irrelevant.

I’m sorry to hear that.
I can try helping you, although I’m not sure what the problem is.
But I can tell you that many are building the binaries without any issues.

First step is to identify if the problem is related to Micropython or to lv_micropython.

  • Please try to build Micropython binaries without lvgl (not lv_micropython), in your environment. lv_micropython is based on Micropython, so let’s first see if that is building ok.
    Clone it, checkout version v1.12 and follow the README that explains how to build the ESP32 port.
  • Micropython v1.12 supports two versions of ESP-IDF. Before building Micropython you need to select one of them and checkout that exact version of esp-idf by checking out that specific hash.
  • When building the ESP32 you need to select your specific board. If your board is not supported, select a generic board or define your own board.
  • Another thing you can try is building the unix port instead of the ESP32 port, to see if the problem is limited to ESP-IDF or not.

If you get stuck there, then the right place to ask is the Micropython forum which you are already familiar with.

lv_micropython is based on Micropython v1.12, so once you can build Micropython it should be easy to move on and build lv_micropython.
The errors you showed us are related to ESP-IDF so I suspect they are related to building Micropython on your environment, and not related to lv_micropython.

Please try these suggestions and tell us how it goes.
Read all the docs, follow the instructions and I’ll try to help you if I can.

When you eventually succeed building it - you are welcome to make some YouTube videos as you suggested and share them with us!

3

I DID and built the micropython binary’s with no problem!
I am using Supported git hash (V4.0-beta1) that your package requires, and I can’t complete the build!
Those errors are displayed near the end of building.
You are not able to look at those errors and identify the possible cause(s)?

4

I’ve never worked with ESP-IDF (so I’m just working off the errors I see), but what you’ve shown makes it look to me like some files that are expected to be present don’t exist.

‘/home/rich/lvgl/esp/esp-idf/components/xtensa-debug-module/include’: No such file or directory
error: ‘printf’ was not declared in this scope

Is it possible that ESP-IDF isn’t downloaded fully?

OT: I saw on the forum thread you linked that you had tried the web simulator and it didn’t work. I recently fixed the web simulator in Chrome and it should be working now. https://sim.littlevgl.com/micropython/ports/javascript/bundle_out/index.html

5

No.
Because all your errors are related to ESP-IDF (under /home/rich/lvgl/esp/esp-idf/components).
lv_micropython does not change anything related to the way ESP-IDF is used.

Your errors don’t even make sense.

For example,

/home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp:35:5: error: ‘printf’ was not declared in this scope
printf("%s (%d)\n", FATAL_EXCEPTION, i);
^~~~~~
/home/rich/lvgl/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp:35:5: note: ‘printf’ is defined in header ‘’; did you forget to '#include '?

Looking at cxx_exception_stubs.cpp, it’s including <cstdio> which declares printf.
So, from the error, it looks like on your environment <cstdio> does not declare printf!

6

Possibly there were other errors closer to the beginning (i.e. where … loads of errors was put) that were more useful?

7

lvgl-error-output.txt (382.0 KB)
see this micropython post…
https://forum.micropython.org/viewtopic.php?f=18&t=7552

I think this problem is also Makefile related

8

You said that you built Micropython (v1.12), why didn’t you see the same problem there?

Anyway, please try their PR, if it works well I’ll integrate it into lv_micropython.

9

As I stated in the micropython forum…

Or better yet if someone can make completed binaries, this would be great!
I think LittlevGL should also have a download page with firmware’s like Micropython does. Having pre-built binaries gives new developers the opportunity to get right to coding, testing, and evaluating LittlevGL without all the “building” hassles.

I seriously do not have the time nor the understanding of the Linux make build system to do these tools justice.
I would greatly appreciate if someone would Port ESP32 GENERIC and GENERIC-SPIRAM
binaries with IL9341 driver using esp-idf v4.0 and post them here.

make -C ports/esp32 LV_CFLAGS="-DLV_COLOR_DEPTH=16 -DLV_COLOR_16_SWAP=1" BOARD=GENERIC_SPIRAM PYTHON=python2 deploy
10

The problem with your request is that a given binary will only work for specific board with specific display with specific ESP-IDF with specific lvgl configuration (lvgl is configured by changing lv_conf.h).
Any combination of these means different binaries.

Have a look how many different binaries Micropython provides only for ESP32. I counted 17 different binaries!
And this number needs to multiply by the number of lvgl specific configurations.

So I understand your desire to skip the build process and “just use a binary”, but as things currently stand, if you want to use lv_micropython you need to carefully configure it for your specific needs and build it yourself (or hire someone who would do it for you, if you “don’t have the time nor the understanding” as you said).

1 Like
11

In my humble opinion, it’s difficult as an open source project to provide prebuilt binaries for embedded hardware. New boards are always being released, and (as @amirgon mentioned) even one board can have many different configurations.

Our approach thus far has generally been to offer simulator projects for the PC that don’t require much effort to set up and start using, and make porting LittlevGL to a new platform as simple as possible. The idea is that if you find LittlevGL useful, you’ll be willing to undergo the effort required to get it working on your hardware.

We do have a number of starter projects available for common evaluation boards, but these usually end up being made available because one of us uses that board as a test platform for changes. These projects also suffer from the issue of rapid evolution. For example, we do not have any STM32H7 project available despite that chip having been released in 2017. It’s not a huge problem, because we do have an STM32F7 project and the two processors are very similar, but it’s still something that would be nice to have.

Keep in mind that lv_micropython is a very recent innovation. Support was only added 1 year ago. Therefore, it hasn’t had as much time to evolve and get tested as LittlevGL itself (although @amirgon does an excellent job of keeping it up to date and bug-free :+1:).

Perhaps, in the future, we could consider offering pre-built binaries, but I think it’s too early for that at the moment, and we don’t have the resources available to maintain enough binaries for all boards at the moment.

I’ll CC @kisvegabor on this conversation in case he has any other thoughts.

1 Like
12

I’m encountering the same problem. So far:

  • I can build lv_micropython using the 3.3 toolchain/esp_idf. However that build does not have ubluetooth.
  • I can build micropython/master using the 4.0 toolchain/esp_idf and following the steps described in the relevant readme.
  • I get the same errors if I try to build lv_micropython using the 4.0ß toolchain/esp-idf. I am following the relevant readme. It is as if the 4.0ß esp-idf has a bug somewhere.

So my question is: has someone been recently able to build lv_micropython with the 4.0 esp-idf using make -C ports/esp32 LV_CFLAGS="-DLV_COLOR_DEPTH=16 -DLV_COLOR_16_SWAP=1" BOARD=GENERIC_SPIRAM ? If so how?

13

Hi @fstengel!

Micropython does not support every esp-idf version.
It supports only specific versions, as specified in the Makefile.

Micropython requires changes and fixes in order to work with different versions of esp-idf.
There is some discussion over this on Micropython GitHub:

Regarding lv_micropython, which is a fork of Micropython -
I try to align it to major Micropython releases (latest is v1.12), so lv_micorpython is compatible with esp-idf versions supported by Micropython v1.12.

14

Hi @amirgon

First of all thank you for the extensive work produced in making lgvl and micropython work together.

I am fully aware that only specific versions of the esp idf work when compiling any version of micropython. That is why I asked the quesiton. My methodology for testing is:

  1. Create a new lubuntu (18.04 LTS) virtual image in virtualbox
  2. Install the various items required to develop. Especially using point 1. of the build instructions found in the root readme.md.
  3. Follow the guide to build micropython. That is following both the readme.md found in the root of the project and the one found in ports/esp32. I pay a particular attention to the esp-idf hash.
  4. Try to compile mpy-cross, then micropython.
  5. Destroy the image before making another attempt

I did this for (micropython/master, idf 4 hash 463a9d8), (lv_micropyton, idf 3 hash 6ccb4cf), (lv_micropython, idf 4 hash 310beae). The first two work without any problem, the last one fails as shown in the original message. So there must be something weird with the version of the esp idf V4 used, or one has to install something extra to make it work.

This is why I asked whether anybody has been recently able to compile using esp-idf 4 hash 310beae.

15

As the op of this…my “issue” was in the make file (as I referenced on feb-26)

Using…
git checkout 310beae373446ceb9a4ad9b36b5428d7fdf2705f
.
I saw a xtensa path error in my build, so I did this first…
changed all path occurrences of xtensa to xtensa-debug-module in the Make fie.
Then I also applied this fix…

image
image.png870×130 10.5 KB


I was then able to build!

The path change and flipping the order of the includes where both done at the same time.
If you see a xtensa path error… just change the path first and test.
And if that does not get you thru, then try apply the flipping the order of the includes change.

I hope this helps!
It took me days to get this to work and have no idea why these changes were necessary.
I was just following the the basic build instructions as insidious as they are.

image
image.png1291×174 15.8 KB

I am no git expert… but are updates in micropython automatically reflected in lv_micropython ??

16

@GC-RmG wrote :

And I could compile. So the issue was with that switch. I would never have found it by myself. Basically, I applied the patch and everything went well. I stll need to try the build firmware to see if everything really works…

Thanks again

17

I just flashed the resulting firmware on my M5Stack and played a bit with it. It seems to work. Now, if I could just change the version string from 1.9.4-xxx to 1.12-yyy. I think one has to toy around with git tags…

18

Glad that worked for you !!!
That fix was applied to the master micropython branch.
it appears no maintenance is being performed.
lv_micropython has not appeared to be updated since 1-17-2020 !
I also get on boot…
a) flash read err, 100
b) Chip revision…
c) incorrect version 1.9.4 (1.12 is used)
Do not get the issues with pure micropython builds.

image
image.png1219×535 36.3 KB

I currently also have have other problems.

Support is almost nonexistent as stated at the beginning of this thread…

Without a huge following, fixes are going to be non-existent unless one is very familiar with the code.
Me personally I might have to look for a commercial package as my project is not for fun.
Good luck.

19

I also exierience issues b ad c. My boot sequence is not showing issue a.

For issue b : I do not think it is a real problem. It basically tells you that the firmware can run on a revision 0 chip and since yours is revision 1, well it will run. If it bothers you, add the line

CONFIG_ESP32_REV_MIN_1=y

in, say, ports/esp32/boards/sdkconfig.base. Personnaly, I would create a “personal” board that would be derived from TINYPICO.

For issue c, I think one simply has to change the git tag. I’ll have to check things out.

20

I guess my question is why do binary’s from micropython, not exhibit these outputs?
My project is using an ESP32 Wrover now, things could change later.