XP2046 touch failure with esp32s2 and lolin 2.4 tft

[dkebler]

I've been discussing my issue with xp2046 touch using esp32s2 with @sfromis in the display channel of discord.
https://discord.com/channels/479389167382691863/800751039283200050/1172257549903466516

I've since done a bit of investigation and putting my results here so this issue can be discussed in an async way. I'm willing to do whatever to resolve this but I do need some help being pointed in directions and even compile my own firmware as necessary. Thx.

---

investigation of failed touch input with lolin 2.4tft (xp2046) using esp32s2 d1 mini.

hardware:

https://www.wemos.cc/en/latest/d1_mini_shield/tft_2_4.html
https://www.wemos.cc/en/latest/s2/s2_mini.html

I have checked the connections from the boards esp header to the xp2046 chip and I can confirm that the spi clock,miso,mosi are connected to both to tft and xp2046 per the schematic. This is my understanding that the touch and tft share these three and then each has their own CS which again I checked and the TS-CS is going from D3/18 to the xp2046. The bottom line is that it seems everything is "connnected" as it should be and the corresponding tasmota template has correct pin assignments.

Firmware

per lvgl binary defines at https://github.com/arendst/Tasmota/blob/development/tasmota/include/tasmota_configurations_ESP32.h#L308-L514
#define USE_XPT2046 #define USE_DISPLAY_LVGL_ONLY
are set and thus per
https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_55_touch.ino#L39
the appropriate code for touch should be enabled in particular the block at
https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_55_touch.ino#L248
but what is not clear is if
#define ESP32 was ever set for the compilation (s2 or otherwise) as !!! critically it must be set or the SPI gpio pins will not be known
https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_55_touch.ino#L258

Testing (CALIBRATION)

So assuming all is fine with the firmware compile per above
Then according to this https://tasmota.github.io/docs/LVGL/#calibrate-a-resitive-touch-screen
I need to calibrate the tft for touch (since it uses xp2046 chip)

I loaded the DisplayCalibrate.tapp and edited the display.ini to add

:TS,*
:M

https://github.com/tasmota/docs/blob/master/docs/Displays.md
my understanding is :TS with wildcard will pick up pin 18 in the template. I run CalibrateDisplay and the calibration screen appears per https://tasmota.github.io/docs/LVGL/#calibrate-a-resitive-touch-screen After the calibration then the proper values for :M are set but this FAILS because there is no recognized touch input.

CONCLUSIONS

If I had to guess I would say this is NOT a hardware issue but a firmware issue. And if I was to point a finger I would guess that the compile switch ESP32 was not set and therefore the SPI gpio pin assignments are unknown to the touch code and thus it fails.

This might be because the esp32s2 compilation is maybe not same as the regular esp32 code. Which might explain why XP2026 might be working for others but not for me (as I am using the s2 chip variant).

So first where is #define ESP32 set not in that ESP32.h file, it's not there anywhere.
I will also set up a normal wrover dev board with this same lolin tft to rule out the s2 being the issue.

Instance INFO

firmware and hardware as reported in UI, I installed tasmota32s2-lvgl.factory.bin

[sfromis]

Your speculation about lacking define of ESP32 does not hold. As a simple check, the command Info (not in docs, but never mind) is only available contingent on #ifdef ESP32 and it does respond with tasmota32s2-lvgl.bin flashed.

The build process is a lot more involved than expecting all #define symbols to come from the source code files.

[Jason2866]

#ifdef ESP32 is true for all MCUs from the esp32 series.

[dkebler]

So the defines/headers are no way any different for regular wrover vs s2 variant. regardless of the chip variant that same header and touch ino file is used.

ok then running out of ideas. given

1. lolin doesn't sell a touch screen using the xp2046 chip that doesn't work (many examples of alternative firmware working with touch e.g http://www.esp32learning.com/code/lolin32-and-2-4-tft-lcd-touch-screen-shield-example.php
2. s2 vs standard esp32 is not the problem. I did not buy this directly from lolin so possible it's a bad knockoff, but I am right now trying to get a wrover dev board working with the lolin tft.
3. Tasmota firmware/build (s2-lvgl) including proper defines is good?
4. Connections are fine (everything is connected correctly for the xp2046 chip, checked right to pins on chip itself)
5. display.ini correct (added the :TS,* to https://github.com/arendst/Tasmota/blob/development/tasmota/displaydesc/ILI9341_display.ini) is there something else not correct in that file?
6. Tasmota template is correct (checked multiple times plus everything works except the touch and I have triple checked that the template is using the right pin for XP2064_CS and that pin is connected exactly to the CS pin on the chip.
7. powered via 3.3 external power, no difference.

@sfromis since you actually have the exact same hardware (lolin tft, esps2 mini) can you help at least with a way I can "debug" the firmware. At this point I have no specific way of knowing if the touch.ino code is running correctly.

[sfromis]

There are differences in what #define values are in force depending on what chip variant is targeted, like USE_ESP32_S3 or USE_ESP32_SOLO, I just observed that ESP32 is general for all ESP32 variants.

Are you saying that you got the same issue with both ESP32-S2 and "classic" ESP32? Or did your point 2 mean something else.

I'm seeing the same with my ESP32-S2 Mini (original Wemos) + ILI9341 Wemos shield, but as I'm not very familiar with the requirements around touch, display drivers and build variants, I have no firm answers for what may be missing, or not.

When it comes to debugging, I've not moved in the direction of developer-level involvement in drivers etc, and thus not "knowing if the code is running correctly".

[dkebler]

btw the weblog now shows this line during boot
00:00:00.143 TS: XPT2046
indicating that the :TS was activated?

[sfromis]

In my understanding, he got to the point of the display working as expected, except for touch, which then became the priority.

[dkebler]

@sfromis is correct. tft sans touch is working fine including demo tapp

[sfromis]

Activating Weblog 4 also shows touch working to some extent, touching/releasing a button gives messages like:

13:19:39.162 TS : TSGlobal.touched x=320 y=240 (raw x=1908 y=1401)
13:19:39.257 TS : TSGlobal.touched x=320 y=240 (raw x=1957 y=1589)
13:19:39.358 TS : TSGlobal.touched x=320 y=240 (raw x=1985 y=1619)
13:19:39.464 TS : TSGlobal.touched x=320 y=240 (raw x=2004 y=1665)
13:19:39.564 TS : TSGlobal.touched x=320 y=240 (raw x=2010 y=1641)
13:19:39.662 TS : TSGlobal.touched x=320 y=120 (raw x=2114 y=1586)
13:19:39.758 TS : released x=320 y=120 (raw x=2114 y=1586)

With x and y being either 0 or 320/240/120, mostly screen edges even when not touching at the edge. Looks like plausible (as in varying) raw values are detected, but not the calibration to pixel coordinates.

This was with display.ini having

:TS,*,-1,0
:M,2119,2109,2032,2074

The last line was produced by the calibration. While I do not know what numbers are used there, seeing low thousands numbers both there and as raw coordinates, I was expecting a wider range in the X/Y coordinates from the calibration, to have any chance of detecting the not very large on-screen buttons.

[dkebler]

according to another webpage (which I can't find again...argh) the low values of the calibration should be around 300. That page explained why the numbers are in thousands and not something like 0 to 320, 0 to 240.

So with your :TS line and the demo
and the :M numbers from
https://github.com/arendst/Tasmota/blob/development/tasmota/displaydesc/ILI9488_XPT2046_display.ini

and now I'm getting some response but not surprisingly the registration is way off.

Getting closer. I'm going to track down that page I mentioned.

[dkebler]

I think the rotation has to be set in display.ini

:TS,*,-1,0
:r,1
:M,3907,324,216,3807

then you get some reasonable calibration numbers. I think those numbers are unique to each rotation. Still running the demo the touch registration is still fubarred. (e.g. touching upper left is apparently left arrow.

[dkebler]

seems the final calculation for the :M has a bug. From the log these were coordinates of each calibration tap. with rotate 2

released x=240 y=320 (raw x=569 y=585)
released x=0 y=320 (raw x=576 y=3574)
released x=240 y=0 (raw x=3738 y=552)
released x=240 y=320 (raw x=3689 y=3540)

[dkebler]

Well getting ever closer.

with

:TS,*,-1,0
:r,1
:M,569,3788,585,3560

That puts the demo in "landscape" but the buttons are touch registered vertically along the right edge but of course appear along the bottom. When I tap the misregistered locations I can see the the corresponding button "depress" and the "page" changes. I wonder if the demo tapp only understands portrait (rotate 0). I've tried variations permutations of :M but this is the best of the worst.

[dkebler]

Ok going to need some more suggestions.

I ran the displaycalibrate tapp and picked these values from the logs (as the calculation of :M is flawed)

upper-left released x=0 y=0 (raw x=3710 y=3622)
upper-right released x=0 y=320 (raw x=3698 y=563)
lower-left released x=240 y=0 (raw x=542 y=3574)
lower-right released x=240 y=320 (raw x=589 y=515)

I then hand edited :M in display.ini thus with rotation zero the default (which is the 320 pixels vertically)

:TS,*,-1,0
:r,0
:M,3700,560,3600,540

for troubleshooting I wrote a simple pages.jsonl and started haspmota

{"comment":"---------- test buttons ----------"}
{"id":101,"obj":"btn","x":70,"y":20,"w":100,"h":60,"action":"button1","bg_color":"#1fa3ec","radius":10,"border_side":1,"text":"Button1","text_font":"montserrat-20"}
{"id":102,"obj":"btn","x":70,"y":100,"w":100,"h":60,"action":"button2","bg_color":"#1fa3ec","radius":10,"border_side":1,"text":"Button2","text_font":"montserrat-20"}
{"id":103,"obj":"btn","x":70,"y":180,"w":100,"h":60,"action":"button3","bg_color":"#1fa3ec","radius":10,"border_side":1,"text":"Button3","text_font":"montserrat-20"}

With this running the three buttons appear vertically more or less centered. If I tap left to right about the vertical center I can fire off events for all three buttons in order so touch is working BUT! the registration (where you tap to actuate the button vs where the button is displayed is definitely 90 degrees rotated (and maybe the "vertical" registration is scaled down).

So why is this and how can I fix it? If I swap the order of values in :M that does NOT fix it and mostly makes it worse or it doesn't function at all.

I'm thinking the issue is with display .ini for the UDD. I am looking at the settings for display.ini wondering what needs to change.
https://github.com/tasmota/docs/blob/master/docs/Displays.md#universal-display-driver

Maybe since it's a rotation problem I need to set :R but to what?

:R,OP,SL

OP = rotation opcode
SL = startline opcode (optional)
:0
:1
:2
:3

Register values for all 4 rotations (color display only)

rotation code
x offset
y offset
rotation pseudo opcode for touch panel, in case of RGB panel use only these entries the appropriate coordinate convervsions are defined via pseudo opcodes 0 = no conversion 1 = swap and flip x 2 = flipx, flip y 3 = swap and flip y 4 = flip x 5 = flip y bit 7 = swap x,y

here is :R for (https://github.com/arendst/Tasmota/blob/development/tasmota/displaydesc/ILI9488_XPT2046_display.ini)
which I tried...and pretty clearly didn't fix it.

:R,36
:0,28,00,00,02
:1,48,00,00,01
:2,E8,00,00,00
:3,88,00,00,03

[dkebler]

THIS WORKS FOR TASMOTA PRE 14. See below for update to this answer for 14+

I have a resolution to this touch issue! Yeah!

Lolin TFT Display with D1 Mini ESP32s2

• https://www.wemos.cc/en/latest/d1_mini_shield/tft_2_4.html
• https://www.wemos.cc/en/latest/s2/s2_mini.html
• XP2046 touch failure with esp32s2 and lolin 2.4 tft #19975 (comment)

FIRMWARE

https://github.com/tasmota/install/releases

tasmota32s2-lvgl.factory.bin

using esptool to load (could not get web installer to work)
To get into flash mode is finiky. Pushing both buttons start the script then release RST button followed by gpio 0 button in order to get into "flash" mode

#!/bin/bash
# see https://tasmota.github.io/docs/ESP32/
# tasmosta="../../Tasmota/firmware/tasmota32"
port=$(./port) 
# esptool.py  \
#         --port $port           \
#         --baud 115200          \
#         --after  no_reset      \
#         --chip esp32s2         \
#         erase_flash        
# echo done with erasing flash
type=$([[ $1 ]] && echo -${1})  
bin=./tasmota32s2$type.factory.bin    
[[ ! $port ]] && echo esp not connected no available tty port && exit
echo flashing $bin to $port
esptool.py  \
         --port $port         \
         --before no_reset               \
         --after hard_reset  \
         --baud 115200                \
         --chip esp32s2                \
         write_flash 0 $bin   

Tasmota Template

{"NAME":"S2 Mini ILI9341 shield","GPIO":[32,1,1,1,1,768,1,736,1,672,1,704,800,1,1,1,1,1,7264,1,1,1,1,1,992,1,1,1,1,6210,1,1,1,1,1,1],"FLAG":0,"BASE":1}

ENABLE

to enable touch for the xp2046 chip with the UDD use this line

:TS,*,-1,0

CALIBRATION/REGISTRATION

From an lvgl post about the same TFT using a similar driver it was pointed out that no calibration was needed. Just use 0,4095 for min/max of both x and y. That got me started in the right directioin.

https://forum.lvgl.io/t/issue-with-calibration-of-display-ili9341-display-and-xpt-2046-touch-controller/395/47

These values for :M seem to be fine across different TFTs (I tested 3)

:M 0,4096,0,4096

SWAP/ROTATION/FLIP

@sfromis was able to articulate the touch codes for :R. "That being 8z where 8 sets the swap (rotate) bit for x and y. Then z follows 0 = no conversion 1 = swap and flip x 2 = flipx, flip y 3 = swap and flip y 4 = flip x 5 = flip y

so with a bit of testing I came up with this for :R which works for all four rotations.

:R,36
:0,48,0,0,82
:1,28,0,00,83
:2,88,00,00,80
:3,E8,00,00,81

BUT

That lines up great for rotations :r,0 and :r,1 but :r,2 and :r,3 are off. I wasn't able to come up with good values for :M in these two cases but to me it's moot. I have portrait and landscape working (i e. r:0, r:1). Just be sure to mount the screen in the correct orientation :).

FYI if you notice there is a black strip on one edge of the TFT where data lines are connected. In rotations :r,2 and :r,3 this creates a miss alignment between the display layer and the touch layer (bad design IMHO) causing the miss registration which might not be "fixable" with any configuration of the UDD. I mean you can touch in the black strip and the log will show you the touch raw values but nothing is ever displayed in that black strip.

FILES

this zip archive has landscape and portrait versions of display.ini and of a full screen grid of test buttons as a pages.jsonl file. The grid of buttons is very helpful in determining if the touch registration is satisfactory.

lolin 2.4 TFT Display.zip

HELP

If you have any issue with the same hardware given the files I have provided post a reply here and maybe I can help you resolve them.

[sfromis]

It should be enough with one display.ini file, as the DisplayRotate command is meant to be the way of adjusting it from the default orientation. The question may be if it should simply be an update to the existing ILI9341_display.ini file, which I'd tend to favor, as the change also works for me. However as IDK how @s-hadinger reports to have it working with the current setup, and also was able to successfully run the calibration, I'm still a bit concerned about what the "best" solution is.
Anyway, with the "portrait" one (defaulting to :r,0) I have it working reasonably along with my suggested update of the min/max logic in ts_calibrate.be.

To me, it makes sense to update the existing ILI9341_display.ini with these lines, unless @s-hadinger has something to say about that.

:0,48,00,00,82
:1,28,00,00,83
:2,88,00,00,80
:3,E8,00,00,81

And then also make ts_calibrate.be works. With the correction I made I have it working for me. However, if the current version (which to me looks broken) actually worked in the past, I'm still wondering if the situation is "more complex".....

I was changing these lines:

      var xmin = (p0x + p2x) / 2
      var xmax = (p1x + p3x) / 2
      var ymin = (p0y + p1y) / 2
      var ymax = (p2y + p3y) / 2

which to me looks like midpoint, to instead look more like actual min/max.

      var xmin = p0x < p2x ? p0x : p2x
      var xmax = p1x > p3x ? p1x : p3x
      var ymin = p0y < p1y ? p0y : p1y
      var ymax = p2y > p3y ? p2y : p3y

[dkebler]

with tasmota 14 this answer is no longer relevant. When I get the new utouch driver working I will update this answer

[dkebler]

This is the updated solution for tasmota >14 which uses uTouch driver instead.

Tasmota template

• this template includes a relay at pin 3 and DS18x20 at pin 16 since is being used as a themostat with screen as the UI.
• The backlight at pin 35 will show in tasmota as a toggle button/relay
• TS SPI CS on pin 18 connects to touch via new uTouch driver.
• Pin 40 has Option A set which will enable universal display driver and now I guess the universal touch driver. See display.ini below

{"NAME":"S2 Mini ILI9341 shield","GPIO":[0,1,1,224,1,768,1,736,1,672,1,704,800,1,0,1,1312,1,10944,1,1,1,1,1,992,1,1,1,1,6210,1,1,1,1,1,1],"FLAG":0,"BASE":1}

NAME	LOLIN TFT BOARD	S3 Mini GPIO
SPI CS	D0	5
SPI CLK	D5	7
SPI MISO	D6	9
SPI MOSI	D7	11
TS SPI CS	D3	18
Backlight	D1	35
Option A	none	40
So those above are reserved leaving only 4 broken out on the header for other purposes
DS18x20	D4	16
Relay	A0	3
	D2	33
	D8	12
of course there are many more possible gpios along the inner two rows of the S2 mini but those are not accessible by the header and would have to be connected separately

Display.ini

This will give you landscape orientation. for Portrait change :r,0
If you load the haspmota demo the touch should be working and properly registered

:H,ILI9341,240,320,16,SPI,1,*,*,*,*,*,*,*,40
:S,2,1,1,0,40,20
:I
EF,3,03,80,02
CF,3,00,C1,30
ED,4,64,03,12,81
E8,3,85,00,78
CB,5,39,2C,00,34,02
F7,1,20
EA,2,00,00
C0,1,23
C1,1,10
C5,2,3e,28
C7,1,86
36,1,48
37,1,00
3A,1,55
B1,2,00,18
B6,3,08,82,27
F2,1,00
26,1,01
E0,0F,0F,31,2B,0C,0E,08,4E,F1,37,07,10,03,0E,09,00
E1,0F,00,0E,14,03,11,07,31,C1,48,08,0F,0C,31,36,0F
11,80
29,80
:o,28
:O,29
:A,2A,2B,2C,16
:R,36
:0,48,0,0,82
:1,28,0,00,83
:2,88,00,00,80
:3,E8,00,00,81
:i,20,21
:r,1
:UTI,XPT2046,S1,*,*,*
CPR 00
RT
:UTT
XPT 300
RT
:UTX
MV 0 2
SCL 460 0.0930233
LIM 319
RT
:UTY
MV 2 2
SCL 300 0.0695652
LIM 239
RT
#