Strange discovery with TOUCH_CS

[bobwolff68]

Setup: ESP32 + ILI9341 with touchscreen. Both on the VSPI. TFT and touch has been working for a week with great progress using both.

Just yesterday I recognized that on the ESP32, GPIO36 is ONLY an input. I found this especially ODD because my configuration which is working on my breadboard has the TOUCH_CS as pin 36. And my touch screen seems to work GREAT.

After convincing myself that I really needed to move it to another pin (GPIO32 in my case), I changed the wiring on the board and plugged it into my USB to prep to download new code for CS being controlled by pin 32.

By chance, things didn't compile and so I didn't download any new changed code to the board. For some odd reason I decided to TOUCH the display. And it WORKED. WHAT? My wiring was no longer hooked up to GPIO36 (which is an input anyway and so why was it working in the first place?) but it was now connected to GPIO32 and the program wasn't doing anything with GPIO32 yet since I hadn't downloaded anything yet.

Is it possible that TOUCH_CS isn't necessary due to some odd coincidence here? I only have the TFT and the touchscreen on the SPI bus. And I thought - hmm - maybe writing to the screen works and reading from touch works and that's why there's no collision, but I'm also sending data at startup to the touchscreen for calibration data (or at least I am TRYING to - meaning ... I'm calling the function but without TOUCH_CS, it shouldn't be getting to the touch controller anyway).

Any thoughts on why this is working at all and what the risks are of leaving it as is and saving an I/O pin on the ESP32? I ask because my project is already short of the pins I need and gaining one would be great news.

[Bodmer]

This ESP32 pin reference is useful for the basic functions and I/O capability.

When pins are not driven as outputs they float. Due to uncontrolled parasitic leakage currents pins that do not have pull ups or pull downs will usually drift to either a logic 1 or a logic 0. In this case TOUCH_CS has drifted to logic 0 level so the touch controller will be listening to the bus and trying to execute any commands. Some commands will result in the touch controller replying but this reply data will get lost when sending data to the TFT as the library is not expecting reply data at this time. Calibration data does not get sent to the touch controller, it is handled within the library, so the touch controller is really just a dedicated ADC. The touch controller also needs a low SPI clock rate so it could e that it is not fast enough to see the TFT pixel data but gets garbage commands now and then.

When a touch check is made then the library and ESP32 asks the touch controller to send the ADC values to work out where the touch was using the calibration values, so any garbage commands will not have an effect on this. At this time the TFT SPI interface will be disabled.

So that explains why it works. The situation where things will go wrong is if you read data from the TFT, now there is conflict between the touch controller output and the TFT output and it it a battle of I/O drive strength as to who wins. The output drivers will probably both survive this fight but it does stress them. If the touch controller wins the fight then the pixel data read will be corrupted.

There may also be some setup registers in the touch controller that get duff values from the TFT writes and put the controller into an apparently unresponsive mode, a study of the data sheet might reveal if this could occur.

The other problem is that the pixel data can start a touch request but not complete it, then when a real touch request comes along the touch controller does not respond, or resonds with incomplete data.

Haing said all that... it really is a good idea to use a dedicated chip select pin for each SPI device on the bus to make the system reliable.

[bobwolff68]

Great insights. Thanks Bodmer. I was just prepping to do some reads from the TFT for the alpha blending concept in a different thread and would have been likely bit by this. Knowing that the calibration data is an internal compensation is helpful as well. I've re-vamped my pin budget again and will have a T_CS line for this prior to embarking on the TFT reading of data.