TDA4VM-Q1: UART is not getting detected

Some additional troubleshooting details that might help narrow this down:

• The board itself is otherwise fully healthy and operational — confirmed reachable over SSH via WiFi, running normally. This issue is isolated specifically to the J4 UART-over-USB path, not a general board failure.
• Per the SK-TDA4VM User’s Guide (SPRUJ21E), connector J4 hosts a Quad UART-over-USB Transceiver (4 ports: WKUP_UART0/MCU_UART0/UART0/UART1 → COM1-4). ttyUSB2 corresponds to UART0 (the main Linux console).
• The onboard XDS110 debug probe (a separate connector/chip, used for JTAG) still enumerates fine as ttyACM0/ttyACM1 — so only J4’s transceiver is affected, not all USB functionality on the board.
• Tested multiple different USB cables on J4, including one cable confirmed working correctly when connected to a different SK-TDA4VM board — same negative result on this board regardless of cable used.
• On the host PC: ftdi_sio never loads, and no FTDI-vendor USB device (VID 0403) appears in lsusb at all, regardless of which cable or host USB port is used — the transceiver chip isn’t enumerating at the USB level, not just failing to get a driver.
• Ruled out a host-PC software/driver change: no relevant package updates occurred around when this started, and CCS was not opened/used between the last known-working session and today.
• The physical UART indicator LED near J4 is also no longer lighting, where it previously did.

This points to a hardware fault isolated to the Quad UART-over-USB Transceiver chip at J4, rather than a cable, driver, or host-PC issue. Could you confirm whether this matches a known failure mode, and advise on repair/RMA options?

Please note : We have purchased this on 16th july 2026, this product still under warranty. So request you to let us know the process in case of raising the repair request.

Hi Neha,

Thanks for the detailed troubleshooting - that narrows this down well.

A couple of corrections/notes from the SK-TDA4VM User's Guide (SPRUJ21E):

- The J4 transceiver is a Silicon Labs CP2108-B02-GM, not FTDI. On Linux the relevant driver is cp210x and vendor ID is 10c4 (not ftdi_sio/0403). This doesn't change your core finding though - lsusb shows any enumerated device regardless of driver, so "nothing appears at all" still means the chip isn't enumerating.
- LD1 specifically indicates an active COM connection with the host, so it being off lines up with no enumeration.
- This transceiver is powered from USB bus power via the host cable, independent of the EVM's own power rail.

Given that last point, a few quick checks before RMA:

1. Run "dmesg -w" and watch it while plugging in the J4 cable. Even with no driver/lsusb entry, the kernel usually logs something at the raw USB layer if the chip responds electrically at all. Total silence vs. a failed-enumeration trace tells us whether it's unresponsive or responding-but-failing.
2. Visually check the J4 connector and nearby components (including LD1) for discoloration, bulging, bent pins, or corrosion.
3. Plug the J4 cable in with the EVM fully powered off/unplugged and see if LD1 lights at all - since the circuit is bus-powered, this isolates whether the fault is local to the J4 circuit itself.

If dmesg stays silent and LD1 doesn't light even with the EVM unpowered, that confirms a dead transceiver or its local power path.

On warranty: TI's Standard Terms for Evaluation Modules give EVMs a 90-day warranty from date of delivery. Your July 16, 2026 purchase date puts you right around that 90-day mark, so I can't confirm status from here - support will need your exact delivery date.

On the RMA/repair process itself: I want to make sure I point you to the correct procedure rather than guess, so I'm confirming that internally and will follow up here.

Regards,
Jeff