Screen shift when using write access to local FS (LittleFS/Fat Fs)

[luc-github]

Hello I am also working on this screen and found your repo I know you are not using any FS yet, but I though it worth asking you ^_^

I have found that doing write access using littleFS/FatFs on local FS make the screen to shift: https://github.com/luc-github/ESP3D-TFT/issues/18 I am wondering if you would have an idea of the root cause? Using SPIFFS or SD card seems not having same issue per my tests.

Additionnaly I have tested arduino configuration code, that use gfx driver (https://github.com/wegi1/ESP32-8048S070-7INCH-LCD/blob/main/1-Demo/Demo_Arduino/3_3-4_TFT-LVGL-Widgets/LvglWidgets/LvglWidgets.ino) adding a code of littleFs writing file and same issue happen, with one difference: once writing is done, the messy screen is auto recovering. at least would be great to have same solution in idf code but could not find what did it orz...

Just sharing with you, in case you have any idea please let me know

[MMlodzinski]

I have no idea what causes the problem. It seems to work fine when littlefs stuff go first and ui after, but then it messes up right on fstream open method. Maybe it breaks screen buffers? Please let me know if you figure it out.

[luc-github]

thank you for your feedback

I am thinking it may not be a software issue but more some design issue and may be EMI ? when writing on FLASH the pin used is generating some noise on sync pin of TFT that shift the screen ? but I am not electronician so it just a some guess based on my past experience and also based on fact none of others screen I used has such issue: http://esp3d.io/esp3d-tft/v1.x/hardware/index.html, but this one is also the only one that use the rgb drivers...

At least if can recover after writing is done like in arduino would be great - TBD - I will continue to investigate when I have time
I will also update here if I find something

[MMlodzinski]

There is section in ESP32 documentation about that issue. Refer to point 10 in that link.

[luc-github]

Wow good finding - I will experiment that Thank you

[luc-github]

Actually my sdkconfig matched almost all some suggestion (QIO 120 ) make the board not bootable but the setting : CONFIG_LCD_RGB_RESTART_IN_VSYNC=y allow to auto recover when write access is done - so it is a good start for mitigation - I will try others solutions proposed later

[luc-github]

I did several tests this morning and it seems decreasing PCLK to at least 6MHz make the screen not shifting (I have tested 2 / 4 / 5 / 6/ 7 MHz) In that case it seems CONFIG_LCD_RGB_RESTART_IN_VSYNC is no necessary as it is not recommended per documentation

I did not tried to have the default frequency to 8/12/16MHz then decrease it before access wait 20ms then increase PCLK to the original level after the access of FS but should be the way to go IMHO

Thank you a lot for your help ^_^

It was really a pleasure to exchange with you

I think issue / question can be closed here -have a great day

[luc-github]

Just applied the patch on my project and CONFIG_LCD_RGB_RESTART_IN_VSYNC neither CONFIG_COMPILER_OPTIMIZATION_PERF do not seem necessary anymore when using the esp_lcd_rgb_panel_set_pclk() but suggested delay of 20ms is not enough in my case, using 40ms make it work ^_^ 😸