Use USB ports as FTDIs for multiple UARTs (custom carrier)

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
,
1

Hi. Using a custom carrier with Orin NX + SSD, flashed with a image built with Yocto (Jetson Linux release: R35.5.0 JetPack release: 5.1.3)

On the normal devkit carrier, there are 4 USB ports. I’ve replaced it with 2 FTDIs, like the following:

image

root@p3768-0000-p3767-0000:~# dmesg | grep tty
[    0.000000] Kernel command line: mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb ipv6.disable=1 audit=0 ipv6.disable=1 audit=0
[    0.275490] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 65, base_baud = 0) is a SBSA
[    1.882535] printk: console [ttyTCU0] enabled
[    3.756296] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 17, base_baud = 0) is a TEGRA_UART
[    3.771035] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 63, base_baud = 0) is a TEGRA_UART
[    3.785787] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 64, base_baud = 0) is a TEGRA_UART
[    7.382253] systemd[1]: Created slice Slice /system/getty.
[    7.383918] systemd[1]: Created slice Slice /system/serial-getty.
[    8.187436] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[    8.222714] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
[    8.472178] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB2
[    8.491034] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB3

Im able to find one of the FTDIs and use the UART to send input and receive it back (chanting TX with RX, using ttyUSB0, ttyUSB1, ttyUSB2 and ttyUSB3), however, im not able to find the other FTDI.

When I test on the DEVKIT carrier, I can use all the 4 USB ports with no issues.

My first question is: Do I have to enable something extra for this to enable it from the software part?

3

Hi robyawyx,

It seems only one FTDI device recognized on your custom carrier board.
Do you have any custom design in USB part different from the devkit?

You can also check dmesg and run lsusb on your custom board and the devkit to compare the difference.

4

Hi.
No, the design should be the same (USB pins directly to FTDI).
When I test on the devkit, I’m able to use all the FOUR USB ports.

When running lsusb on the custom carrier, only 1 FTDI appears.
Ive also tried to switch sides (so USB0 to FTDI_1 and USB1 to FTDI_0) and I was able to understand that the problem here is USB1. USB0 still works on FTDI_1. Im not sure what to do next, maybe I’ll try to use USB_2 instead, so I can check if there’s a problem with USB_1, but I dont think so.

i have CONFIG_USB_SERIAL_FTDI_SIO=y and the FTDI’s are FTDI FT4232 - FT4232H-56Q-REEL

Do you have any suggestion? I’m confused if this is a hardware issue or software/OS issue.

5

This is just a general comment, and might be completely wrong for this case. Generally speaking, many hardware devices are not “plug-n-play”, which means they cannot self-report what they are such that a driver will find them. USB devices are certainly plug-n-play, but the controller chip itself which acts as a root HUB very very likely needs to have its information passed to the driver before it can load for that device. The method of choice for this is the device tree entry, which normally offers an alias@<hex address> type node, and within that a “compatible” list of drivers which would pay attention to this. Finally a “status=okay” to tell the driver to use that information. If your device tree is wrong, it is quite possible the driver simply does not know how to find the hardware.

1 Like
6

Hi, thanks for answering.
While I understand your comment, I don’t think this is the case, since the USB ports work fine on the DEVKIT. Then, USB0 to FTDI0 also works, but USB1 to FTDI_ does not. So I don’t think this is a driver issue (?). There can be a issue on the carrier, but I’m not sure how to debug and discover what is wrong here.

7

If the devkits work as expected then I think there may be custom design on your board to cause this issue.

Can you help to compare the dmesg on the dekvit(working case) and your custom board(failed case)?

8

If there is any pin of the module that has multiple possible uses, and if your carrier board differs in any way for that routing, then the device tree must be changed. I am thinking that perhaps your USB1 to FTDI_ involves a change in physical address, either directly or indirectly. An indirect issue example is a power rail.

9

Hi, I think we found the issue. The problem is: USB0 on the CARRIER is the TYPE-C (which is used for programming) connector which is different from ORIN NX one. We are confusing SoM ports and Carrier ones. Will answer soon if this was the problem.

1 Like
10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.