Issue with 1 out of 10 touch buttons

[dave111]

This issue only manifests itself with touch button 1 (T1). I never see it happen with any of the other 9 touch buttons (T0, T2, T3 ... T9). On my dev-board (Lolin32 lite), T1 is made available on the same pin as GPIO 0.

When T1 malfunctions, touch_pad_read(1,&val) will return either 0 or 1 for val. Return code is always ESP_OK.

The problem seems to depend on the type of power supply being used. With some power supplies, I never see the problem (all 10 touch buttons work perfectly). But with some other power supplies (including a USB (5V) battery pack), the problem does occur every time. And it always happens to T1.

What could cause T1 to malfunction in such a way, when all other touch buttons never malfunction? Thank you.

[dave111]

I have looked at this from all sides. I tested with 10 different ESP32 boards, old and new and from different vendors. Problem remains: depending on what is powering the ESP32 board via USB port, one specific touch sensor (T1) may not receive values. It is not a single, malfunctioning board causing this issue. I have now updated to the latest idf from 28 march. But still the same.

This screenshot shows a log of the issue. As you can see T1 in column 7 never receives any values. (Each column has three numbers: live / average / trigger.)

https://i.imgur.com/BcwR6uJ.png

The best way for me to prevent this problem, is to connect the ESP32 board directly to one of the USB ports on my PC. When powered this way, T1 always receives proper values, just like the 9 other touch sensors. But when connected to certain other 5V power supplies (including a USB battery pack), there is a chance of me running into this problem.

I need someone to help me solve this. What could cause a single touch sensor to malfunction in such a way?

[WiFive]

Were your 10 boards all Lolin32 lite?

[dave111]

Yes, all 10 boards are Lolin32 lite.

I meant to say "from different retailers." All boards are from the same vendor.

[WiFive]

Well gpio0 is connected to reset/programming circuit of transistors and ch340c so if you plug it into a battery the default state of those ch340c pins may affect the state of gpio0.

[dave111]

Don't understand, sry. How does battery power differ from grid based power when both are connected via USB?

Aside from that, the same issue occurs also with several grid based power supplies.

Most importantly: can you come up with an idea on how to tackle this issue?

[WiFive]

I meant when it is not connected to a PC USB port and the ch340 chip is not being enumerated by the USB controller. If it works with some wall chargers it may be because they have data lines connected..to something. You could test this theory with a USB cable with the data lines cut or a piece of tape covering the pins.

[dave111]

This theory cannot be right, because some of the configurations, in which the issue also occurs, are when the board is connected to some USB host - just not my main PC.

A) T1 fails if board is connected to an Android tablet (being USB host) and it is being powered by the tablets battery.

B) T1 fails if board is connected to an Android tablet (being USB host) and both devices are powered by an external 5V power supply (using a USB Y-cable).

The issue does also occur when the ESP32 board is powered by a dedicated power supply (grid based or USB power brick) and nothing is connected to the USB data pins. But the two configurations above (A + B) are the ones where T1 fails and where I am able to fetch logs. Such as the one I have shown above.

Can we disregard the data connection explanation for a moment and think of what else might be causing a single touch sensor to fail?

I am not fully certain of the following: I think I have seen (once or twice) T1 to start to return correct values after being in failed state for a brief amount of time. Like recovering from failed state "by itself", while the other sensors have been reporting good values already. But if at all, this is happening very rarely. Q: Would it be meaningful to try to "kick start" a failed touch sensor in code? Or maybe play with any of the it's settings?

[WiFive]

Android tablet could configure ch340 dtr and rts pins differently than pc

[dave111]

I have new data. I was able to test with two ESP32 boards from other vendors. It does not look like rts/dtr handling is having anything to do with the issue:

Code: Select all

ESP32 board            connected->  PC Ubuntu 16.4      Nexus 9 7.1       plain USB power / no data
---------------------               --------------      -----------       -------------------------
Lolin32 (ESP32 rev 1)               no fail             T1 fail           T1 fail  -or-  no fail
NodeMCU (ESP32 rev 1)               T1 + T2 fail        T1 + T2 fail      not tested
ESPea32 (ESP32 rev 0)               T1 fail             T1 fail           not tested

In summary: T1 (GPIO-0) has a tendeny to fail on all three boards. And T2 (GPIO-2) is failing consistently on one of the boards.

The question is not anymore why the Lolin32-lite fails on the Android device (or on plain 5V). The question now is: why does the Lolin32-lite NOT fail when connected to the PC?

Anybody out there who has abs no issues with T1 and T2?