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.