Horizontal jitter on display Waveshare ESP32-S3-Touch-LCD-7 800 x 480, 8MB PSRAM, 8MB Flash, ST7262, GT911 #22553
-
PROBLEM DESCRIPTIONA clear and concise description of what the problem is. REQUESTED INFORMATIONMake sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Configuration output here:
16:27:58.868 MQT: Tester/stat/RESULT = {"NAME":"WaveShare7","GPIO":[1,1,1,1,1,1,1,1,640,608,1,1,1,1,1,1,1,1,1,1,1,1,6210,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":1}
16:27:59.068 MQT: Tester/stat/RESULT = {"Module":{"0":"WaveShare7"}}
16:27:59.279 MQT: Tester/stat/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO6":{"0":"None"},"GPIO7":{"0":"None"},"GPIO8":{"640":"I2C SDA1"},"GPIO9":{"608":"I2C SCL1"},"GPIO10":{"0":"None"},"GPIO11":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"0":"None"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"},"GPIO18":{"0":"None"},"GPIO19":{"0":"None"},"GPIO20":{"0":"None"},"GPIO21":{"0":"None"},"GPIO33":{"6210":"Option A3"},"GPIO34":{"0":"None"},"GPIO35":{"0":"None"},"GPIO36":{"0":"None"},"GPIO37":{"0":"None"},"GPIO38":{"0":"None"},"GPIO39":{"0":"None"},"GPIO40":{"0":"None"},"GPIO41":{"0":"None"},"GPIO42":{"0":"None"},"GPIO43":{"0":"None"},"GPIO44":{"0":"None"},"GPIO45":{"0":"None"},"GPIO46":{"0":"None"},"GPIO47":{"0":"None"},"GPIO48":{"0":"None"}}
Rules output here:
STATUS 0 output here:
16:30:17.314 MQT: Tester/stat/STATUS = {"Status":{"Module":0,"DeviceName":"ES117-Tester3","FriendlyName":["Tasmota"],"Topic":"Tester","ButtonTopic":"0","Power":"1","PowerLock":"0","PowerOnState":0,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":1,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
16:30:17.322 MQT: Tester/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"Test","OtaUrl":" ","RestartReason":"RTC Watch dog reset digital core and rtc module","Uptime":"0T00:19:25","StartupUTC":"2024-11-27T05:10:52","Sleep":50,"CfgHolder":4617,"BootCount":28,"BCResetTime":"2024-11-27T06:10:17","SaveCount":63}}
16:30:17.328 MQT: Tester/stat/STATUS2 = {"StatusFWR":{"Version":"14.3.0.7(2322646-lvgl-haspmota)","BuildDateTime":"2024-11-26T10:56:16","Core":"3_1_0","SDK":"5.3.1.241024","CpuFrequency":240,"Hardware":"ESP32-S3 v0.2","CR":"365/699"}}
16:30:17.334 MQT: Tester/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["BlackNightOffice","BlackNight"],"TelePeriod":0,"Resolution":"558180C0","SetOption":["00008029","2805C80001000600003C5A0A192800000000","000000C8","00006000","00004000","00000000"]}}
16:30:17.347 MQT: Tester/stat/STATUS4 = {"StatusMEM":{"ProgramSize":2669,"Free":210,"Heap":145,"StackLowMark":18,"PsrMax":5568,"PsrFree":4693,"ProgramFlashSize":8192,"FlashSize":8192,"FlashChipId":"1740C8","FlashFrequency":80,"FlashMode":"QIO","Features":["0809","9FAAD7DF","0005A021","B7F7BFCF","05DA9BC4","60360DC7","C80840D2","20200000","D4BC483D","810A80F1","00000014"],"Drivers":"1,2,!3,!4,!5,!8,9,10,11,12,13,!14,!16,!17,!20,!24,26,!27,29,!34,38,50,52,54,55,!56,!59,!60,62,!63,!66,!67,!68,!73,!75,81,82,!86,!87,!88,!121","Sensors":"1,2,3,5,6,7,8,9,10,11,12,13,14,15,17,18,19,20,21,22,26,31,34,37,39,40,42,43,45,51,52,55,56,58,59,64,66,67,74,85,92,95,98,103,105,109,127","I2CDriver":"7,8,9,10,!11,!12,13,14,15,17,18,20,24,29,31,!36,41,42,!44,46,48,58,59,62,65,69,76,77,82,89"}}
16:30:17.360 MQT: Tester/stat/STATUS5 = {"StatusNET":{"Hostname":"ES117","IPAddress":"192.168.2.117","Gateway":"192.168.2.254","Subnetmask":"255.255.255.0","DNSServer1":"192.168.2.254","DNSServer2":"0.0.0.0","Mac":"24:EC:4A:03:0F:48","IP6Global":"","IP6Local":"fe80::26ec:4aff:fe03:f48%st2","Ethernet":{"Hostname":"","IPAddress":"0.0.0.0","Gateway":"0.0.0.0","Subnetmask":"0.0.0.0","DNSServer1":"192.168.2.254","DNSServer2":"0.0.0.0","Mac":"00:00:00:00:00:00","IP6Global":"","IP6Local":""},"Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":19.0}}
16:30:17.367 MQT: Tester/stat/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.2.100","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_030F48","MqttUser":"mymqtt","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
16:30:17.373 MQT: Tester/stat/STATUS7 = {"StatusTIM":{"UTC":"2024-11-27T05:30:17Z","Local":"2024-11-27T16:30:17","StartDST":"2024-10-06T02:00:00","EndDST":"2024-04-07T03:00:00","Timezone":99,"Sunrise":"05:54","Sunset":"20:22"}}
16:30:17.384 MQT: Tester/stat/STATUS10 = {"StatusSNS":{"Time":"2024-11-27T16:30:17"}}
16:30:17.406 MQT: Tester/stat/STATUS11 = {"StatusSTS":{"Time":"2024-11-27T16:30:17","Uptime":"0T00:19:25","UptimeSec":1165,"Heap":145,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":99,"MqttCount":1,"Berry":{"HeapUsed":29,"Objects":545},"POWER":"ON","Wifi":{"AP":1,"SSId":"BlackNightOffice","BSSId":"B0:BE:76:2E:95:12","Channel":9,"Mode":"HT40","RSSI":100,"Signal":-38,"LinkCount":1,"Downtime":"0T00:00:06"}}}
Console output here:
No errors seen, just these updates
16:33:03.150 TS : touched x=91 y=453 gest=0x00 (raw x=91 y=453)
16:33:03.252 TS : touched x=91 y=453 gest=0x00 (raw x=91 y=453)
16:33:03.348 TS : released x=91 y=453 (raw x=91 y=453)
16:33:03.400 LVG: Refreshed 12705 pixels in 4 ms (3176 pix/ms)
16:33:03.517 LVG: Refreshed 32000 pixels in 8 ms (4000 pix/ms)
16:33:03.559 LVG: Refreshed 32000 pixels in 8 ms (4000 pix/ms)
16:33:03.598 LVG: Refreshed 32000 pixels in 9 ms (3555 pix/ms)
16:33:03.634 LVG: Refreshed 32000 pixels in 8 ms (4000 pix/ms)
16:33:03.668 LVG: Refreshed 32000 pixels in 8 ms (4000 pix/ms)
16:33:03.689 LVG: Refreshed 32000 pixels in 8 ms (4000 pix/ms)
16:33:03.718 LVG: Refreshed 32000 pixels in 9 ms (3555 pix/ms)
16:33:03.751 LVG: Refreshed 32000 pixels in 9 ms (3555 pix/ms)
TO REPRODUCESteps to reproduce the behavior: autoexec.be: pages.jsonl: display.ini: EXPECTED BEHAVIOURA clear and concise description of what you expected to happen. SCREENSHOTSIf applicable, add screenshots to help explain your problem. In this pic, LEDs look correct but color wheel does not (page1) In this pic the gauges are rendered really poorly (page2) ADDITIONAL CONTEXTAdd any other context about the problem here. It took me a while to get the 16 data pins correct for color, but I believe this is verified correct by the 5 red, 6 green and 5 blue virtual LEDs. Each one changed by one significant bit. I have also tried flashing the device with lvgl-micropython. I've used the same display parameters here, as I did in the lcgl-micropython rgb_display driver. Under that framework there is no glitching, the display is rock solid even with fast data charting and all the widgets I've tried so far display properly. (Please, remember to close the issue when the problem has been addressed) |
Beta Was this translation helpful? Give feedback.
Replies: 15 comments 36 replies
-
|
Multiple problems here. Unfortunately I don't have such a large display, I have only 480x480. Is it possible to have a short video. There are at least 2 possible causes for glittering, and visible artifacts are very different in both cases |
Beta Was this translation helpful? Give feedback.
-
|
Also there seem to be a RGB mapping problem which makes the gradients look so bad |
Beta Was this translation helpful? Give feedback.
-
|
Can you try this: Details:
|
Beta Was this translation helpful? Give feedback.
-
|
Do you have the parameters of ST7262 from Micropython for this display? This would help a lot because there are MANY parameters |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much @s-hadinger , I'll try tonight after work. I note the SPI initialization, but an SPI port doesn't appear to be used for display on this board at all. ST7262 timing from datasheet Waveshare pin assignments. From the datasheet max DCLKP is about 25MHz, my/our clock frequency is about half that. Following on from this I believe that all the figures in this table which have the 'Unit measure' as DCLK should be doubled to reflect this. In micropython I tried both the min and max of these new values for all porch widths and pulse widths. Bottom line no effect, same as the idle_low settings, no impact at all. If I pushed past some of these limits there was failures. DCLKP is definitely active low (falling edge) The following appears to work perfectly under lvgl_micropython on the same board. If I used exactly the same data pin assignments on Tasmota the RGB (565) displays as BRG, (556) so I needed to swap the bytes around. Obviously not entirely correct. |
Beta Was this translation helpful? Give feedback.
-
|
Small glitch example, always to the right. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at schematic there doesn't appear to be any I2C or SPI connections between ESP and ST7262 which would allow for configuring registers. Only the RGB interface is exposed. I would have to assume that the default startup register configuration is suitable, as is, for the lvhl_micropython rgb_driver on this particular board.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks. The glitch does look like an interrupt that breaks the flow of data from PSRAM. Let's address this later. From the pinout and the Micropython, your first line should be (pinout was mixed up): |
Beta Was this translation helpful? Give feedback.
-
|
I was only talking about the RGB code for ESP32-S3, where there are three code paths in |
Beta Was this translation helpful? Give feedback.
-
|
Yes. Thanks for that. Indeed the rotation code was not ported, and we could get it for free. |
Beta Was this translation helpful? Give feedback.
-
|
So this would be my proposal based on the assumption about byte swapping being requested only via display.ini and not via pushColors(): |
Beta Was this translation helpful? Give feedback.
-
|
That's a good assumption, please write it explicitly in the comments. Also you can add logging to indicate that requesting byte_swap to pushColors is not supported (just in case) |
Beta Was this translation helpful? Give feedback.
-
|
Created PR #22970. |
Beta Was this translation helpful? Give feedback.
-
|
Hello there. Same im allready 3 days struggling to get this display work with TASMOTA. Here is my berry driver: Adding :B parameter solves big/little ending problem, so the colors are now allright. The only problem is still glitching same as described by Mark. Did many tests, but the only option for this display to stop glitching with tasmota is to force it work somehow with lower DCLK, usually under 10 mhz, but i had no success with tons of configs to run it under 12 MHz. I have another 7ich display with EK9716 driver (Sunton), runing same resolution, but there i was able to run it on 8Mhz stable without glitching. But same for this display when set over 10Mhz. Anyone some idea to fix this mess with hi-res displays in Tasmota? |
Beta Was this translation helpful? Give feedback.
-
|
Have you measured the relevant clocks? |
Beta Was this translation helpful? Give feedback.
-
|
Will measuring the actual clock frequency help in solving this problem? If so I'll borrow an oscilloscope and measure. |
Beta Was this translation helpful? Give feedback.
-
|
It will rule out (or not?) that the clock is in the specs. |
Beta Was this translation helpful? Give feedback.
-
|
From my post two weeks ago, max clock frequency from spec is 27 MHz. It also shows a minimum of 23 - not sure why there is a minimum. So as far as I can tell we are only clocking at about half that max. Under lvgl_micropython I have a stable display as long as the clock is between 11.8 and 12.8. Below 11.8Mhz it crashes and above 12.8Mhz, over time the UI starts to walk horizontally - exactly what Kevin told me would happen. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Developer/s, Is it likely that this issue can be fixed at some point in the nearish future? Or is such a large displays (800 x 480) not really compatible with Tasmota, due to the size of the frame buffer? I have managed to get the display stable with lvgl_micropython, however I've now really embraced the Tasmota framework for many of my projects rather than MicroPython on ESP32 devices. I'm guessing that not many people are using such a large display (with RGB) , and as such might be at the bottom of your already busy lists. If possible I would just like an idea of where this sits so I can plan accordingly. Many thanks, for all your assistance so far. |
Beta Was this translation helpful? Give feedback.
-
|
Clock testing has been done with a 2GSa/s 12bit oscilloscope. The ST7262 DCLK frequency was not very stable so I've also shown min, max and deviation (I think it's 1 standard deviation, but the manual is not clear on this) taken over 1000 samples. Nothing, or just solid colours display at 11MHz or below. Between 12MHz and 23MHz the jitters get increasingly bad. At 24MHz I can no longer make out screen objects, I pushed it beyond the ST7262 max of 27MHz, all the way to 29MHz and dispaly was still working. Above 27MHz however the web GUI becomes very very slow to respond, almost to the point that I needed to reflash to get it going again.
I also looked at GPIO36 on the ESP32-S3-WROOM-1 module which I think is the SPI clock for on chip PSRAM and on module flash. The bursts were all exactly 40MHz. |
Beta Was this translation helpful? Give feedback.
-
|
Top waveform is the SPI CLK (GPIO36) the bottom is display clock (DCLK). I also tried the tasmota32s3-qio_opi_120 build, with exactly the same waveform results, although some haspmota content was not being displayed properly with this version
|
Beta Was this translation helpful? Give feedback.
-
|
I also tested many custom builds with same result. I saw a little deviation in default flash chip mode on arduino website. For every Waveshare ESp32 S3 board there is mentioned as default and only mode of flashing as DIO, not QIO. Even when tested with DIO, nothing changed in result. Also tryied to change LVGL os different ones including rtos, but this has nothing to do with jitters (tasmota build with rtos for lvgl is slowing tasmota core). I remember i had few similiar issues when using Openhasp and the problems with jitters at higher clocks were caused when WIFI was on, but turning wifi off has no effect there. PS: i dont think that driving display trought TTL-RGB interface is the best way to do it with ESP32+tasmota for many reasons. It consumes almost all gpio pins - custom display board developers solve this with adding cheap expanders with limited gpio abilities. And offcouse, ESP32 is multipurpose mcu, not only a display driver, so there are many possible points of failure. By my opinion, the best way to drive the large resolution display with esp32 is to use displays with QSPI interface, which is more than enough. If there is someone to try to integrate QSPI in tasmota, i will send him a display for free, just PM me. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, on the bright side, I have two devices with 480x480 RGB (esp32s3) displays without any flicker. So maybe the frequency required is just too high. Any recommendation for a cheap and fast to deliver (in France) display with 800x480? |
Beta Was this translation helpful? Give feedback.
-
Send me your address, phone and mail on [email protected] , ill send my ESP32-S3-Touch-LCD-7 . https://www.waveshare.com/wiki/ESP32-S3-Touch-LCD-7 Yes, these displays cant work stable under 10mhz (most of the did not even start), but 7mhz+ is the area where jitters are starting. |
Beta Was this translation helpful? Give feedback.
-
|
I own one of these Displays, too. Bought it some time ago, didn't get the display running that time. I tried an older Tasmota build, I run 14.1.0.4. My custom build doesn't include the color picker, not sure, but the scales also seem to look the same. BUT changing to another page runs without image disturbance! :) I just tested my custom firmware I use for the Sunton 7" touch displays. I spent three days (don't ask!) to get it running with touch, display AND I2S sound... It's not much more than the tasmota32s3-qio_opi build including USE_I2S_ALL in the end.... Oh, and I added to the user_config_override.h! Anyway, since the Waveshare also runs smoother using Tasmota 14.1.0.4 in comparison to 14.3 or 14.4 - just the same as the Sunton ESP32-S3 does - something new in Tasmota must interfere with the display.... Just give 14.1. a chance (I use 14.1.0.4 because that exact version was the latest in dev branch the time I first time got the Sunton 7" running), it's worth a try! :) |
Beta Was this translation helpful? Give feedback.
-
|
Wait... What? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for the tip. Indeed until v14.2 there is almost no flickering except a short burst when writing to flash. Last working commit: d716a27 First broken commit: 1248bd1 The bad news is that the problem was introduced by Arduino/esp-idf newer version. Let's see what we can do. |
Beta Was this translation helpful? Give feedback.
-
|
@MarkMakies @TheHexaMaster @bertlpower @s-hadinger |
Beta Was this translation helpful? Give feedback.
-
|
I just tested now with the latest version, I still get rare jitter, especially during Flash writes and some transitions. It's much much better than before. |
Beta Was this translation helpful? Give feedback.
-
|
For reference, here is the configuration for Waveshare ESP32-S3-Touch-LCD-7
|
Beta Was this translation helpful? Give feedback.
-
|
This board uses the I/O Extension Chip CH422 Works the SD-Interface ? Is CH422 supported by Tasmota? |
Beta Was this translation helpful? Give feedback.
-
|
I have not found support for CH422G in Tasmota, so I implemented it myself as a Berry class based on the datasheet and some existing drivers (e.g. for HA). It is not as versatile as the Tasmota support for e.g. the MCP23S17 though. You can find it here: https://github.com/treitmayr/tasmota-thermostat/blob/main/ch422g.be While my main objective is to use the DISP pin to be able to turn off the display (also for a little energy savings, as it draws ~800 mW), I have to say that I have serious problems using it for my purpose. But maybe for the SD interface the problems will not appear. For that interface you may need to assign the CS function to the pin, but I am not sure if and how this can be done in Tasmota for pins other than the main ESP pins. For the DISP line I solved this with a board-specific Tasmota driver: Maybe I should start a separate discussion on the DISP issue, but in short it seems to me that actively switching the respective pin from 0 back to 1 (3.3V) causes a slight power breakdown and the board restarts. I have to admit that I did not do any measurements though. Turning off the output drivers (i.e. switching them to input) does the trick in that the pull-up changes the line state a bit slower. But this strategy does not work when also trying to use the SD CS, because the chip can only switch all its GPIO to input/output at the same time. Still there is the possibility that I screwed up something in the driver or misunderstood how the chip works. Maybe you can find out more... |
Beta Was this translation helpful? Give feedback.
-
|
@treitmayr Yes, please open a new discussion for support of "CH422" It has nothing to do with the Jitter problem. |
Beta Was this translation helpful? Give feedback.
-
|
@treitmayr |
Beta Was this translation helpful? Give feedback.
@MarkMakies @TheHexaMaster @bertlpower @s-hadinger
Thx for all your Infos and tests. We finally found the bug and fixed it. The bug was in the Tasmota Arduino framework. The compiled and used
libesp_lcdwas not correctly build for the S3 when using OPI PSRAM.Fixed in latest Platform (2025.02.30) which is already merged and used in branch development.
My tests with a RGB 800x480 Display driven by an esp32-S3 with OPI PSRAM are without Jitter now.
Before it was not possible to find working settings where no massive Jitter occured