LVGL sample failing to display properly on SHARP displayl

RE: LVGL sample failing to display properly on SHARP displayl

Christopher — Fri, 27 Mar 2026 21:41:11 GMT

Is this still the issue with nRF Connect SDK version 3.2.3?

RE: LVGL sample failing to display properly on SHARP displayl

Zeke — Wed, 06 Aug 2025 14:05:44 GMT

Thanks for all the help, but I have actually found out that it is the display buffer held for the monochrome display that wound up being too large. The memory reserves 8 bytes for the palette, so the memory kept 8 extra bytes in memory, but what I did not know was that these already had skipped the palette bytes, so the 8 bytes were leaking into other parts of the memory.

All I had to do was alter a function in the file lvgl_display_mono.c to ensure the right size buffer.

void lvgl_set_mono_conversion_buffer(uint8_t *buffer, uint32_t buffer_size)
{
	mono_conv_buf = buffer;
	
	// 8 palette bytes do not need to be altered
+	mono_conv_buf_size = buffer_size - 8;
}

RE: LVGL sample failing to display properly on SHARP displayl

Amanda Hsieh — Wed, 30 Jul 2025 13:32:40 GMT

Hi,

Kazi is out of the office, so I take this case.

I am no expert in LVGL, but my colleague has just been doing display_write makes LVGL take one buffer 16 or 18 bit. It seems like on 1bpp display, he was trying to read this discussion in the github issue number 1427 and it is possible that your LVGL buffer stays all 0x00 (black) because LVGL is writing a single‐bit brightness into each lv_color_t (which ends up in the LSB), and then the Zephyr flush simply spits out those bytes without repacking them into MSB-first pixel order. You might need to pack 8 pixels into one byte from MSB to LSB something like below

+#include <lvgl.h>
 #include <stdio.h>

-static void flush_cb(struct _disp_drv_t *disp_drv,
-                     const lv_area_t *area,
-                     lv_color_t *color_map)
-{
-    display_write(display_dev,
-                  area->x1, area->y1,
-                  &disp_buf_desc,
-                  (const void *)color_map);
-    lv_disp_flush_ready(disp_drv);
-}
+static void sharp_flush_cb(lv_disp_drv_t *drv,
+                           const lv_area_t *area,
+                           lv_color_t *buf)
+{
+    int w = area->x2 - area->x1 + 1; // important change, pack 8 LVGL pixels into 1 byte
+    uint8_t line[400/8];
+
+    for (int y = area->y1; y <= area->y2; y++) {
+        memset(line, 0, sizeof(line));
+        for (int x = 0; x < w; x++) {
+            if (lv_color_brightness(buf[x + (y-area->y1)*w]) > 128) {
+                line[x>>3] |= 0x80 >> (x&7);
+            }
+        }
+        display_write(display_dev, area->x1, y, &row_desc, line);
+    }
+    lv_disp_flush_ready(drv);
+}
+
+static struct display_buffer_descriptor row_desc = {
+    .pitch = 400,
+    .height = 1,
+    .buf_size = 400/8,
+};
+
+void main(void)
+{
+    disp_dev = device_get_binding(DT_LABEL(DT_CHOSEN(zephyr_display)));
+    if (!device_is_ready(disp_dev)) return;
+
+    lv_init();
+
+    static uint8_t buf[400*240/8 + 8];
+    static lv_disp_draw_buf_t draw_buf;
+    lv_disp_draw_buf_init(&draw_buf, buf, NULL, sizeof(buf));
+
+    lv_disp_drv_t disp_drv;
+    lv_disp_drv_init(&disp_drv);
+    disp_drv.hor_res = 400;
+    disp_drv.ver_res = 240;
+    disp_drv.draw_buf = &draw_buf;
+    disp_drv.flush_cb = sharp_flush_cb;
+    disp_drv.color_format = LV_COLOR_FORMAT_I1;
+    lv_disp_drv_register(&disp_drv);
+
+    lv_obj_t *lbl = lv_label_create(lv_scr_act());
+    lv_label_set_text(lbl, "Hello world!");
+    lv_obj_align(lbl, LV_ALIGN_CENTER, 0, 0);
+
+    while (1) {
+        lv_timer_handler();
+        k_sleep(K_MSEC(10));
+    }
+}
 
-void main(void)
-{
-    display_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_display));
-    if (!device_is_ready(display_dev)) {
-        LOG_ERR("Device not ready, aborting");
-        return;
-    }
-
-    lv_init();
-    lv_disp_draw_buf_init(&draw_buf, buf, NULL, sizeof(buf));
-    lv_disp_drv_init(&disp_drv);
-    disp_drv.hor_res = 400;
-    disp_drv.ver_res = 240;
-    disp_drv.draw_buf = &draw_buf;
-    disp_drv.flush_cb = flush_cb;
-    lv_disp_drv_register(&disp_drv);
-
-    /* … rest of sample … */
-}

instead of using Zephyr LVGL handling, he is using lv_disp_drv API here, use it as a template.

Regards,
Amanda H.

RE: LVGL sample failing to display properly on SHARP displayl

Zeke — Fri, 25 Jul 2025 22:02:33 GMT

Hello Kazi,

The board is the nRF54L15 DK. I do not know quite what you mean by application file, but I have added everything needed to reproduce the issue. I have attached a zip folder as well with the files.

devzone.nordicsemi.com/.../lvgl_5F00_2025.zip

RE: LVGL sample failing to display properly on SHARP displayl

Kazi Afroza Sultana — Thu, 24 Jul 2025 14:27:44 GMT

Hello Zeke,

Is this a custom board? Could you please share the application file so I can try to reproduce the issue?

RE: LVGL sample failing to display properly on SHARP displayl

Zeke — Wed, 16 Jul 2025 22:04:01 GMT

If you are referring to the LCD, the board is a LS0XX board, one which the driver had already come with the install of Zephyr and nRF Connect. When building the project, I use the nrf54l15/nrf54l15/cpuapp board target.

I am also using ncs v3.0.2.

RE: LVGL sample failing to display properly on SHARP displayl

Kazi Afroza Sultana — Wed, 16 Jul 2025 07:09:21 GMT

Hello,

The Bus error seems display driver is not fully compatible with the zephyr display API as expected by LVGL which results a NULL or invalid function pointer dereference in display_write().

Is this a custom board? which NCS you are working on?