USB connect/disconnect

[K4KDR]

Hello! Hoping to use the lessons learned from my first attempt at building this device, I used extraordinary caution when assembling my second attempt unit. No detail was too small. (I actually did component-level bench repair way back when... quite a few resume entries ago)

While we can never rule out an assembly problem, I wanted to share my result on the outside chance that it indicated something in particular. When connecting the unit to the same USB cable that works perfectly fine for off-the-shelf ESP32's, my syslog loops through the following:

Feb 16 05:11:25 3010i5 kernel: [40601.552217] usb 1-1.3: new full-speed USB device number 106 using ehci-pci
Feb 16 05:11:26 3010i5 kernel: [40601.662018] usb 1-1.3: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
Feb 16 05:11:26 3010i5 kernel: [40601.662020] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 16 05:11:26 3010i5 kernel: [40601.662021] usb 1-1.3: Product: CP2102 USB to UART Bridge Controller
Feb 16 05:11:26 3010i5 kernel: [40601.662022] usb 1-1.3: Manufacturer: Silicon Labs
Feb 16 05:11:26 3010i5 kernel: [40601.662022] usb 1-1.3: SerialNumber: 0001
Feb 16 05:11:26 3010i5 kernel: [40601.662921] cp210x 1-1.3:1.0: cp210x converter detected
Feb 16 05:11:26 3010i5 mtp-probe: checking bus 1, device 106: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3"
Feb 16 05:11:26 3010i5 mtp-probe: bus: 1, device: 106 was not an MTP device
Feb 16 05:11:26 3010i5 kernel: [40601.664955] usb 1-1.3: cp210x converter now attached to ttyUSB0
Feb 16 05:11:27 3010i5 snapd[830]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug
Feb 16 05:11:27 3010i5 systemd[1]: Starting Manage ttyUSB0 for GPS daemon...
Feb 16 05:11:27 3010i5 gpsdctl: gpsd_control(action=add, arg=/dev/ttyUSB0)
Feb 16 05:11:27 3010i5 gpsdctl: reached a running gpsd
Feb 16 05:11:27 3010i5 systemd[1]: Started Manage ttyUSB0 for GPS daemon.
Feb 16 05:11:27 3010i5 upowerd[1403]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0
Feb 16 05:11:28 3010i5 upowerd[1403]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3
Feb 16 05:11:29 3010i5 ModemManager[812]: <info>  Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3': not supported by any plugin
Feb 16 05:11:34 3010i5 kernel: [40609.706944] usb 1-1.3: USB disconnect, device number 106
Feb 16 05:11:34 3010i5 kernel: [40609.707152] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Feb 16 05:11:34 3010i5 kernel: [40609.707171] cp210x 1-1.3:1.0: device disconnected
Feb 16 05:11:34 3010i5 systemd[1]: Stopping Manage ttyUSB0 for GPS daemon...
Feb 16 05:11:34 3010i5 upowerd[1403]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0
Feb 16 05:11:34 3010i5 gpsdctl: gpsd_control(action=remove, arg=/dev/ttyUSB0)
Feb 16 05:11:34 3010i5 gpsdctl: reached a running gpsd
Feb 16 05:11:34 3010i5 systemd[1]: Stopped Manage ttyUSB0 for GPS daemon.
Feb 16 05:11:35 3010i5 upowerd[1403]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3
Feb 16 05:11:36 3010i5 compiz[1408]: [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

... by chance does anything there suggest what might be wrong? FYI, one time it actually stayed "alive" long enough for me to upload code via the Arduino IDE and in the serial monitor, I got one quick iteration of my code's user menu.

Note that I am only using USB power. While this works perfectly fine for any other device I use, do you think it might possibly be helpful here if I powered the unit externally?

Many thanks!

-Scott, K4KDR

[K4KDR]

Just to follow-up, I have noticed that the CP2102 chip gets EXTREMELY hot. I removed D1 in case I had installed that backwards but with D1 removed, the same syslog errors occur and CP2102 (U2) still gets hot.

[jgromes]

The overheating issue is very strange, it doesn't do that on my board. How long does it take to start overheating? Can you rule out shorts on the QFN package? Also, are you using CP2102 or CP2102N? Apparently, those two are quite different.

Using only USB power should be fine for startup, it might not be enough when transmitting at 1 W but that's not the case now.

The USB/UART converter and reset circuit is copied from NodeMCU, so I hoped it would work. Which ESP32s did you try?

[K4KDR]

The overheating is immediate. FYI, the first components installed were the USB jack and CP2102. Connecting to the computer via USB with ONLY those two components installed gave a proper "USB device found" type of message in syslog, so I felt confident to continue the build. No overheating was noticed at that point.

I continued this "syslog" type of testing throughout the build. Everything was stable until the last few components were installed. They were the SMA jack, pin header, slide switch, R3 / R5 / R7, and R14 / R15.

If no smoking gun is identified, I can certainly work backwards removing the last few components to see if the issue stops. I would like to think I can omit the SMA jack from consideration, but the other components might be telling.

As for those components you asked about, the CP2102 is: https://www.mouser.com/ProductDetail/634-CP2102-GM/

... and the ESP32 is: https://www.mouser.com/ProductDetail/356-ES32WROOM32D16MB/

If I have used an incorrect CP2102, that would almost be "good" news - at least I would have an explanation.

Thank you so much for your time!

[jgromes]

Let's go through it then, back to front:

• R14/15 are I2C pullups, so that's most likely not related
• R7 is just a serial resistor on ESP32's RX - again, doesn't seem like the culprit
• R3/5 are serial resistors that connect to the reset and bootloader buttons. That one looks more interesting, what buttons did you use? If they're always shorted to the ground, it could mess up the BJT autoreset switches
• the slide switch connects the CP2102 to power, so that one will always be suspicious
• pin header doesn't seem related
• SMA jack also doesn't

The CP2102 should be the correct one, as well as the ESP32.

[K4KDR]

I was hoping I had chosen the wrong CP2102... at least that would be easy to correct!

Very well, thank you so much for the detailed part functionality review. I will start removing items until I return to a device that will connect to the computer in a stable fashion -- and without excess heat.

By chance do you have a high-resolution picture of a completed board without the OLED installed? It would be helpful to verify the orientation of some components obscured by that display... D1 in particular. There is a faint 'line' on one end of D1 and I am not certain whether the 'line' should face U1 or U2.

Thanks!

[K4KDR]

I neglected to answer ref. the push-button switches. They are:

https://www.mouser.com/ProductDetail/667-EVQ-P2F02K/

[jgromes]

OK, that should be the exact same as mine, so that theory is busted then.

Here's a picture of the area beneath the dispplay, hope it helps. The diode is there just for reverse-voltage protection, so if it's mounted backwards, it still doesn't explain the overheating issue.

[K4KDR]

Thank you! I had D1 oriented correctly, so I'll re-install it.

Where did you get that socket for the OLED? I can't use it as my display modules have VCC & GND reversed from your build. But it would be wonderful to have some of those for future use.

[jgromes]

It's basically a precision pin header, originally for round pins but it can take square ones too. It's a lot more solid connection than the usual square headers. Here's a TME link, Mouser might have them too: https://www.tme.eu/cz/en/details/zl307-1x4/pin-headers/connfly/ds1002-03-1-4131/

[K4KDR]

Removing R5 & R7 made no difference, so I suppose that I should not overlook the obvious... that tiny CP2102 is not installed cleanly. When I only had the USB jack & CP2102 installed, of course very few pins were in use. Now that all of the CP2102 pins (at least those utilized on this build) are connected, a short could certainly be causing all this heat under that chip. I suppose I should remove & try again the CP2102...

[K4KDR]

Well, after VERY carefully reinstalling the CP2102 chip (actually a new chip), I no longer am overheating. After also reinstalling D1 and the resistors that I had removed, the device seems to be recognized by my system and does not instantly disconnect. (see images below) However, I'm having mixed results w/ uploading code from VSCode & the Arduino IDE. Using ESPTOOL to completely wipe the flash worked once, but now hangs. Is anything special needed to interact with this VROOM module that I might not have on my system? Thanks!

[K4KDR]

An update....

Noticed the following scrolling non-stop in the Serial Monitor window in VSCode:

----------------------------
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57
-----------------------------

[jgromes]

Seems like an issue with the ESP32 flash module. Could you post the full output of esptool?

[K4KDR]

Glad to!

Is there some particular argument that might help you? If I just run

esptool.py --port /dev/ttyUSB0

it returns the list of additional options & arguments that are available

[jgromes]

Nothing in particular, just the output from uploading via esptool (even in Arduino IDE).

[K4KDR]

Very good - thank you! Here is what I get when attempting to upload from VSCode:

2021-02-18--k4kdr--esptool-upload-error.txt

[jgromes]

After going through a couple issues on esptool GitHub, I think this is most likely faulty hardware again. This seems to be supported by the esptool output:

Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB

0xFF is a very typical output of a faulty SPI. My guess is that either something got damaged with the shorted CP2102, or there's some short or cold joint on the ESP32.

As a last check, could you try running espefuse.py --port PORT summary (where PORT is the serial port ESP32 is connected to)? Apparently this thing can also happen if the fuses aren't set correctly.

[K4KDR]

I have also been researching this and the internet is flooded with reports of similar issues/errors. Apparently there is some combination of circumstances that makes this type of thing very common with ESP32s.

There seem to be many references to GPIO-2 possibly having a role in whether or not an ESP32 can be programmed successfully, but I'm not clear on that.

I saw many references to the espefuse command but have no idea what a "fuse" is in the ESP32 world. The output of that command from my build is attached. Many thanks!!

2021-02-19--k4kdr--espefuse-output.txt

[jgromes]

Looking over the efuses, I don't see anything that stands out.

GPIO2 is used as LED indicator pin, I guess you could try to remove R9 to isolate it, but I don't think it's going to make a difference. So I'm afraid this really does look like a hardware fault in the ESP32 module.

[K4KDR]

Thanks so much!! I'll remove R9 in case GPIO2 is a factor. If nothing changes, then I'll try another ESP32 module.

Will report the results!

[K4KDR]

Very grateful for your patience to walk me through this fun project! Removing R9 did not help, so I removed the ESP32 and installed a new one.

The device now accepts programming both from VSCode and the Arduino IDE!

Could you please confirm the pin assignments for this Ebyte 400M30S module? I have tried several combinations that I thought were correct, but get:

Failed to initialize radio, code: -2

From the user manual for this device, if I understand correctly this is an SX1268 chip, is that right?

Finally, by chance is there any code available to "test" the various aspects of this build? I mean, something more simple than the more complex repositories that add so many other variables into the equation?

Thanks!

[K4KDR]

Follow-up... using the new BETA tinyGS code, I seem to be ok. Your custom 1W board is on the pick list using the initial 192.168.4.1 wi-fi connection, so that got me properly configured.

Further, I found that same listing in the code so that should provide what I need in regard to pin assignments (for other uses of this device)

... so thank you again. I used the "P" key available using the tinyGS code and confirmed over-the-air transmission looking at an SDR waterfall. So, all is well so far.

[jgromes]

The pin assignment for the LoRa module can also be seen on the PCB itself, next to the pin header. And yes, Ebyte 400M30S is using SX1268 as the transceiver.

Since it looks like the issue is now resolved, I'm closing this. I also created #3 with a list of improvements to make the design a bit easier to assemble, so if you have any more feedback, it would be great if you could place it in that issue. Thanks!