Hello,
I have a serial communication at 2400 baud 8 Bits parity even of poor quality, and I receive a lot of parity errors. After an undetermined number of parity errors, the processor starts giving without stopping the FF char, with a parity error.
The input hardware signals are at rest. It is as if the receive interrupt flag never returns to 0.
Monitor in function "imx_rxint" of file imx.c
OS: Linux 4.14.218
µP : is an imx6ULL
Have you ever encountered this problem?
What can I do to stop it?
Thank you for your help.
解決済! 解決策の投稿を見る。
Hello,
Thank you for your response.
No, I don't use flow control.
I have made progress on understanding and solving the problem.
My communication has a lot of parity error but also the reception of break error.
Here is the result of the ioctl command with the parameter "TIOCGICOUNT".
I think µP has a problem under these particular conditions.
Here's the solution I've implemented is one that works. When the number of errors reaches a threshold I do a software reset using the "UCR2_SRST" bit. In the "Part-of_imx.c" file the part of code added.
I have proof that it takes the µP out of this permanent FF sending state in the file "TheProof.txt"
do you think this is the right solution ?
Jean-françois
Did you try to deactivate DEBUG_SERIAL? If the baud rate of your debug output is slow this may cause the errors.
Hello Jamesbone,
Thank you for your response.
The debug is already disabled in the kernel. Here is the lines of .Config Kernel.
Is there another DEBUG to deactivate ?
Do you think you can share some of the code? are you using flow control? becaue in the i.MX6UL there is no signal of flow control in the uart.
Hello,
Thank you for your response.
No, I don't use flow control.
I have made progress on understanding and solving the problem.
My communication has a lot of parity error but also the reception of break error.
Here is the result of the ioctl command with the parameter "TIOCGICOUNT".
I think µP has a problem under these particular conditions.
Here's the solution I've implemented is one that works. When the number of errors reaches a threshold I do a software reset using the "UCR2_SRST" bit. In the "Part-of_imx.c" file the part of code added.
I have proof that it takes the µP out of this permanent FF sending state in the file "TheProof.txt"
do you think this is the right solution ?
Jean-françois
Hello JamesBone,
Yes, this software solution fixes the problem.