Q: I am trying to establish a UART connection between the jetson nano b01 board and esp8266. I am plugging an esp8266 USB cable into one of the ports of Jetson Nano. After that, I tried lsusb, lspci, dmesg commands in the terminal of ubuntu(nano), but I am not getting port in terms of ttyUSB*/ttyACM*/ttyTHS*, after lsusb it is detecting and showing in BUS 2 & channel form. I simply wrote Python code after installing pyserial lib to send/receive data to/from nano and esp8266, but not work. In my case, the port must be in the form of THS*.
can someone pls help?
If you have the esp8266 on, and the Jetson is fully booted, and you monitor “dmesg --follow” on the Jetson, what additional log lines show up as a result of plugging in the USB cable?
Thank you so much for your reply @linuxdev,
I tried dmesg --follow, It is generating detailed logs but what I found it is not able to get me the exact port number. I tried a few ports randomly but UART communication failed every time. I have also tried using product ID and vendor ID.
Seems like an issue with the CH340G driver. So, I am working on that as of now.
I was hoping you could post the message that appears as a result of the plug-in. USB is “hot plug”, or “plug-n-play”. This means it is just a communications pipe, but that the device is described to drivers, and a driver can take ownership. Knowing what the message is offers information on what the drivers were thinking (or not thinking).
Apologies for the delay in thanks and thanks for guidance.
Here is something you can help
[ 9.435957] device rndis0 entered promiscuous mode
[ 9.440579] IPv6: ADDRCONF(NETDEV_UP): rndis0: link is not ready
[ 9.444804] l4tbr0: port 2(usb0) entered blocking state
[ 9.444809] l4tbr0: port 2(usb0) entered disabled state
[ 9.444949] device usb0 entered promiscuous mode
[ 9.449282] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[ 9.666058] soctherm: OC ALARM 0x00000001
[ 11.281966] eth0: 0xffffff800ab11000, 48:b0:2d:69:f7:59, IRQ 406
[ 11.389330] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 11.656368] soctherm: OC ALARM 0x00000001
[ 12.794289] soctherm: OC ALARM 0x00000001
[ 13.199107] IRQ11 no longer affine to CPU2
[ 13.203551] CPU2: shutdown
[ 13.206267] psci: CPU2 killed (polled 0 ms)
[ 13.267067] IRQ12 no longer affine to CPU3
[ 13.271486] CPU3: shutdown
[ 13.274787] psci: CPU3 killed (polled 0 ms)
[ 33.909345] vdd-fan: disabling
[ 33.909387] vdd-usb-vbus: disabling
[ 33.909417] vdd-usb-vbus2: disabling
[ 33.909497] vddio-sdmmc-ap: disabling
[ 33.909836] vddio-sdmmc3-ap: disabling
[ 33.910096] vdd-3v3-sd: disabling
[ 33.910138] avdd-io-edp-1v05: disabling
[ 33.910169] vdd-usb-hub-en: disabling
[ 321.519222] device-mapper: table: 253:0: thin-pool: unknown target type
[ 321.526158] device-mapper: ioctl: error adding target to table
[ 324.096011] device-mapper: table: 253:0: thin-pool: unknown target type
[ 324.111444] device-mapper: ioctl: error adding target to table
[ 326.802126] device-mapper: table: 253:0: thin-pool: unknown target type
[ 326.808856] device-mapper: ioctl: error adding target to table
[ 541.779800] r8168: eth0: link up
[ 541.780296] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1334.355185] r8168: eth0: link down
[ 1337.505927] r8168: eth0: link up
[ 1809.555188] r8168: eth0: link down
[ 1817.761918] r8168: eth0: link up
[ 1820.819260] r8168: eth0: link down
[ 1833.121934] r8168: eth0: link up
[ 1972.370822] r8168: eth0: link down
[ 1990.849363] r8168: eth0: link up
[ 2780.419582] usb 1-2.3: new full-speed USB device number 6 using tegra-xusb
[ 2780.443914] usb 1-2.3: New USB device found, idVendor=1a86, idProduct=7523
[ 2780.443976] usb 1-2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 2780.444020] usb 1-2.3: Product: USB2.0-Ser!
[ 2898.124855] usb 1-2.3: USB disconnect, device number 6
[ 4723.935103] usb 1-2.3: new full-speed USB device number 7 using tegra-xusb
[ 4723.959579] usb 1-2.3: New USB device found, idVendor=1a86, idProduct=7523
[ 4723.959643] usb 1-2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 4723.959688] usb 1-2.3: Product: USB2.0-Ser!
[ 4929.483777] usb 1-2.3: USB disconnect, device number 7
[ 5077.210048] usb 1-2.3: new full-speed USB device number 8 using tegra-xusb
[ 5077.234599] usb 1-2.3: New USB device found, idVendor=1a86, idProduct=7523
[ 5077.234665] usb 1-2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 5077.234712] usb 1-2.3: Product: USB2.0-Ser!
utsav@hostnano:~$
Which part of that is a result purely of the plug-in event? It is important to know if some part of it was from unplug or if part was from boot while already plugged in. I need to differentiate logs which are specific to plug-in.
I ask in part because I see three disconnect events. If these are part of a single plug-in event, then this is important to know it was self-disconnecting. If you unplugged and re-plugged, then I need to remove that information.
Assuming this subset of log is what occurred from plug-in (and it might not be just that subset, you need to confirm):
[ 5077.210048] usb 1-2.3: new full-speed USB device number 8 using tegra-xusb
[ 5077.234599] usb 1-2.3: New USB device found, idVendor=1a86, idProduct=7523
[ 5077.234665] usb 1-2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 5077.234712] usb 1-2.3: Product: USB2.0-Ser!
Then I would say that detect is working. The vendor and product IDs from the USB ID database:
Vendor 0x1a86: QinHeng Electronics
Product 0x7523: Not part of the database.
Something a bit concerning, but perhaps not actually a problem: Product: USB2.0-Ser!
I say this because it looks like this company has a lot of UART devices which are rebranded CH340 devices. The “Ser!” says maybe the device is missing part of its description; this, in turn, says maybe the device itself has corrupted data in the USB BIOS. I can’t say for sure because perhaps this is the intended programmed description, and such descriptions don’t normally cause issues.
One thing we don’t know yet is the full USB response. We could do it the hard way through /sys, but what do you see from “lsusb”? We can use that to ask the device to respond to queries.