I have turned off the system debugging message and set it to the common Uart, but data loss will occur in this serial port. Besides the system console, is there any program in the system that will send data to the DEBUG? Or what still uses the UART1 of the core module. In addition, the lost bytes are very small, about two bytes. Could it be a check signal set by the system? Of course, these are just my guess. I hope to find a solution to this problem.
How do you check the data loss?
Please give step for reproducing it.
Thanks
We write a test program to receive the PC application sends data, the function of the test procedure is as follows: when the UART receive the number of bytes to send at the same time, the number of bytes phase under a machine without a phenomenon, when the UART receive bytes and send the number of bytes is not at the same time, under a printing machine terminal receives the total number of bytes to the current number of bytes received.After a lot of practical test we found the rule, when the PC sends the number of bytes to 8 bytes integer times, lower machine UART receive will not be lost, but if the number of bytes sent is not the integer times of an 8 bytes, lower machine will only keep 8 bytes of the integer times of data, more than eight integer times of data will be lost.
This phenomenon occurs only when the modified DEBUG UART is used, and the occurrence time is not fixed. Everything is normal when the two UART other than DEBUG are used, one of which is RS232 and the other is TTL.
The lower computer program is in the board card of Jetson Xavier NX 4.6.2, while the upper computer is a serial port tool in Windows. I used C language and Python to achieve similar test functions, and the test conclusion was consistent, so I determined that the test program was OK.
I wonder, does the internal hardware of the core module do anything else with the pin corresponding to DEBUG? Maybe there are other programs in the system that operate on it besides the console consent message, or maybe the DMA interrupt trigger prevalues of DEBUG UART are different from the DMA interrupt trigger prevalues of the other two UART, I am eager to find a solution to the problem, thank you
rs232_test_ros.py (1.6 KB)
