Question Details

No question body available.

Tags

c esp32 lvgl

Answers (1)

Accepted Answer Available
Accepted Answer
March 2, 2026 Score: 3 Rep: 34,116 Quality: Expert Completeness: 60%

Caveat: I'm not too familiar with ESP32 or LVGL but I am familiar with HW/SW frame buffers.

Your LVCANVASBUFSIZE call is incorrect. You give the 4th arg as 0. This is the stride argument. [If you don't already know] the "stride" is the number of bytes between two rows (e.g.) pixel 0 on row 0 and pixel 0 on row 1.

So, the 4th arg should be: CANVASWIDTH 4 (assuming the stride is CANVAS_WIDTH but for some setups, stride can be larger (e.g. roundup to some multiple based on row padding in the H/W)).

The amount of needed space for the buffer should be CANVAS_HEIGHT stride. So, approximately/minimally 230,400 or 0x038400 bytes.

Note that the "corruption" value is 0xFFFFFF00 which is the RGBA value for white (also in A2).

Based on image/segment maps, the area for the buffer should be in segment 3 starting at virtual address 0x42000020. But, from heapinit, there is an area at 0x3FCA9D88. These seem to be the only ones that are large enough to hold the buffer.

Looking at the register dump, register A5 is 0x3FCAD668. This is only reg that keeps things in the heap area large enough to hold the buffer. This is offset 0x38E0 from the start?

My guess (as is yours) is that the lvmalloc size is insufficient

I don't know enough about the specifics here, but I'd expect the 0x42000020 for the segment to match with the 0x3FCA9D88 from heapinit??? Maybe some further virtual translation?

It would help if you printed the return from lvmalloc (as well as the value of its argument).

You've got UART print working--great. But, it might help if you can get JTAG/gdb/whatever debugging working also.

Instead of doing lvcanvasfill_bg, you might try writing bytes directly into the buffer in a loop using 0xFFFFFF00 (with printf of the address). Adjusting how often you print (e.g. every 256 bytes) to narrow down the exact address of the failure.