AM4378: AM437x /dev/ttyS1 get stuck

Hi Nancy,

Is this test done on TI EVM? If not, does it happen on TI EVM too?

Hi，

It's custom board. He didn't test on EVM board, because there is no uart lead out on this EVM.

UART configuration:

Baud rate:230400

Data bits: 8

stop bits:1

Nancy,

Nancy Wang said:

After executing the program for a short time and then kill it.

Instead of kill the program, if the program runs for a short time then closes the UART port and exits, does the issue still happens?

Also does the issue happen on Processor SDK v6.3.0.106 too?

Bin Liu said:

Nancy,

Nancy Wang

After executing the program for a short time and then kill it.

Instead of kill the program, if the program runs for a short time then closes the UART port and exits, does the issue still happens?

Yes. And the issue still happen in Processor SDK v6.3.0.106

The difference is the kernel. The kernel is also based on the kernel in the processor SDK v6.3.0.106. Customer has add some customize drivers, the uart1 configuration is based on am437x-gp-evm.dts.

Nancy,

Nancy Wang said:

Yes. And the issue still happen in Processor SDK v6.3.0.106

Does it happen only when manually "kill' the program or it also happens when let the program close the UART and exit?

Nancy Wang said:

Customer has add some customize drivers, the uart1 configuration is based on am437x-gp-evm.dts.

Please provide more details, what are the customized drivers?

BTY, the AM437x GP EVM has UART1_TX and UART1_RX singals routed to the DB9 connector J37. I think you can test it on the EVM. You would have to modify the pinmux of these two signals, which are set for DCAN1 in device tree.

Yes ，it also happens when let the program close the UART and exit.

Okay. Thanks for the update.

Can you please ask the customer to test on the AM437x GP EVM using the J37 DB9 connector?

Hi，

The customer has test on AM437x GP EVM.

The EVM can receive data normally. After executing the uart_test program several times (5~6 times), the issue still happens. And It is confirmed that it has nothing to do with the customized drivers.

Below is uart_test code.

Nancy,

Thanks for providing the test code, I will have a setup to run the test.

What is connected to the AM437x UART1 to send data? How the data are send?

Hi,

Thanks!

Tera term or putty.

Sorry Nancy, I just noticed that there is CAN transceiver (ISO1050) is in between AM437x UART1 and DB9 connector J37 on AM437x GP EVM, so I don't think J37 connector can be directly used to test UART1. Can you please explain how the customer tested on the AM437x GP EVM? Have they modified the EVM to bring out UART1 TX/RX signals?

Hi，

He removed R177 and R178, and connected UART1 with jump wire.

Nancy,

Thanks for the update. I am requesting my board to have the similar modification so that I can run the test. The process for the modification will be slow due to pandemic. I will update once I made progress.

Hi:

I am the author of this question.

The computer connects to the AM437x GP EVM through USB to serial port tool, and sends data to the AM437x GP EVM through serial port assistant.

Is there any solution to this problem?

Hi,

Sorry for my late response. I don't have access to my AM437x GP EVM in the next couple days. I will provide an update later this week.

Hi:

I set up the same configuration on both sides and checked, but again, there will be a problem

I connected to EVM using the computer of Win7 system. The configuration of data bit, check bit and stop bit is the same.The data is sent and received normally and correctly, the test still has this problem.

Hi,

The tty termios settings have more attributes than just parity or stop bits. Please ensure all of them are the same on both sides of the UART connection. I am not sure how to check the settings on Windows system, but on Linux, you can use command 'stty -F /dev/ttyS1 -a' to check the settings for UART1.

root@am437x-evm:~# stty -F /dev/ttyS1 -a
speed 230400 baud;stty: /dev/ttyS1
 line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel
-iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten -echo -echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho
-extproc

You can also run the tool serialstats from https://github.com/nsekhar/serialcheck on the AM437x board to check if there is any line error on its UART1 port, when the lockup happens.

Hi，Thank you for answering！

I did as you asked，Linux is used on both sides and the same serial configuration is set up on both sides（Confirm the configuration information for both sides using stty -F /dev/ttyS1 -a）,The problem is still there.But I've noticed some patterns.

the code run on board:

#include     <stdio.h> 
#include     <stdlib.h>  
#include     <unistd.h>   
#include     <string.h>   
#include     <sys/types.h> 
#include     <sys/stat.h> 
#include     <fcntl.h>  
#include     <termios.h> 
#include     <errno.h> 
    
int main() 
{ 
    int fd; 
    int fd1; 
    int i,j; 
    int len; 
    int n = 0;       
    char read_buf[1024]; 
    char write_buf[1024]; 
    struct termios opt;  
     
    fd = open("/dev/ttyS1", O_RDWR | O_NOCTTY|O_NONBLOCK );    //默认为阻塞读方>式 

    tcgetattr(fd, &opt);  
 
    printf("ttyS1\n"); 
    printf("c_iflag=%x\n", opt.c_iflag); 
    printf("c_oflag=%x\n", opt.c_oflag); 
    printf("c_cflag=%x\n", opt.c_cflag); 
    printf("c_lflag=%x\n", opt.c_lflag); 
    printf("c_line=%x\n", opt.c_line); 
 
 
    cfsetispeed(&opt, B230400); 
    cfsetospeed(&opt, B230400); 
     
    if(tcsetattr(fd, TCSANOW, &opt) != 0 ) 
    { 
       perror("tcsetattr error"); 
       return -1; 
    } 
  
 #if 0    
    opt.c_cflag &= ~CSIZE;    
    opt.c_cflag |= CS8;    
    opt.c_cflag &= ~CSTOPB;  
    opt.c_cflag &= ~PARENB;     
    opt.c_cflag |= (CLOCAL | CREAD);   
    opt.c_oflag &= ~OPOST;      
    opt.c_oflag &= ~(ONLCR | OCRNL);    //添加的        
    opt.c_iflag &= ~(ICRNL | INLCR);      
    opt.c_iflag &= ~(IXON | IXOFF | IXANY);    //添加的           
    opt.c_cc[VTIME] = 0;      
    opt.c_cc[VMIN] = 0;   
         
    opt.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);   
#else 
        opt.c_iflag=0; 
        opt.c_iflag=0; 
        opt.c_oflag=0; 
        opt.c_cflag=0x1cb3; 
        opt.c_lflag=0x8a20; 
        opt.c_line=0 ; 
#endif 
 
    tcflush(fd, TCIOFLUSH);        
    printf("configure complete\n");           
    if(tcsetattr(fd, TCSANOW, &opt) != 0)      
    {          
        perror("serial error");          
        return -1;      
    }      
    printf("start send and receive data\n");       
    j = 0;   
    while(1)      
    {              
        n = 0;          
        len = 0;          
        memset(read_buf, 0,sizeof(read_buf));    //类似于memset          
        memset(write_buf,0, sizeof(write_buf));            
        if( (n = read(fd, read_buf, sizeof(read_buf))) > 0 )         
        {              
            for(i = len; i < (len + n); i++)              
            {  
                write_buf[i] = read_buf[i - len]; 
            }  
            len += n;  
 
            write_buf[len] = '\0'; 
            write_buf[len] = '\0'; 
            printf("\nstr=%s \n", write_buf);        
            sleep(1); 
        } 
 
        if(n > 0) 
        { 
            j++; 
            if(j > 10) 
            { 
                close(fd); 
                return 0; 
            } 
        } 
 
    }  
 
    return 0; 
}

the code run on Ubuntu:

#include     <stdio.h>
#include     <stdlib.h>  
#include     <string.h> 
#include     <unistd.h>   
#include     <sys/types.h> 
#include     <sys/stat.h> 
#include     <fcntl.h>  
#include     <termios.h> 
#include     <errno.h> 
 
#define BUF_SIZE 512 
    
int main() 
{ 
    int fd1,fd2; 
    int i; 
    int len; 
    int n = 0;       
    char read_buf[BUF_SIZE]; 
    char write_buf[BUF_SIZE]; 
    struct termios opt;  
    fd1 = open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK );//| O_NOCTTY);    //默认为阻塞读方式 
    if(fd1 < 0) 
    { 
        perror("open serial 0\n"); 
        exit(0); 
    } 
 
    tcgetattr(fd1, &opt);  
 
    cfsetispeed(&opt, B230400); 
    cfsetospeed(&opt, B230400); 
 
    opt.c_cflag &= ~CSIZE;    
    opt.c_cflag |= CS8;    
    opt.c_cflag &= ~CSTOPB;  
    opt.c_cflag &= ~PARENB;    
    opt.c_cflag |= (CLOCAL | CREAD);   
    opt.c_oflag &= ~OPOST;      
    opt.c_oflag &= ~(ONLCR | OCRNL);    //添加的        
    opt.c_iflag &= ~(ICRNL | INLCR);      
    opt.c_iflag &= ~(IXON | IXOFF | IXANY);    //添加的    
    opt.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); 
 
    printf("c_iflag=%x\n", opt.c_iflag); 
    printf("c_oflag=%x\n", opt.c_oflag); 
    printf("c_cflag=%x\n", opt.c_cflag); 
    printf("c_lflag=%x\n", opt.c_lflag); 
    printf("c_line=%x\n", opt.c_line); 
    tcflush(fd1, TCIOFLUSH); 
    if(tcsetattr(fd1, TCSANOW, &opt) != 0)      
    {          
        perror("serial error");          
        return -1;      
    } 
 
    printf("start\n"); 
 
    for(i=0;i<sizeof(write_buf)-1;i++) 
    { 
        write_buf[i] = 65; 
    } 
    write_buf[BUF_SIZE-1]=0; 
    while(1)      
    {                 
        memset(read_buf,0, sizeof(read_buf));    //类似于memset  
        len = write(fd1,write_buf,sizeof(write_buf)); 
        if(len != sizeof(write_buf) || len < 0) 
        { 
            printf("write date error\n"); 
		}
        //sleep(1); 
        usleep(500000);}  
    printf("return\n"); 
    close(fd1); 
 
    return 0; 
} 

When you sleep time long enough(Such as sleep(1)), it's almost never a problem,but When sleep time is short(such as use usleep(500000),Make sure the write operation works); Problems are more likely to arise.

Hi,Thank you for answering! I did as you asked, using Linux on both sides to ensure the same configuration on both sides, but the problem still exists. But I did post a few rules, and when the PC sends a large amount of data frequently, the problem is easier to repeat.When the PC sends a small amount of data and infrequent, this problem will not occur.

Hi,

The program you used on the Ubuntu PC sending UART data in an ifinite loop. Do you stop it when re-run the program on AM437x? or the PC was constantly sending data while re-run the program on AM437x?

Did you run the serialstats tool I mentioned in my previous response and does it report any line error on AM437x?

Hi,

Yes,The PC has been sending data without stopping,the PC was constantly sending data while re-run the program on AM437x.

you ask to  check if there is any line error on its UART1 port when the lockup happens.but when the lockup happens,The system is stuck and can't do anything except reboot.

When the system on the board is normal, the board runs serialstats tool, the PC sends data all the time, and serialstats tool shows no error only overrun.The serial port may not be able to handle the resulting deadlock.

I'm sure there will be problems with both sides using the same serial port configuration, so you can test and repeat the problem several times.