How to Improve the serial interrupt response

Now I have a serial’s question about ttyTHS2 on r24.2.2.
We have a case that when we send and receive at the same time for the large amounts of discontinuous data at very short intervals in the serial port terminal, 
there will always cause the data package lost  . 
Is this because the CPU cannot respond, which resulting in the loss of interrupt? 
How should I debug to solve this problem? 
How to raise the priority of serial interrupt?

I can’t completely answer this, but to start with make sure performance is set to max via:

sudo ~ubuntu/jetson_clocks.sh

Keep in mind that there is a very limited buffer within a serial UART. There is no mechanism within the UART itself for flow control, that is up to software. Software can choose CTS/RTS flow control and improve responsiveness of UARTs behaving well with regard to buffer overflow.

At faster speeds there may be issues with the clock being slightly off…in which case two stop bits should improve things.

What settings are you using? The default is 115200 8N1. Any faster and two stop bits should be used (“8N2”). CTS and RTS wires can be used and software told to use CTS/RTS flow control.

Note that on a TX1 all hardware interrupts go through CPU0. If you increase the priority slightly, then you might get what you want, although if priority increase is needed there might be other things going on. You are better off first attempting two stop bits. Increasing priority implies the only core handling hardware interrupts is blocked from doing something else with other I/O.

Hello,I make sure performance is set to max via,but this problem no solve;
My serial setting in 1000000 8N1,After the kernel of print information, thart is not deviation, in this baud rate.
Now the biggest problem is that the serial has been received data flow more than 120 hz, after my test, I write when the serial data come in, must lead to the read data lossed,.

what reason tho causes this problem, is a serial port interrupt priority is lower then leading to interrupt loss, or serial port driver not working in Full duplex,or have a bug in this serial driver frame?

Not all speeds will work. Many UARTs have higher speeds set through a divisor (and thus must be integral multiples of the base clock).

Above 115200 you definitely need two stop bits, the 8N1 will not work.

Drivers which report speed only know what they have told the hardware. UARTs are not capable of replying to the driver what their actual speed is. When you query the driver and it says it is 1000000, then the driver told the hardware to do this…but if the hardware can’t do that, then it won’t really be 1000000.

First correct by using two stop bits. After that you can test at whatever speed you want and you should get useful information.

Additionally, above 115200 speed, you really should use CTS/RTS flow control. Overruns can be dealt with faster and more reliably. Without flow control there is nothing to cause a stop of transmission when the buffer fills. Many 16550A implementations only have about 15 bytes of buffer. Earlier implementations might have no buffer at all.

I make sure tx1 can working 1000000 8N1,because my transmitting device is working in 1000000 8N1 and if the baudrates on both sides are quite different which kernel will get “Got frame errors”.
Now problem is if I don’t write any data in tx1 serial then will read all data perfectly,or write the data in serial but after read serial data,also can read all data perfectly.

So,I guess the serial driver has a problem when recevive the large amounts of discontinuous data at very short intervals will leads poor performance in serial IO.

Amd our hardware conditions make it impossible for us to adopt control flows.

Two stop bits gives more time for drivers to adjust, but at higher speeds even that may not be enough. Keep in mind that most UARTs, when in 16550A compatibility mode, have only 15 bytes of buffer. At 1Mbps that’s a very short time…an IRQ would have to service before the next byte arrives, or else there would be loss. Or…flow control can say to wait. Unless you have a dedicated hard real time o/s and CPU combination.

If you really need that high of a bit rate, and cannot change flow control, then a USB serial UART might be a better option since it may be possible for USB to do the buffering.