ERROR lv_bindings/driver/generic/modlvindev.c

I also agree

I was able to build an ESP32 firmware by:

  1. casting (mp_rom_error_text_t)whenever I got the error with the incompatible pointer cast
  2. as hinted, changing mp_instance_cast_to_native_baseinto mp_obj_cast_to_native_base whenever the problem appeared.

This being said, I have not tried that firmware. I’ll dot that momentarily and I’ll keep the forum posted.

I have not tested the firmware extensively. I basically ran a very short test interface using lvgl. It looks as if it works. Fingers crossed :crossed_fingers:

I am not at all familiar casting or the C language.
Could you show in more detail your method(s).
It would be immensely appreciated !!!

My workflow was very basic:

  2. I looked at the error log and performed the alterations.
  3. Went back to point 1 until there were no more errors…

What alterations did I perform?

  1. For the error: passing argument 2 of 'mp_obj_new_exception_msg'... error I did as follows. For instance in lib/lv_bindings/driver/generic/modlvindev.cI changed line 131 from:
               &mp_type_RuntimeError, "indev instance needs to be created before callback is called!"));


               &mp_type_RuntimeError, (mp_rom_error_text_t) "indev instance needs to be created before callback is called!"));
  1. For the error error: implicit declaration of function 'mp_instance_cast_to_native_base', I changed ‘mp_instance_cast_to_native_base’ to ‘mp_obj_cast_to_native_base’ as in line 98 of ports/esp32/build-GENERIC_SPIRAM/lvgl/lv_mpy. In that file I changed line 98 from
   return mp_instance_cast_to_native_base(mp_obj, MP_OBJ_FROM_PTR(native_type));


   return mp_obj_cast_to_native_base(mp_obj, MP_OBJ_FROM_PTR(native_type));

I do not remember how many modifications I made, but there were a lot (50-ish? in about half a dozen files, some of them generated: those in build-GENERIC_SPIRAM…)

Man aren’t you the ambitions one !!
Can we expect an update any time soon ??
Is this a one-time thing or on every build?

p.s. where is this error log?

@fstengel -
lv_mpy.c is a generated file.
If you don’t want to change it on every build, better change which contains the templates from which lv_mpy.c is generated.

Yes, I just discovered that. “only” 8 thingies that need to be changed. Being a noob with git, I’m not quite sure on howto submit a patch/diff to cover the modifications. However lv_mpy is not the only file that needs to be patched. Some seem to be generated (mp_lodepng.c for instance), but I also had to patch at least: modrtch.c, modILI9341.c, modlvindev.c and modxpt2046.c. What’s weird is that those are all drivers.

Since lv_micropython is aligned to official releases of Micropython, it does not make sense to accept patches on the mainline that are not aligned with the supported Micropython release.

But we can probably accept it on a branch, for people who want a more up to date Micropython/esp-idf.

Fair enough. What I could do is describe what I did in order to be able to build lv_micropython with the latest of micropython/master which is quite a few commits ahead of the version found in the lv_micropython github repo.

fstengel… your the man !!

I started by forking lv_micropython (, followign the usual method (git clone-recurse-submodules xxx etc.) and then followed what is exposed in the post linked below

If you’d like to update lv_micropython manually, you should be able to clone it and then run the following commands:

git remote add micropython
git fetch micropython
git merge micropython/master

It’s quite possible you’ll have to resolve some merge conflicts but that will give you all of the latest changes in Micropython.

I modified the offending files and pushed the whole lot to my repo. You can start with this repo. But your work is not finished.

Now, there are 5 files that are part of the lv_bindings submodule. I can modify them, but I do not know how to push them (and I dare not messing up the lv_bindings repo…) the files are (the root is lv_bindings):

  • gen/
  • driver/generic/modlvindev.c
  • driver/esp32/modILI9341.c
  • driver/esp32/modrtch.c
  • driver/esp32/modxpt2046.c

In those files I had to:

  1. search for mp_obj_new_exception_msg (there are two variations) and place a (mp_rom_error_text_t) before the string that appears as a second argument
  2. in search for mp_instance_cast_to_native_base and replace it with mp_obj_cast_to_native_base.

As far as I can tell that is all I had to do in order to be able to compile lvgl with micropython/master and esp-idf V4.

is this correct… 7 locations
modlvindev.c 1 location
modILI9341.c 2 locations
modrtch.c 1 location
modxpt2046.c 2 locations

Ouch, no. Sorry for my lack of clarity. Your lines 549-550 should look like this:

            &mp_type_SyntaxError, (mp_rom_error_text_t) "Can't convert %s to %s!", mp_obj_get_type_str(mp_obj), qstr_str(mp_type->name)));

What this does is forcing the string to become an object of type mp_rom_error_text_t

And you have to repeat it for the 13 locations you found. Basically insert the (mp_rom_error_text_t) just before the " of the string…

If somebody proficient in git could give me a way of pushing the modifications I did in the lv_bindings submodule, without messing up the original, that would help a lot…

THANK YOU VERY MUCH " fstengel" !!!
I feel much better that I am using the most recent release!

Is there any way that the correct version is displayed?
again thank you !

Weird. My boot sequence shows:

ets Jun  8 2016 00:22:57

configsip: 0, SPIWP:0xee
mode:DIO, clock div:2
entry 0x40080638
MicroPython v1.12-635-g269836295-dirty on 2020-04-12; ESP32 module (spiram) with ESP32
Type "help()" for more information.
>>> help("modules")
__main__          gc                uasyncio/core     uos
_boot             ili9341           uasyncio/event    upip
_onewire          inisetup          uasyncio/funcs    upip_utarfile
_thread           lodepng           uasyncio/lock     urandom
_uasyncio         lvesp32           uasyncio/stream   ure
_webrepl          lvgl              ubinascii         uselect
apa106            machine           ubluetooth        usocket
btree             math              ucollections      ussl
builtins          micropython       ucryptolib        ustruct
cmath             neopixel          uctypes           utime
dht               network           uerrno            utimeq
ds18x20           ntptime           uftpd             uwebsocket
esp               onewire           uhashlib          uzlib
esp32             rtch              uhashlib          webrepl
espidf            sys               uheapq            webrepl_setup
flashbdev         uarray            uio               websocket_helper
framebuf          uasyncio/__init__ ujson             xpt2046
Plus any modules on the filesystem

Notice the two differences: the version and the size of the second segment. My board (a M5Stack) does not show the flash read error either.

Just for reference I am using a
WEMOS LOLIN D32 Pro V2.0.0 ESP32 wrover

I downloaded your repo, made the changes, flashed…
and this is what I got
How can my binary be different than yours?
Also why -dirty why not -lvgl or somthig

more info…



 (name='micropython', version=(1, 12, 0), mpy=10757)

Sigh. My git-fu is really not up to standard :cry: Basically, the tag that builds the version message (v1.12 vs v.1.9.4) did not go through. Go figure. As far as I can tell, the -dirty suffix comes from the fact that this is several commits since the last release. You get that also in official downloads.

Thank you you’ve been extremely helpful and informative.