mini-UART problem and discussion notes

Viewed 15 times

This is actually not a question but a post about an issue I was seeing and figured out root cause and want to share it with the community.

I have a sensor which every 1 second spits out a 32-character serial stream at 9600 baud. I hooked it up to the mini-UART pins on the GPIO connector. What I saw was bad data.

After staring at the received data (and looking at the actual data on an oscilloscope) for a while it became clear that it was “losing synchronization” with the data. i.e. even though it was supposed to start capturing data at the falling edge after a stop bit, it was obviously capturing bits at other times, leading to garbled characters.

Now here was the confusing part: I also had a different sensor from another company that was working PERFECTLY on the original mini-UART. So why would one sensor work fine and the other not, with the same RPi configuration?

As another experiment, I used the various switches in config.txt (disable-bt for example) to use the AMA0 UART instead of the S0 UART, and everything worked fine!!! So the problem is obviously with the S0 UART and not the AMA0 UART.

The documentation does hint that there are various problems/shortcomings with the mini-UART but it still did not explain why it was screwing up. I finally found the reference that helped to explain the behavior.

The key was finally reading section 2.2 of the BCM2835 ARM Peripherals documents, link found on the RPi site. This section describes the mini-UART operation in a bit more detail.

The thing I have not told you yet is this: The sensor with the bad readings also used the parity bit. It was set to provide even parity, so the parity bit could be high or low depending in the data in the previous 8 bit slots.

The document noted above says:

“After receiving a start bit and 8 (or 7) data bits the receiver waits for one half bit time and then starts scanning for the next start bit. The mini UART does not check if the stop bit is high or wait for the stop bit to appear. As a result of this a UART1_RX input line which is continuously low (a break condition or an error in connection or GPIO setup) causes the receiver to continuously receive 0x00 symbols.”

So what was happening was that the UART would receive the 8 data bits, and if the parity was already even in the data, the parity bit (which is bit 9 in the serial stream) would be low. Instead of using it as a parity bit, the UART would see that as a low and interpret that as a start condition and start receiving another character. Of course the next bit or two would be high as these are the stop bits, and after that you get a low for the next start, etc, so the data received was nonsense.

So in summary, the mini-UART on RPi 3 and earlier simply WILL NOT WORK IF YOU HAVE DATA THAT USES PARITY CHECKING!!! In this case the sensor I have cannot be told to not use parity, so the only way I can use it with the RPi3 or earlier is to swap the UART’s as noted above.

I have tried the same experiment with the RPi 4. Best as I can tell this problem has been fixed. I seem to be able to use either UART on the 4 and it works as expected.

I will conclude by just noting that this was a ridiculously stupid design decision on the chip designers part.

 New contributor
  • 1
    This is just a rant because you didn’t do any research. – Milliways 4 hours ago
  • 1
    Wow was that comment actually necessary? – Larry Klein 2 hours ago
  • Hi @Larry Klein, Welcome and nice to meet you. Ah, let me see. I have been reading forum discussions on UART for a couple of years and have never seen such an excellent research report with detailed analysis and a recommendation. I fully agree that miniUART is not very good, and as you said, if you are using parity checking, causing out sync problem. Many newbies like me always use 8N1, ie, no parity, so never have your problem. I always try to avoid the Rpi on board UART, whether miniUART or otherwise, by using USB to UART adapter/cables. / to continue, … – tlfong01 53 mins ago   
  • The linux USB/UART drivers such as CH340, PL1202 etc are very stable. Of course the lesson learnt is to NOT to ask the simple minded miniUART to do parity check. Thank you very much for sharing your research experinece with us newbies. BTW, your “question” actually includes an answer. I would split your “question” into two parts: (1) Question part: How come miniUART has a out of sync problem with devices using parity check, (2) Answer part: Your in depth research finding the root cause, and a recommendation of newbies. I appreciate your research report very much. Have a nice day. – tlfong01 53 mins ago    

Categories: Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: