Unable to bypass built-in USB UART On DevKitC board

liyanage
Posts: 2
Joined: Mon May 27, 2019 7:28 am

Unable to bypass built-in USB UART On DevKitC board

Postby liyanage » Mon May 27, 2019 7:40 am

I'm working with a DevKitC board, but I would like to avoid using its USB/UART chip and instead use a separate FTDI-based USB/UART cable. The reason is that I currently have an issue with the Silabs USB kernel extension/driver on my Mac so I can't use that part of the board. Until I have that sorted out, I wanted to use the separate cable that I have and whose driver works.

I hooked up the cable to the appropriate pins and I'm able to get the bootloader message to show up in a terminal program on the Mac when I press the EN/Boot buttons. However flashing always fails and I I figured out that the TX line coming from the Mac and going into the RX pin of the board has a bad signal the moment the pin is connected. With the pin not connected and measuring the Mac's output, the signal looks good, it goes from 3.3V to 0V. However the moment I connect the pin, the signal only goes down from 3.3V to about 2.8V. See screenshots. The same does not happen on the RX (TX on the ESP32 side) line.

Is this possibly because the Silabs chip sits on the same line and somehow interferes with signal coming from the Mac? Can I disable that?
Attachments
scrprint-1.png
scrprint-1.png (31.7 KiB) Viewed 3423 times
scrprint.png
scrprint.png (33.27 KiB) Viewed 3423 times

ESP_Sprite
Posts: 9766
Joined: Thu Nov 26, 2015 4:08 am

Re: Unable to bypass built-in USB UART On DevKitC board

Postby ESP_Sprite » Mon May 27, 2019 2:40 pm

Yes. Remove R17 and R18 on the DevkitC to disconnect the CP2102 from the TxD and RxD lines.

liyanage
Posts: 2
Joined: Mon May 27, 2019 7:28 am

Re: Unable to bypass built-in USB UART On DevKitC board

Postby liyanage » Mon May 27, 2019 9:19 pm

Thank you for your super-quick reply ESP_Sprite, that's exactly what I wanted to know, I'll try that out.

BTW for anybody else who might end up here while trying this rather unusual procedure: the symptom of this problem is that when attempting to flash, the operation fails with the well-known "Timed out waiting for packet header" message (because the board never sees the host's bootloader commands and therefore never sends the expected reply, which eventually leading to the tool timing out).

Who is online

Users browsing this forum: Bing [Bot] and 101 guests