Detecting 2 COM Ports of IWR6843AOP Sensor

Raees Abdullah · Feb 15, 2026

Hi there, I am facing a problem and need urgent help if somebody can please, the thing is I am working on IWR6843AOP sensor and you don't need to know about this sensor for this problem but when you plug this sensor with the PC it shows 2 COM Ports by default, both these ports are important because one COM port is used to upload the configuration (the settings used to tune the sensor according to your requirement) and the other COM Port is used to read the data coming from the sensor, Now I don't know how these 2 COM ports are being implemented/splitted by the Texas Instrument (off course virtually) but the thing is that now I want to use the teensy 4.1 with the sensor for a standalone project in which I don't want to use PC, so I selected teensy 4.1 because it was the only microcontroller that came with a USB host pins with which I can use the PC along with the sensor with just teensy in between and later just separate the PC and use it standalone. But I encountered a problem I didn't imagined that teensy is unable to detect the second COM port and it only detects one and by doing some search I found out the USBHost_t36 is only capable of detecting 1 COMport interface, now tell me is that really true? have anyone else has faced the same issue? and have you found the solution? Do I need to make changes to the library myself to detect 2 COM ports and will it work? And the thing is when I try to detect these 2 com ports one by one by closing the first one and detecting second it does not do that and still detects the first one.

Please if the officials are seeing this message I want them to look into this and update the library or provide me some solution if its already there.

PaulStoffregen · Feb 15, 2026

First step is to edit USBHost_t36.h to turn on debug printing.

Look for this near the top of that file, probably at line 62.

Code:

// Uncomment this line to see lots of debugging info!
//#define USBHOST_PRINT_DEBUG

PaulStoffregen · Feb 15, 2026

Maybe this cable from Amazon could be used for testing?

https://www.amazon.com/dp/B0DHRM7TJ4

It claims to have the CP2105 chip

jmarsh · Feb 15, 2026

There are some FTDI chips supported by USBHost_t36 that provide multiple ports, by claiming the individual interfaces rather than the whole device. The CP210x driver would need to be modified to do the same.

KurtE · Feb 15, 2026

Try editing serial.cpp near this line

https://github.com/PaulStoffregen/USBHost_t36/blob/master/serial.cpp#L59

add in your boards VID and PID CP… and a 1 instead of 0. You need at least two serial objects defined not sure if you need HID objects

PaulStoffregen · Feb 15, 2026

I ordered the CP2105 from Amazon.

defragster · Feb 15, 2026

Is this the same DUAL Serial Teensy presents? VID/PID not the same - but would allow testing with programmable smart device.

Raees Abdullah · Feb 16, 2026

Thank you very much for your reply, Paul, first of all sorry from my side I didn't think some official will reply to me because there are a lot of threads and that's why I posted under many threads in panic hoping someone might help me. I will discuss the problem with you.

Now first of all yes, the sensor is not IWR6843AOP (it's just a chip), its IWR6843AOPEVM and here is the link: https://www.ti.com/tool/IWR6843AOPEVM

When I just plug the sensor directly with my PC it shows 2 Com port as I discussed earlier, one COM port is used to upload the configuration (the settings used to tune the sensor according to your requirement) and the other COM Port is used to read the data coming from the sensor, previously I was using python to upload the configuration file and reading the data from the sensor and it was working perfectly fine, but the big issue was the involvement of PC because now my goal is to make standalone project of the task I have done. I don't want to go to the raspberry pi boards because firsts python is really slow than C/C++ and also those boards have more awakening time and other stuff because it's basically a whole computer. And in my case the timing is very crucial.

Now among different MCU's I only found teensy that allowed me to upload the code from the PC to the teensy, along with integrating the sensor with it, which was perfect! The logic in python was initializing both the COMPORTS first:

CLI_COM_PORT = "COM3"
DATA_COM_PORT = "COM4"
CLI_BAUD = 115200
DATA_BAUD = 921600

and upload the configuration file. After it finished uploading, the sensor automatically starts sending data and python starts reading it.
But when I implement the same logic on teensy 4.1, it does well in the first half and uploads the configuration file to the IWR6843AOPEVM sensor but then stops and nothing happens (I was printing every step output on the serial monitor). It didn't read the data coming from the sensor and on debugging I found out it was unable to detect the DATA COMPORT (the second com port in my case). It is failing to enumerate both the COMPORTs coming from a single device and seems like it just only detects the COMPORT it sees first. I found out this by writing a small code and enabling the debugging options, the output of that code was:

port change: 10001803
connect
port change: 1C001002
disconnect
port change: 10001803
connect
port change: 1C001002
disconnect
port change: 10001803
connect
port change: 1C001002
disconnect
port change: 10001803
connect
begin reset
port change: 10001005
port enabled
end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration_transmit, state 0
enumeration_receive, state 0
enumeration_transmit, state 1
enumeration_receive, state 1
queuing get device descriptor
enumeration_transmit, state 2
queuing get device descriptor
enumeration_receive, state 2
Device Descriptor:
12 01 00 02 00 00 00 40 C4 10 70 EA 00 01 01 02 05 01
VendorID = 10C4, ProductID = EA70, Version = 0100
Class/Subclass/Protocol = 0 / 0 / 0
Number of Configurations = 1
enumeration_transmit, state 3
enumeration_receive, state 3
enumeration_transmit, state 4
enumeration_receive, state 4
Manufacturer: Silicon Labs
enumeration_transmit, state 5
enumeration_receive, state 5
Product: CP2105 Dual USB to UART Bridge Controller
enumeration_transmit, state 6
enumeration_receive, state 6
Serial Number: 010BCEB1
enumeration_transmit, state 7
enumeration_receive, state 7
Config data length = 55
enumeration_transmit, state 8
enumeration_receive, state 8
Configuration Descriptor:
09 02 37 00 02 01 00 80 32
NumInterfaces = 2
ConfigurationValue = 1
09 04 00 00 02 FF 00 00 03
Interface = 0
Number of endpoints = 2
Class/Subclass/Protocol = 255 / 0 / 0
07 05 81 02 40 00 00
Endpoint = 1 IN
Type = Bulk
Max Size = 64
Polling Interval = 0
07 05 01 02 40 00 00
Endpoint = 1 OUT
Type = Bulk
Max Size = 64
Polling Interval = 0
09 04 01 00 02 FF 00 00 04
Interface = 1
Number of endpoints = 2
Class/Subclass/Protocol = 255 / 0 / 0
07 05 82 02 20 00 00
Endpoint = 2 IN
Type = Bulk
Max Size = 32
Polling Interval = 0
07 05 02 02 20 00 00
Endpoint = 2 OUT
Type = Bulk
Max Size = 32
Polling Interval = 0
enumeration_transmit, state 9
enumeration_receive, state 9
USBHub memory usage = 992
USBHub claim_device this=20004220
USBHub memory usage = 992
USBHub claim_device this=20004600
USBSerial(512)claim this=20004AE0
vid=10C4, pid=EA70, bDeviceClass = 0, bDeviceSubClass = 0, bDeviceProtocol = 0
09 04 00 00 02 FF 00 00 03 07 05 81 02 40 00 00 07 05 01 02 40 00 00 09 04 01 00 02 FF 00 00 04 07 05 82 02 20 00 00 07 05 02 02 20 00 00
len = 46
USBSerial, rxep=1(64), txep=1(64)
rx buffer size:1920
tx buffer size:1920
new_Pipe
new_Pipe
CP210X: 0x41, 0x11, 0, 0, 0 - reset port
control callback (serial) F
CP210x setup, 0x41, 3, cp210x_format 800
control callback (serial) E
CP210x Set Baud 0x40, 0x1e
control callback (serial) C
CP210x 0x41, 0, 1
control callback (serial) 8
CP210x 0x41, 7, 0x0303
control callback (serial) 0

Now by seeing this output I tried to understand this and with some help from Claude I found out that the teensy is actually seeing both the COMPORTS but the problem is it is only claiming one COMPORT.
Now tell me is it a common thing? is it the limitation of teensy board or the USB HOST library that it can only detect one COMPORT and that one will be the first one they see or its just the problem on my side and it can actually enumerate both the comports simultaneously? And yes, I have also tried to detect CLI COM ports first, upload the cfg file first, then close it and then detect the DATA_COM but still it didn't work and it still detected the first one the CLI com port. How can I claim both the interfaces from the single device and is it the library limitation or its the limitation of the USBHost pins itself? I am confused a little I dont actually know if I am asking the right question

Raees Abdullah · Feb 16, 2026

KurtE said:
Try editing serial.cpp near this line

https://github.com/PaulStoffregen/USBHost_t36/blob/master/serial.cpp#L59

add in your boards VID and PID CP… and a 1 instead of 0. You need at least two serial objects defined not sure if you need HID objects

Thanks, KurtE for pointing one of the problems, yes, I need only two serial interfaces to be detected coming from the same device, because the sensor is using CP2105 which is a USB-to-Dual-UART Bridge controller, so I made changes to the file as:
{0x10c4, 0xea60, USBSerialBase::CP210X, 0 },
{0x10c4, 0xea70, USBSerialBase::CP210X, 1 }

I was just curious that can I detect more interfaces as well by copying the above and replacing 1 with 2? like:
{0x10c4, 0xea70, USBSerialBase::CP210X, 2}

But when I asked Cluade that will this solve my problem or not?, it replied that you will have to add some block of code as well in order to claim it and the code it gave me this block code to be added after line #246

// For CP2105 (dual UART), we need to claim at interface level
// to allow multiple USBSerial objects to claim different interfaces
if ((dev->idVendor == 0x10C4) && (dev->idProduct == 0xEA70)) {
// CP2105 Dual UART Bridge
if (type != 1) {
println("CP2105: Must claim at interface level");
return false; // Force interface-level claiming
}
sertype = CP210X; // Use CP210X driver

// Track which interfaces have been claimed
static Device_t* claimed_device = nullptr;
static uint8_t claimed_interface_mask = 0;

// Reset tracking if this is a new device
if (claimed_device != dev) {
claimed_device = dev;
claimed_interface_mask = 0;
}

// Get interface number
uint8_t interface_number = descriptors[2];

// Check if this interface is already claimed
if (claimed_interface_mask & (1 << interface_number)) {
println("Interface ", interface_number, " already claimed");
return false;
}

// Mark this interface as claimed
claimed_interface_mask |= (1 << interface_number);

println("CP2105: Claiming interface ", interface_number);
// Continue to claim this interface...
}

Now was this block of code was neccessary?

PaulStoffregen · Feb 16, 2026

My first advice is ignore Claude and try Kurt's suggestion. Kurt wrote much of this code, so he is by far the best person to answer!

You've already changed 0 to 1 for the correct VID, PID line. Do not use 2 or any other number. This code is written for only 0 or 1.

Kurt's other advice was "You need at least two serial objects defined not sure if you need HID objects". Looking at the debug print info, I'm pretty sure you don't need any HID stuff.

You will need to create 2 USBSerial instances in your program. Since this is only 12 Mbit speed device, you don't need the _BigBuffer version.

Your next step for help is to show us your test program with 2 USBSerial instances. Remember, we can't see your screen. For any of us to try helping, we need to see clearly exactly what you are trying.

When you reply, to sow your code click this button.

This will preserve the formatting of your code, which makes it easier for all of us to read. Everyone is busy with limited time. If reading your code is quicker, more people with experience are likely to assist.

Raees Abdullah · Feb 16, 2026

KurtE said:
Try editing serial.cpp near this line

https://github.com/PaulStoffregen/USBHost_t36/blob/master/serial.cpp#L59

add in your boards VID and PID CP… and a 1 instead of 0. You need at least two serial objects defined not sure if you need HID objects

KurtE can you also tell what is meant by 0 and 1 in these two lines? Does it tell the interface number? I have tried changing these but it when I use the same VID, PID for both the lines it shows no com ports detected, but when I use two different PID then it detects both COMPORTS but those com ports doesn't work as they should be working (i.e. CLI ports works good and configuration files get uploaded but the Data ports shows nothing when I try to read the data from the sensor)

// Silex CP210...
{0x10c4, 0xea60, USBSerialBase::CP210X, 0 },
{0x10c4, 0xea70, USBSerialBase::CP210X, 1 }

this is the change I made, is it right? I am attaching the images of Hardware ID of my COMPORTS, please can u give it a look and tell me how my #59 lines should be?

Also I have two codes and I am attaching both of those codes,

The first code to test the ports in general:

Code:

#include <USBHost_t36.h>

USBHost myusb;
USBSerial userial1(myusb);
USBSerial userial2(myusb);

void setup() {
    Serial.begin(115200);
    delay(2000);
  
    Serial.println("\n=== Simple Detection Test ===\n");
    myusb.begin();
  
    Serial.println("Waiting 5 seconds for enumeration...");
  
    for (int i = 0; i < 50; i++) {
        myusb.Task();
        delay(100);
      
        if (i % 10 == 0) {
            Serial.print(".");
        }
    }
  
    Serial.println("\n\n--- Results ---");
  
    Serial.print("userial1: ");
    if (userial1) {
        Serial.print("DETECTED ✓ - VID: 0x");
        Serial.print(userial1.idVendor(), HEX);
        Serial.print(", PID: 0x");
        Serial.println(userial1.idProduct(), HEX);
    } else {
        Serial.println("NOT DETECTED ✗");
    }
  
    Serial.print("userial2: ");
    if (userial2) {
        Serial.print("DETECTED ✓ - VID: 0x");
        Serial.print(userial2.idVendor(), HEX);
        Serial.print(", PID: 0x");
        Serial.println(userial2.idProduct(), HEX);
    } else {
        Serial.println("NOT DETECTED ✗");
    }
  
    Serial.println("\n--- Conclusion ---");
    int detected = (userial1 ? 1 : 0) + (userial2 ? 1 : 0);
    Serial.print("Total interfaces detected: ");
    Serial.println(detected);
  
    if (detected == 0) {
        Serial.println("ERROR: No interfaces detected!");
    } else if (detected == 1) {
        Serial.println("Only ONE interface detected (expected limitation)");
    } else if (detected == 2) {
        Serial.println("BOTH interfaces detected! Library can handle it!");
    }
}

void loop() {
    myusb.Task();
    delay(1000);
}

,

I am using the first code to just simply check if my comports are being detected and then my second code is the full fledge code in which I try to upload the configuration file through the CLI port (interface 0 port) and then read the data from the DATA port (interface 1), but no data is being shown, I think the problem might be that only 1 interface is actually being used for both the task or it might be a problem of port swapping. The second code is:

Code:

#include <USBHost_t36.h>
USBHost myusb;
USBHub hub1(myusb);
USBSerial_BigBuffer userial1(myusb, 1, 1024);  // Assume Interface 0 = CLI
USBSerial_BigBuffer userial2(myusb, 1, 1024);  // Assume Interface 1 = Data
const char* RADAR_CFG[] = {
    "sensorStop",
    "flushCfg",
    "dfeDataOutputMode 1",
    "channelCfg 15 7 0",
    "adcCfg 2 1",
    "adcbufCfg -1 0 1 1 1",
    "profileCfg 0 60 7 4 40 0 0 29 1 64 2500 0 0 48",
    "chirpCfg 0 0 0 0 0 0 0 1",
    "frameCfg 0 0 16 0 30 1 0",
    "lowPower 0 0",
    "guiMonitor -1 1 0 0 0 0 0", 
    "cfarCfg -1 0 2 8 4 3 0 12 0",
    "cfarCfg -1 1 0 4 2 3 1 12 0",
    "multiObjBeamForming -1 0 0.5",
    "clutterRemoval -1 0",
    "calibDcRangeSig -1 0 -5 8 256",
    "extendedMaxVelocity -1 0",
    "lvdsStreamCfg -1 0 1 0",
    "compRangeBiasAndRxChanPhase 0.0 1 0 -1 0 1 0 -1 0 1 0 -1 0 1 0 -1 0 1 0 -1 0 1 0 -1 0",
    "measureRangeBiasAndRxChanPhase 0 1.5 0.2",
    "CQRxSatMonitor 0 3 5 103 0",
    "CQSigImgMonitor 0 71 4",
    "analogMonitor 0 0",
    "aoaFovCfg -1 -45 45 -45 45",
    "cfarFovCfg -1 0 0 10",
    "cfarFovCfg -1 1 -1.21 1.21",
    "calibData 0 0 0"
};
bool configSent = false;
uint32_t frameCount = 0;
uint8_t magicWord[8] = {0x02, 0x01, 0x04, 0x03, 0x06, 0x05, 0x08, 0x07};
void setup() {
  Serial.begin(2000000);
  myusb.begin();
  delay(2000);
}
void loop() {
  myusb.Task();
  
  if (userial1 && userial2 && !configSent) {
    // Interface 0 (CLI) = 115200
    userial1.begin(115200);
    delay(100);
    
    // Interface 1 (Data) = 921600
    userial2.begin(921600);
    delay(500);
    
    // Send config to Interface 0
    for (int i = 0; i < 27; i++) {
      userial1.print(RADAR_CFG[i]);
      userial1.print("\n");
      delay(50);
    }
    
    delay(100);
    
    // Send sensorStart to Interface 0
    userial1.print("sensorStart\n");
    delay(500);
    
    // Clear buffers
    while(userial1.available()) userial1.read();
    while(userial2.available()) userial2.read();
    
    configSent = true;
    Serial.println("Config sent. Reading data from Interface 1...");
  }
  
  // Read from Interface 1 (Data port)
  static uint32_t totalBytes = 0;
  static unsigned long lastPrint = 0;
  
  while(userial2.available()) {
    uint8_t b = userial2.read();
    totalBytes++;
    
    // Print first 50 bytes to verify we're getting data
    if (totalBytes <= 50) {
      if (b < 16) Serial.print("0");
      Serial.print(b, HEX);
      Serial.print(" ");
      if (totalBytes % 16 == 0) Serial.println();
    }
  }
  
  if (millis() - lastPrint > 2000) {
    Serial.print("Total bytes: ");
    Serial.println(totalBytes);
    lastPrint = millis();
  }
}

Now that was all the working I have done. But dealing with these 2 COM ports is still a challenge. Now I am angry on Texas instruments that why didn't they just gave simple UART headers pins for general purpose use on such a board

, this task might have been a lot simpler when interfacing the sensor with different MCU's.

Raees Abdullah · Feb 16, 2026

jmarsh said:
There are some FTDI chips supported by USBHost_t36 that provide multiple ports, by claiming the individual interfaces rather than the whole device. The CP210x driver would need to be modified to do the same.

Can you further elaborate it please.

PaulStoffregen · Feb 16, 2026

Amazon delivered the CP2105 cable.

When I plug it into my computer, Linux kernel log shows this:

Code:

[2465198.794888] usb 3-1.1: new full-speed USB device number 50 using xhci_hcd
[2465198.976721] usb 3-1.1: New USB device found, idVendor=10c4, idProduct=ea70, bcdDevice= 1.00
[2465198.976725] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[2465198.976727] usb 3-1.1: Product: CP2105 Dual USB to UART Bridge Controller
[2465198.976728] usb 3-1.1: Manufacturer: Silicon Labs
[2465198.976729] usb 3-1.1: SerialNumber: 00653C88
[2465199.066834] usbcore: registered new interface driver cp210x
[2465199.066849] usbserial: USB Serial support registered for cp210x
[2465199.066875] cp210x 3-1.1:1.0: cp210x converter detected
[2465199.068314] usb 3-1.1: cp210x converter now attached to ttyUSB0
[2465199.068329] cp210x 3-1.1:1.1: cp210x converter detected
[2465199.069655] usb 3-1.1: cp210x converter now attached to ttyUSB1

PaulStoffregen · Feb 16, 2026

I'm sad to say the 2nd port on this cable does not work. It's TXD2 pin has about 1.5 to 2.0 volts (sensitive to touching the wire). The TXD1 pin has 3.4 volts, as it should, and works fine when open the port and send data.

This is testing with my Linux desktop PC, not even connected to Teensy yet. I just wanted to test the cable and label with 6 wires.

defragster · Feb 16, 2026

defragster said:
Is this the same DUAL Serial Teensy presents? VID/PID not the same - but would allow testing with programmable smart device.

To refer to my earlier post:
Have a DUAL USB: "Triple_Serial_Test" on USB host of "SerialTest" and with two lines of:

Code:

USBSerial_BigBuffer userial(myusb); // Handles up to 512 but by default only for those > 64 bytes
USBSerial_BigBuffer userial2(myusb); // Handles up to 512 but by default only for those > 64 bytes

It is working. They present as 480Mbps BigBuffer - not sure about other details in USB handling - but shows promise.

Not SAME 'hardware/interface' related - though USB_Host software seems capable.
Here is the disconnect - then plug message and then USB sending an ASCII :10 == NewLine:

Code:

*** Device USERIAL1 - disconnected ***
*** Device USERIAL2 - disconnected ***
*** Device USERIAL1 16c0:48b - connected ***
  manufacturer: Teensyduino
  product: Dual Serial
  Serial: 7658850
*** Device USERIAL2 16c0:48b - connected ***
  manufacturer: Teensyduino
  product: Dual Serial
  Serial: 7658850

    USerial Available
TriSerTest
USB_
    USerial2 Available
TriSerTest
usb2
    USerial Available
Serial USB1 received: 10
USB_Main Serial received: 10
USB_
    USerial2 Available
Serial USB1 received: 10
usb2Main Serial received: 10
usb2

Quick edit of msgs passed/printed shows Host identifies and parses/handles both 'devices'

Raees Abdullah · Feb 17, 2026

defragster said:
To refer to my earlier post:
Have a DUAL USB: "Triple_Serial_Test" on USB host of "SerialTest" and with two lines of:

Code:

USBSerial_BigBuffer userial(myusb); // Handles up to 512 but by default only for those > 64 bytes USBSerial_BigBuffer userial2(myusb); // Handles up to 512 but by default only for those > 64 bytes

It is working. They present as 480Mbps BigBuffer - not sure about other details in USB handling - but shows promise.

Not SAME 'hardware/interface' related - though USB_Host software seems capable.
Here is the disconnect - then plug message and then USB sending an ASCII :10 == NewLine:

Code:

*** Device USERIAL1 - disconnected *** *** Device USERIAL2 - disconnected *** *** Device USERIAL1 16c0:48b - connected *** manufacturer: Teensyduino product: Dual Serial Serial: 7658850 *** Device USERIAL2 16c0:48b - connected *** manufacturer: Teensyduino product: Dual Serial Serial: 7658850 USerial Available TriSerTest USB_ USerial2 Available TriSerTest usb2 USerial Available Serial USB1 received: 10 USB_Main Serial received: 10 USB_ USerial2 Available Serial USB1 received: 10 usb2Main Serial received: 10 usb2

Quick edit of msgs passed/printed shows Host identifies and parses/handles both 'devices'

Sorry I didn't get your point "Have a DUAL USB: "Triple_Serial_Test" on USB host of "SerialTest" and with two lines", and yes I have already included these two lines in my code (you can see my previous comment in which I posted my whole code):

USBSerial_BigBuffer userial1(myusb, 1, 1024); // Assume Interface 0 = CLI
USBSerial_BigBuffer userial2(myusb, 1, 1024); // Assume Interface 1 = Data

The ports are being detected but the data coming from the sensor is not being read by the teensy. I will try to find some other sensor who uses CP2105 chip and see if its communicating with teensy or not and see if this issue is on the sensors side or the teensy. But let's hope I found something in cheap to test.

PaulStoffregen · Feb 17, 2026

Amazon is sending me a replacement CP2105 cable tomorrow. I want to look into this, but need working hardware to do anything useful.

defragster · Feb 17, 2026

Raees Abdullah said:
didn't get your point

The point was to test an alternate hardware path that suggests the desired functionality can easily be had with USB_Host.

A Teensy presenting DUAL SERIAL "example" using that 'USB_Host Indicated Example' quickly showed it to work.

As noted above the device with CP2105 will NOT present the 480 Mbps BigBuffer - and may be a different class of USB device it seems as both ports are claimed without the special case naming section indicated above for the "USBSerialBase::CP210X"

KurtE · Feb 18, 2026

PaulStoffregen said:
Amazon is sending me a replacement CP2105 cable tomorrow. I want to look into this, but need working hardware to do anything useful.

Thought about ordering one, but don't really need yet another USB to serial adapter. It could also turn out that the Interface descriptors are not what we expect for Serial...

PaulStoffregen · Feb 19, 2026

Amazon delivered the replacement CP2105 cable. I'm happy to report both ports actually work on this new cable.

Another urgent matter came up yesterday, so I probably can't dive into USB Host serial until the weekend. But I definitely do want to look at this soon.

Raees Abdullah · Feb 22, 2026

I need to confirm one thing that are these two lines correct according to my port's hardware_ids information attached in the image? and what does that 0 & 1 represents? interface number?

// Silex CP210...
{0x10c4, 0xea60, USBSerialBase::CP210X, 0 },
{0x10c4, 0xea70, USBSerialBase::CP210X, 1 }

Raees Abdullah · Feb 23, 2026

My problem is that I can't send/receive data to/from the interface 1 and recently I was reading some previous forums, and I found this forum: https://forum.pjrc.com/index.php?th...-issues-with-silabs-cp2105.75211/#post-344623

This person was facing exactly the same issue I am facing and someone replied to him that "Judging from the screenshot of the hardware properties, the enhanced port is interface 0 and the standard port is interface 1. From what I can tell the CP210x driver in the USBHost_t36 library only uses interface 0, it would require a bunch of changes to use interface 1". This means that teensy 4.1 still does not have the capability to use the interface 1 completely.

defragster · Feb 24, 2026

For 3.3V Dual UART you could use a second T_4.0 or 4.1 to connect the TWO UARTS and using Teensy Dual Serial as in post#15/etc and easily connect those to your T_4.1 USB Host port.

At $26 for that SP2105 device that Paul needed an OOB replacement would it last long?

The Teensy can reliably and efficiently process both UARTS bidirectionally and maybe even do some pre-processing if that would help in the end. And if the data is copious the Teensy runs at 480 Mbps instead of 12 Mbps.

It will probably draw a bit more power - but for just UART data transfer to USB building with a lower clock speed could reduce that somewhat.

jmarsh · Feb 24, 2026

@defragster I think you are missing the part where OP is trying to talk to a sensor that has the CP2105 incorporated. There is no raw UART access, just a USB port.

defragster · Feb 24, 2026

jmarsh said:
missing the part where OP

Indeed - AHA

turns to Gotcha

- that was missed that in the p#23 afterthought

Though - per the initial point - still shows hope that when both 'devices' can be recognized - they should function through USB_Host core code.

Detecting 2 COM Ports of IWR6843AOP Sensor

Member

Attachments

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Member

Attachments

Member

Well-known member

Member

Attachments

Member

Well-known member

Well-known member

Senior Member+

Member

Well-known member

Senior Member+

Senior Member+

Well-known member

Member

Attachments

Member

Senior Member+

Well-known member

Senior Member+