2016-09-23-raspbian-jessie and have done all the updates steps everyone suggests (
apt-get update ; apt-get upgrade). After that (and
enable_uart=1) didn't work I added
dtoverlay=pi3-disable-bt to my
/boot/config.txt and made sure
console=tty1 console=serial0,115200 is in my
/boot/cmdline.txt. I've used two different USB/serial converters, several different baud rates and built a loop-back plug. As far as I can tell all that is as it should be but I'm still getting garbage during the boot. (At least the garage has the right cadence for a boot console so I have reason to think I'm close.)
In desperation I dug up
setserial and, despite the boot command line asking for 115200, it shows Baud_base=3000000:
# setserial -gav /dev/ttyAMA0 /dev/ttyAMA0, Line 0, UART: undefined, Port: 0x0000, IRQ: 87 Baud_base: 3000000, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal
But even that seems to be a dead end as manually forcing that to 115200 (which seems to stick) doesn't get usable output in my terminal.
I'm about out of things to try. Any suggestions?
I tried turning off the serial consol, looping back the port on the Pi and testing it via screen. That indicates that it works (at least to some degree).
I hooked up my DMM in frequency mode and sent long streams of
~~~~~~~~ back and forth (
0b01111110 the longest run of 1's in ASCII) and got the same frequency in both directions which makes me think the baud rate is matching. To check things I then tried
33333 (which happens to be
0b00110011) and as expected, I get the same higher frequency in both directions.
What's instersting is that when I send out
0b01111110 the other end sees strings of
0b00000011 and when I send out
0b00110011 I get
0b10011001. In both caes
result = ~(input << 1). To test that theory, I tried
X and as predicted got
O. If I feed those sorts of buffers in the other direction, I get visable repating patterns, but nothing so clean.
While that's all intersting, I'm still at a loss as to what alls causing the problem.