When I run my LVGL app I see random dots on the screen (green and blue as you can see). They are 100% same every time. It appeared after I updated my LVGL version. Sadly I do not have a record of my previous LVGL version so I am a bit sad on how to fix it. It kinda looks like debug dots, as they are very regular. I tested it on multiple devices. Any idea what I can to debug?
Are they random or always in the same place? if they are consistent, it is probably from the disp_flush function not sending the whole frame especially the last pixel. Otherwise if they are random, check the wires that goes to the LCD.
There’s two sets of dots: one on the far right edge of the screen, spaced at certain distance, and one set a pixel to the right of where the menu bar opens.
I will look at the disp_flush, thank you! It’s just so weird and strange.
I guess I can delete all the things on the screen, then put an if statement to see if it sends green color at all?
I encauntered the same problem a while ago. It was the disp_flush function sends all the frame pixels except the last one, hence the white dots at the end of each frame.
I suggest you manually call the disp_flush function and send some frames to the LCD before the Lvgl library is initialized. If the dots appear, then it is definitely from this function.
The disp_flush function takes an array of lv_color_t. Try something like this.
lv_color_t buf_1[50*50]; // I think it should be global variable
for (int i = 0; i<50*50; i++){
buf_1[i] = red;
}
disp_flush(NULL,&left_top,buf_1);
for (int i = 0; i<50*50; i++){
buf_1[i] = green;
}
disp_flush(NULL,&right_top,buf_1);
for (int i = 0; i<50*50; i++){
buf_1[i] = blue;
}
disp_flush(NULL,&middle,buf_1);
It seems sadly I can’t easily use LVGL_ESP32 driver without initializing LVGL as well. I tried several things, but it seems that LVGL_ESP32 init actually goes and initializes a timer that checks if SPI is free for a transaction. This causes it to crash in spi_ready code.
Also not sure why it’s drawing in the same place. Should I try to use the built in screenshot function to see what it " thinks" is on the display?
Mmm interesting. I am sorry I am not that familiar with RTOS.
It is very strange. Try to breakpoint on each flush call and see what has been drown each time breakpoint hits or enter a delay between flushes. I suspect if you are using DMA with SPI, you are changing the content of the buffer before the current dma transfer complete.
Also, could you post your disp_driver_flush function or just use the one in the github and try it out, it may work with you?
I had this same exact issue when I switched from 160MHz core clock / 100Hz FreeRTOS tickrate to 240MHz core clock / 1000Hz tickrate. I’m using an ESP32-S3 with ILI9488 and an 8-bit parallel interface. On the scope at the very start of transaction, the pins would be high too long and spill over into the next byte. This had the effect of creating mostly green dots in the top left of drawn regions, occasionally the position would be affected and rarer yet the whole frame would get corrupted.
I reduced my esp_lcd_panel_io_i80_config_t pckl_hz from 10MHz down to 5MHz and it appears to be working now. Also edited, I spoke too soon and made an incorrect statement about the periodic lvgl timer
Not sure if this is your exact issue or if you’ve solved by now but I found this post by Google, maybe it will help someone else.
