Issue with 1 out of 10 touch buttons

[WiFive]

On the nodemcu board gpio2 is connected to an led and a 12k pull-up on gpio0. On espea32 there is a 10k pull-up on gpio0.

[dave111]

Hmmm. Is there some shared understanding among board vendors that no sane person will want to ever use all 10 touch sensors and therefor T1 or T2 or both can be sacrificed for other purposes?

I created a 2-wire USB cable (no data wires, 5V only) to test with my lolin32-lite boards. T1 still fails where it has failed before. But now T1 _also_ fails where it used to work before: when connected to my main PC.

How do you read this? DTR up -> gpio-0 down -> T1 working? And DTR down -> gpio-0 up -> T1 fail?

[Archibald]

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

I too had been hoping to use all 10 touch sensor inputs (on a different board).

With an Arduino, I have used a breakout board with the MPR121 touch sensor chip and found it works really well. Surprisingly, Sparkfun have now discontinued them, but they are still available from Adafruit and from China. I've ordered one for use with ESP32.

Depending on discussions with a client, my current project may end up using only 8 touch inputs. Even so, I expect I would still need to use an MPR121 to leave sufficient pins for SPI, I²C, chip selects etc (use of push-button switches is not an option for this project).

You may be able to gain some insight into what is going on with your Lolin32 Lite board by measuring the RTS and DTR voltages on the UMH3N dual transistor. Incidentally, the circuit diagram of the board does not show the 4.7KΩ base resistors within the UMH3N.

[dave111]

Interesting. And good to know I'm not the only one who has run into this. I won't be able to use the MPR121 for this, but that should be OK. Because lolin32-lite is able to provide 10 working touch sensors. You can see them all lined up here, including T1:

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

This was captured running minicom on Ubuntu. Ubuntu is using the cp210x kernel driver to implement ttyUSB. I think Android is doing the same, only using an older version of the same driver. But when I connect the lolin32-lite board to my Android debice, T1 just fails. And unfortunately, raising DTR on the host side does not change anything. I've tried. It's got to be something else.

[WiFive]

lolin32-lite does not use cp210x

[dave111]

Right. The other two boards come with a cp210x uart, but the Lolin32-lite comes with a ch341 uart.

Also fact: The Android devices I own do not come with ch341 driver. I overlooked this so far, because I was always able to receive the logs from all three devices. Not sure how this is possible. Maybe Android has a fallback mechanism and is using a simplified USB serial driver in such case? Anyway, based on our previous findings (T1 fails on Lolin32-lite when connected to Ubuntu PC with a 2-wire power-only cable), a true ch341 driver may indeed be required. So I sat down, compiled the ch341 driver and managed to load it on the Android device. Here is the kernel log showing how the Android kernel is loading the ch341 driver.

Lolin32-lite connected to Android kernel log:

Code: Select all

<6>[ 1625.943878] usb 1-1.3: new full-speed USB device number 29 using msm_hsusb_host
<6>[ 1626.056549] usb 1-1.3: New USB device found, idVendor=1a86, idProduct=7523
<6>[ 1626.056884] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
<6>[ 1626.057342] usb 1-1.3: Product: USB2.0-Serial
<6>[ 1626.070526] ch341 1-1.3:1.0: ch341-uart converter detected
<6>[ 1626.086791] usb 1-1.3: ch341-uart converter now attached to ttyUSB0

However, nothing has changed. I can still receive the device logs. But T1 is still dead also.

But a solution that would depend on a specific host device is not my preference anyway. I would much rather see a solution where the Lolin32 would support all 10 touch sensors, while only being connected to a wall charger. Maybe manipulating the UMH3N dual transistor can provide such a solution. I still have to look into this.

[dave111]

Archibald wrote:
You may be able to gain some insight into what is going on with your Lolin32 Lite board by measuring the RTS and DTR voltages on the UMH3N dual transistor. Incidentally, the circuit diagram of the board does not show the 4.7KΩ base resistors within the UMH3N.

On the Lolin32-Lite, the UMH3N chip is the 1st component behind the gpio-0 pin. This means that the UMH3N always sits between the T1 outside sensor and whatever it needs to connect to.

https://i.imgur.com/33g23nx.png

What I get from this, is that signal RTS on UMH3N pin5 needs to be high, for T1 on gpio-0 to be able to connect through UMH3N pin3 to UMH3N pin4. Can someone please help me understand this?

Archibald, can you tell me more about the 4.7KΩ resistors? Where is it located?

[WiFive]

http://loboris.eu/ESP32/ESP32_AutoReset.jpg

The resistor is inside the chip

[Archibald]

Archibald, can you tell me more about the 4.7KΩ resistors? Where is it located?

From the datasheet, the dual transistor should have been drawn like this . . . .

UMH3N.png (11.4 KiB) Viewed 11226 times

Note that the transistor on the right would normally be drawn the other way up. It's drawn that way to correspond with the device's pin arrangement.

If DTR (pin 4) is low and RTS (pin 5) is high, base current will flow through the resistor, the transistor will conduct (from collector to emitter) and pull GPIO-0 (connected to pin 3) low. This transistor will not conduct for the other three logic combinations of DTR and RTS.

EDIT: paragraph deleted

Incidentally, if GPIO-0 were to be set to output high by code, I would expect a high current to flow from GPIO-0 to ground via that transistor if RTS becomes high and DTR low.

[dave111]

I quickly summarize:

As long as the Lolin32 lite is connected to my PC, all 10 touch signals (T0-T9) work just fine. When I disconnect it from my PC and run it from battery or via wall charger, one of the touch signals (T1, which is attached to gpio-0) stops working. I assume the UMH3N is blocking this signal as a result of the configuration change (no more USB data connection).

So I am trying to unblock T1 and let it's signal travel unmodified from gpio-0 (through the UMH3N) to it's internal destination. Q1: How should RTS and DTR be configured to achieve this? The Ubuntu ch341 driver - as long as it is connected as host - gets this done somehow. So it has to be possible. Q2: Who has access to RTS and DTR? Only the host? Or the code running on the ESP32 as well? Or both?

To answer your questions: Yes, the ESP32 is writing a console log to a serial monitor. Yes, I can monitor all 10 touch sensors via Wi-Fi or Bluetooth. This is how I find out that T1 stops working, when it is not connected to the PC.