How do I change the baud rate? please

Hello ,everyone!
Please tell me how to change the baud rate on TK1? Thanks

Which baud rate?


My first question…what are you using to read the output to know when it is correct? Assuming read is external to the tk1, what kind of cabling are you using? Is there a particular serial port you want to start with? I’m going to assume ttyTHS2, I believe this goes to J3A2 (but I’m not certain if the translation between schematic numbering and /dev/ttyTHS# is 1-to-1…if my oscilloscope hadn’t died I would test by echo of text to the port).

Install the setserial package, and view the existing settings of /dev/ttyTHS2:

setserial -a /dev/ttyTHS2

I see:

/dev/ttyTHS2, Line 2, UART: undefined, Port: 0x0000, IRQ: 78
        Baud_base: 0, close_delay: 50, divisor: 0
        closing_wait: 3000
        Flags: spd_normal

Some of the data returned is obvious, e.g., baud_base; other parts are not so obvious, but are explained in the man page to setserial (e.g., divisor). The characteristics you read with setserial -a are generally the ones you can also set. In some cases you need to set a baud_base to some special number and then use the divisor to reach the effective/true speed.

To set the speed:

setserial /dev/ttyTHS2 baud_base 115200

After I did this, here is the newly set ttyTHS2:

root@tk1:~# setserial -a /dev/ttyTHS2
/dev/ttyTHS2, Line 2, UART: undefined, Port: 0x0000, IRQ: 78
        Baud_base: 115200, close_delay: 50, divisor: 0
        closing_wait: 3000
        Flags: spd_normal

Note that if you need a setting during boot there are probably kernel command line arguments or firmware changes you could make. In the case of the serial console, this is passed to the driver and then the driver makes the adjustments. This is the part of kernel command line to set the serial console:


…here is the part which sets up the local console:

console=tty1 no_console_suspend=1

Those console examples go to console drivers which set up the correct tty…there might be a similar option for serial UARTS, but I don’t know.

I managed to update the /dev/ttyTHS1-2 baudrate by calling some C function, following is the sample source code, compile and run it:

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
//#include <sys/ioctl.h>

int main(int argc, char *argv)
int uart_fd;
char *uart_name = “/dev/ttyTHS1”;
char sample_test_uart[25] = {‘S’, ‘A’, ‘M’, ‘P’, ‘L’, ‘E’, ‘\n’, ‘\r’};
struct termios uart_attr;
uart_attr.c_ospeed = 0;

if(argc > 1) uart_name = argv[1];

uart_fd = open(uart_name, O_RDWR | O_NONBLOCK | O_NOCTTY); //

if(uart_fd < 0){
printf(“error opening UART %s, aborting…\n”, uart_name);
return uart_fd;

if(tcgetattr(uart_fd, &uart_attr) < 0) {
printf(“failed to read uart attibute, aborting \n”);
return uart_fd; }

printf("UART speed is %d\n", uart_attr.c_ospeed);

//cfsetspeed(&uart_attr, B38400);
cfsetspeed(&uart_attr, B921600);
printf("B38400 is %d\n", B38400);
printf("B921600 is %d\n", B921600);

//uart_attr.c_ospeed = B38400;
//uart_attr.c_ispeed = B38400;

if(tcsetattr(uart_fd, TCSANOW, &uart_attr) < 0) {
printf(“failed to set uart attibute, aborting \n”);
return uart_fd;

printf(“writing to UART %s\n”, uart_name);
int result = write(uart_fd, sample_test_uart, 8);

printf(“write %d byte to UART\n”, result);


when I open the “/dev/ttyTHS1” without the O_NONBLOCK, the open function will block. anyone know something about this?

You will probably want to give information on how you opened ttyTHS1 (including whether for read, read-write, or write) and whether the nature of what the serial side is talking to. It is possible that since a UART is physical hardware you might be running into some aspect which is normal for such hardware…don’t know, need more details of exactly how the UART is being opened, when it is being blocked, and what you actually expected to occur. Also a note on what release is used (“head -n 1 /etc/nv_tegra_release”).

I just use the code above post by TKAI.But I have fixed this issue. I add the code “memset(&uart_attr, 0, sizeof(uart_attr));” before modify the attribute, after tcgetattr. I think some config of the attr default are not suitable, but I dont kown which attribute make it. My board is Customized with TX2, and the tegra_release is R28.2.1. Thank you @linuxdev.

This is the defined behavior. Is there more to the description, e.g., are you saying that when the function blocks and then data arrives it fails to continue?

I mean the open function will block if without O_NONBLOCK. I did not try to send data to the uart, the uart was floating. I thought the open function will not block, even something is wrong ,it will only return failed.

Removing O_NONBLOCK is supposed to cause blocking. That’s the very definition, it isn’t a bug. If you’ve been comparing how this behaves on some other file types, then the comparison probably wasn’t valid since this is a hardware driver implementation of serial I/O and is neither purely in software nor is it a block device.

Let me rephrase…what would you like to accomplish? You can’t stop hardware serial I/O from being bound to hardware and kernel drivers, so maybe there is some other approach. If you have problems with efficiency of polling or blocking behavior, then you might work around it with some method such as running the I/O in its own separate thread.


Problem statement: i want to communicate from jetson to another Microcontroller,
i can successfully able to read the data from serial:Serial( ‘dev/ttyTHS1’, 57600), but when i am sending the data it is not showing any response

i have tried way arround which is . i have connected the ttl to usb converter from jetson nano to microcontroller , i could read and write the data and micrcontroller also repond to it.

Do you have some explaination or solution for this, it would be great help.

Alread tried : to disable nvgetty

This should be a new post. I’ll guess it needs a pull-up or pull-down resistor if the UART is already at the correct voltage (3.3V). There is normally no need for such a resistor, so I couldn’t tell you what value to use.

Note that having a port talk to itself via loopback is a good hardware test…simply connect the TX and RX together, and name the port “/dev/ttyTHS1” from a serial terminal program (such as minicom). Then try different settings. It should echo whatever is typed. If this occurs, then you know the issue is not that the port itself fails.