Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
GPIO UART - Missing characters when sending longer strings #1855
After upgrading from the 4.4.x kernel branch to 4.9.x using rpi-update I started noticing missing data on the GPIO UART when transmitting longer strings that are being echoed, character by character, back to the sender.
The initial tests were performed with our circuit board that uses the UART for communication. Normal communication seemed to work fine since in most cases sends to our device are single characters, but one case when we sent a larger configuration string caused missing data to become apparent. This device uses 115200 baud and has had no issues with previous versions of the Pi boards or firmware. See Test #1 below.
In order to eliminate our device firmware as causing the issue I replaced it with a TTL serial adapter connected to my workstation with a simple python script that read and echoed each character it received. See Test #2 below.
The tests were performed simply by pasting a long string into 'screen' that had the UART open. After a certain point the communication breaks in a specific pattern. See comparisons below. It should be noted that none of the missing characters were received by our device or the echo script. I was able to replicate the issue with 9600, 19200, 115200, and 330400 baud. It seems like the lower the baudrate the more consistent the issue. At 9600 baud it happens nearly every time, while 115200 might take a few attempts.
Device: Raspberry Pi 3 Model B
Test Results #1 (with our device):
Test Results #2 (with echo script):
Okay, so I think I've made a little progress on this. It appears to be an issue with the mini-uart in the 4.9.x kernel that was not present in the 4.4.x series.
Latest OK Kernel: Linux raspberrypi 4.4.50-v7+ # 970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
As for the GPIO version, the error case isn't reproducible by just, for example, holding down a key inside of screen. I've only seen it while sending a "large" amount of data at it. My current real-world test string is 92 characters, however the breaking point seems much smaller than that: anything over 11 characters starts the pattern of missing characters. Maybe the transmit buffer is filling up too fast, at which point the slower clock can no longer keep up with it?
Test String and Echoed Response
Please let me know if you need anything else.
referenced this issue
Jun 16, 2017
The regression is caused by a bug/difference in the UART hardware exposed by switching to the dedicated upstream AUX UART driver instead of using a generic 16550 driver with a few additional settings.
The 8250/16550 driver supports many different variations on the original 8250 design, with parameters and flags to modify the behaviour. It also supports a number of pre-canned configurations, selected using Device Tree
Linux 4.9 introduced a
tx_loadsz controls how many bytes are written to the TX FIFO on each attempt - larger values should reduce interrupts and increase line utilisation. Unfortunately the MINI UART has a THRE (TX FIFO "empty") bit that is really means "not full", so writing more than one byte after checking THRE can lead to data loss. Luckily we already have a CAP_MINI flag indicating that we are dealing with a MINI UART, so it is easy to add an extra test within the transmit loop that the FIFO hasn't just gone full.
A patch adding this extra THRE checking is now in rpi-4.9.y and will be in the next firmware release.
added a commit
Jun 22, 2017
added a commit
Jun 22, 2017
It is with deep gratitude that I report that after apt-get update, apt-get upgrade and rpi-update, that my serial communications are now working perfectly. My last test was with 89 bytes, and I have found no new artifacts resultant from the update. All my OpenCV, PocketSphinx and other installations are working fine, but now all my cluster nodes can talk to each other. Thank you, very much.