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?
Unable to bypass built-in USB UART On DevKitC board
Unable to bypass built-in USB UART On DevKitC board
- Attachments
-
- scrprint-1.png (31.7 KiB) Viewed 3423 times
-
- scrprint.png (33.27 KiB) Viewed 3423 times
-
- Posts: 9766
- Joined: Thu Nov 26, 2015 4:08 am
Re: Unable to bypass built-in USB UART On DevKitC board
Yes. Remove R17 and R18 on the DevkitC to disconnect the CP2102 from the TxD and RxD lines.
Re: Unable to bypass built-in USB UART On DevKitC board
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).
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