LVGL 9.2 + esp32-s3 + display axs15321b

Hi,
I’m trying to port LVGL on a board with esp32-s3 and axs15321b display (QSPI)/touch driver(I2C).
I’m using LVGL 9.2.2 and esp_lvgl_port esp-idf 5.3.1 in ESP-IDE.

At the moment I have a firmware with LVGL that seems working, display shows and touch senses.
But I have problem during event widget refresh.
For example I have a code where I simply show a button with a callback on click event.
On first button display out, before any user interaction, the display shows the widget.
On click the rendering fails.

Here you have a screenshot before and after the “button100” press.

It seems something related to task concurrency in esp_lvgl_port library ?
Have you any suggestion where I could look at or something else to try?

Thanks to all of you.


Hi,
okay, after a lot of tries (… and sleepless nights :-)), I found that something goes wrong with partial buffer display rendering because via fulll refresh, the display seems working great… :slight_smile:
Now, I’m digging deeper about partial buffer corrupt displaying…
Byte… sorry, bye!

Would you mind sharing your code for this?
I’m having a hard time getting my display (JC3248W535) going with esp-idf and esp_lvgl_port and I’m banging my head against a wall right now it seems. lol
Thanks :slight_smile:

I got LVGL 9 working on JC3248W535

You must use display refresh FULL instead of partial

and then use PSRAM for the render buffers so they don’t take all the SRAM

PSRAM is fine because the sample code copies the image one slice at a time (1/10 screenful) into a 1/10 size SRAM buffer to rotate (if needed) and send to the screen via DMA while it works on the next slice. There is no attempt to use DMA to send direct from PSRAM straight to LCD so it works.

Drawing on this screen works correctly as long as it is done in slices that are the full “Width” of the screen (And by this, i mean the slices are 320 pixels long, to match the axis of the screen that is also 320 pixels long, however you define it.)

it may be a drag to update the full screen but JC3248W535 has 8 bit access to both the PSRAM and the LCD so speed is not terrible. Potential optimization for anyone editing the source of LVGL 9 is to update the refresh routines to expand invalidated regions of the screen to always match the 320 side so partial updates could be sent, just always 320 in length so the screen will still draw them without errors. could be invented as a STRIPE update method, alongside FULL and PARTIAL…