display monitor error

Hi
I have a monitor error while doing ‘FTDI serial usb to TTL’ with jetson tx1.
I do not see anything on the monitor screen except for the desktop.
What’s the problem?
What should I do?
please help me.

Hi n0nename,

What error do you see? Could you paste your kernel message here? Use “dmesg” to show the log.

thank you for your reply
but I can’t see the terminal window.
I can’t see anything…

Do you have UART console that can debug? or ssh with known IP?

no, I don’t have it…

If you want to set up a serial UART for console, here is the info (this would work even when video and much of the system fails):
http://elinux.org/Jetson/TX1_Serial_Console
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/

Is it correct the failure occurs when the FTDI serial device has the USB connector put on the Jetson itself (meaning the Jetson USB port is used, not the serial port)?

sorry. I’m beginner. so I can’t understand well about your word.
if I correctly understood about your word, i didn’t connect USB port.
I want to know :

  1. I wonder if I can export serial via jetson tx1.
  2. Can I use the CP2102 to output UART communication?

I really appreciate your interest.

I am referring to the original problem statement:

I have a monitor error while doing 'FTDI serial usb to TTL'

I interpret this to mean you failed to receive correct serial port communications when using an FTDI serial UART. But then I see CP2102 mentioned…I am not sure which is the problem, or if both are involved. I am not really sure what the question is, it is somewhat confusing, so I’ll just give some common serial UART information which might trigger a new question.

The CP2102 is not FTDI. I am confused by whether you are talking about an error from CP2102 or whether you are talking about an error from FTDI. Typically, FTDI is supported by default and has a driver already installed. CP2102 is unlikely to work without adding a driver. I am also not sure whether the USB side of a serial-to-USB cable is connected to the Jetson or a PC host.

For the Jetson side are you using a built-in serial port? If so, which one? Which physical connector, and which device special file? If not, is the USB for a CP2102 or FTDI chipset?

If the CP2102 has a driver, then it should work for serial communications if the serial port settings are correct. The driver is only required on the side which USB is connecting to.

Can you give more information on this earlier description?

but I can't see the terminal window.
I can't see anything....

What application are you using for a terminal window? I suggest experimenting with minicom, gtkterm, and cutecom. Note that by default most name a serial port only as names similar to “ttyS0…ttyS#”. A tty by name “ttyTHS0…ttyTHS#” may require editing an init file used by the terminal program if naming convention does not expect this name format (or manually typing in the ttyTHS name if the list of available ttyS allows this). The ttyTHS# naming is for serial ports using NVIDIA’s DMA-enabled serial UART; the ttyS# format is for simple serial UARTs. Which ttyS/ttyTHS are you using on the Jetson side?

When you use a serial port there are actually two UARTs involved…one at each end. If the two do not match settings, then the port won’t work or will display corrupt data. This will be true regardless of using a CP2102 or an FTDI UART. It sounds like you are saying your serial terminal shows no output at all. If this is correct, then I suggest you start with a loopback test.

About Loopback…
A serial port has a TX wire and an RX wire for data. Optionally, the CTS ad RTS are used for flow control (which helps more as speeds go faster or wire lengths get longer). Normally the one UART’s TX goes to the other UART’s RX, and if hardware flow control is being used, then one UART’s CTS goes to the other UART’s RTS. Loopback involves using only one UART and wiring its own RX to TX (and optionally CTS to RTS if using hardware flow control).

When in loopback there is only one UART and so you can be guaranteed that there is a match of settings at each end of the communications…you can test functionality at a given speed and not worry if both sides of the connection have matching settings. If you have your serial console program running at a given setting, then typing something in should echo and you will see what you typed. This implies if another serial UART is connected to the first (instead of loopback), and if that other UART has this setting, then you are guaranteed that any failure is due to wiring and not due to settings. By testing each side of the connection in loopback with settings being the same on both sides you can eliminate software issues as being a problem when the two connect.