The Jetson Orin Nano during COM loopback test no response

I can not find the driver for f81534 from your link.
Pleas just share the file here.

and what I want to check is the device tree (i.e. the dts file which includes the configuration for f81534).

Why you run lspci rather than lsusb to check USB issue?

Hi Kevin

driver link

Please give me the info command you need directly.
orinnx-lsusb-20231120.log (831 位元組)
xavier-lsusb-20231120.log (741 位元組)

Don’t you know what is device tree?
If not, it is dtb(compiled) file on your board or dts(source) file on your host.
Please get the /boot/dtb/kernel_XXX.dtb from both of your boards.

Actually, this driver is not from us so that I could not give you the detailed logic inside.
Just a rough example here.

Now, you got the following error:

f81534 ttyUSB0: f81534_switch_gpio_mode: failed, 1245

From the source you would know taht it’s causing from Line:1245.
f81534_set_mask_normal_register() returns unexpected value, you could print the what’s the value of status. You could also print both status for f81534_get_normal_register() and f81534_set_normal_register() to debug further.

You should ask your vendor to let us know where it gets stuck in USB driver.
We could not help to debug the custom driver.

Hi Kevin
We obtained the Fintek development board and tested it from Orin NX PCIe to USB 2.0. Over 12hrs, no problems occurred. What are the parts related to USB2.0_1 adjustment? Which files can be adjusted?

You could check usb2-1 node in device tree.

What do you mean about “Fintek development board”? Could you share the current block diagram of your connection? (failed case with successful case)

PCIe → USB → COM(Reference board) ok.
USB2.0_1 ->F81534 fail.

1 Like

Have you tried connecting other USB3 port from the board?

Have you checked in details what’s the error from f81534 driver?

and could you reproduce the issue on the Orin Nano devkit(p3768)?

USB2.0_2 port has the same problem.
error from f81534 driver has been checked by Fintek.
We are currently requesting the company to provide it.

Please let us know the specific error coming from USB driver so that we could do further debug.
You could also get a Orin Nano devkit to check if the issue could be reproduced.

The driver has been checked again by fintek.

So this issue has been resolved by their new driver?

No, fintek does not think the problem is with the IC or driver.

Have you gotten the Orin Nano(p3768) devkit to reproduce the issue?

Already applied for Orin Nano(p3768) devkit but have not obtained it yet.

Hi Kevin
1: driver for testing - Google Drive
2: Log via Teledyne LeCroy USB Protocol Suite v8.5 build 3675
orin.usb - Google Drive

Preliminary explanation:

  1. Observed from LA
    The first out token requires the device to perform the following actions:
    offset 00: 00h (UART0)
    offset 01: 02h (UART command TX)
    offset 02: 64h (TX 100 bytes)
    offset 03: don’t care.
    offset 04~104: TX data (from 64~c7h)
    But the second out token, is completely messed up.

2.After Driver timeout, print the current packet data expected to be sent.
The expected information to be sent is following picture 1. The last picture in picture 1 is c4/c5/c6/c7, and the information to be sent here is c8/c9/ca… which is correct.
But what was recorded by USB LA was not sent by the Driver (the second out token in Figure 1)

Sorry that I am not clear about what do you mean here.
Do you mean c8/c9/ca are expected? and c4/c5/c6/c7 are unexpected?

Or you mean that you don’t know where is the second token coming from?
It seems not match with your packet format.

Have you gotten the devkit to reproduce the issue?

Hi Kevin
In the first picture, the last out token is TX c6 / c7, so theoretically the next out token should start from c8.
However, the picture recorded by USB analysis is a messed up packet. The second picture is the actual data of the packet to be transmitted, and it is inconsistent with what was recorded.

How do you know “the last out token is TX c6/c7”?
From the screenshot, there are still 2E/30 in the following.

It seems there’s unexpected data measured from LA.
Please run the following command before the test and check if it could help for your case.

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service

The same problem occurs with Disable nvgetty service.

Are there any unexpected messages coming from USB port if you are not using them?