Strange USB enumeration behaviour on Wrover Dev Kit 4.1

[davetcc]

I have a rather odd problem that has recently started to occur with a Wrover developer kit 1.4 (with ILI9341 LCD); which prior to this appeared to be working correctly.

Environment:

Mac book pro running Catalina, (even rebuilt the Mac today to ensure it's not an OS problem)
Windows 10 device running "Version 10.0.18363.1139" (tried two different PCs).
ESP-WROVER-KIT_V4.1 jumper states:

• *POWER - from USB or from external, makes no difference
  * RX & TX - connected
  * +all other jumpers are open.

Problem description:

A few days ago, I accidentally uploaded some firmware that used the JTAG ports, at the same time as requesting remote debugging thus possibly causing a conflict.

The issue is that whenever I connect the device to macOS it lists the serial port, but cannot access it. The error I get is error: (22, 'Invalid argument'). I've tried holding down BOOT while pressing EN, the ports again enumerate, again give the same error.

On Windows 10 the situation is even worse (even with the recommended FTDI drivers installed), it basically constantly disconnects the device and then reconnects it, so I'll see COM11 and COM12 appear momentarily, then disappear. At the same time, the USB enumeration sounds can be heard. I initially suspected it could be power related, so I tried powering from 5V on my bench supply. This eventually leads to a blue screen if left plugged in long enough!

At the moment I don't think the actual developer env matters much as the serial ports will not even enumerate in any mode. But my development environment is platformIO with Clion ID. It works flawlessly with another ESP32 board (Heltek WiFi kit 32) and also works flawlessly with my other ESP8266 boards.

Is there any way to recover the board from this situation, or is it likely to be a faulty board? The board is only a few months old, and has not been used that many times.

[davetcc]

I was hoping that I'd just overlooked something fairly basic and would be quickly corrected, but that doesn't seem to be the case. I've not seen this behavior before and suspect there is some kind of issue with signal or power lines to the FTDI chip as it's constantly cycling through appearing then disappearing on the host.

However, the embedded code on the device works absolutely fine, even though there is no possible way to update it!

I think the best course of action is to follow up with product support where I purchased the device as I suspect it may be faulty.

[ESP_Angus]

Hi dave,

If it's constantly enumerating and de-enumerating then this does sound like a faulty board.

Silly question, but have you tried swapping out the USB cable? Sometimes faulty USB problems like this come down to the cable (or a problem with the plug on a particular cable mating with the USB Micro socket.)

The only other possibility I can think of is something connected to the dev-kit or touching the pins is shorting power out, but it sounds like you ruled this out already.

Angus

[davetcc]

Many thanks for the reply.

I've tried three different cables, a nearly new amazon basics micro usb (also tested with mbed -> STLink and working fine), a generic micro usb that I've had some time, also tested with another esp32, esp8266, and MKR with all working fine. Same in all cases.

I've even got out the magnifying glass and checked for any small pieces of debris or any damage on the board. Nothing I can see, I can only conclude that the board must be faulty. It's nearly new, so I'll arrange a return.

I've even run it off my bench PSU, the current was very stable at less than 0.2A on the external adapter. Like I say when run on external power, the board runs flawlessly on the program I managed to put onto there before this fault started!

Thanks,
Dave

[davetcc]

I've got an update on this. The original board was actually malfunctioning because it would not even enumerate properly on MacOS which the new board does without any issues.

However, the behavior I saw on Windows with the devices appearing and disappearing applies to the esp-prog board too. I fixed it by reading a bit about this on various PC gaming sites, where they see similar problems with large numbers of HIDs attached. The solution was to connect a powered USB2 hub in front of the USB3 port. It appears that the high power USB3 mode is chatty and upsets the FTDI device making it unregister itself. Since I've connected a powered USB2 hub, it has presented in device-manager without issue. So I think the key to always connect the device to a USB2 (or USBC port on the mac), both seem to work fine for me.

I think I have some answers on the original problem now, if anyone from Espressif watches the forum, I'm talking about the board with the LCD attached: my problems seemed to start after accidentally uploading a sketch that used one of the debug GPIOs. I think that the programming boot mode is not working properly here, because that should rescue you from any such situation with a regular board. Or am I mistaken when debugging is involved, is it possible to recover a device in that situation?

For now, I've gone to using a separate programmer and display, so if the emergency boot fails in such a situation, I can just dispose of the $10 ESP module without wasting a screen and programmer, and it's easier to recover with the emergency boot option with the onboard serial.

I'm enjoying debugging again now! Hope this helps others.

[ESP_Sprite]

FWIW, unless you're actively messing with eFuses, reprogramming the board should always work. Worst case you need to put the board into programming mode manually (by holding the BOOT and pressing and releasing the RESET button) but it should always work.