2

I'm using 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?

Edit #1

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 (~ is 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 0x33 or 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.

  • 1
    It is clearly not possible to "have done all the updates steps everyone suggests", and even if you have tried your system would be a mess. What you haven't described is WHAT YOU ARE TRYING TO ACHIEVE. If all you want to do is get serial console out on the default serial port the standard image should work. – Milliways Oct 11 '16 at 11:24
  • @Milliways, I'll grant "all the updates steps everyone suggests" is a touch vague. Specifically, I did the "make sure stuff is running recent versions" updates. -- Yes, I just want to "get serial console out on the default serial port", (I thought that was clear from the subject line). While it may be true it "should" work from the standard image, it's not, and I'm trying to figure out why. – BCS Oct 11 '16 at 14:15
  • 1
    Have you tried using the UART with the login console disabled and, e.g., minicom on the pi side? And/or: "built a loop-back plug" -> I think with the console output disabled a jumper from rx to tx should fill that role. The software side of this is very unlikely to be the problem since otherwise it would affect large numbers of people, so testing with minicom and a loopback would help point the finger more clearly at a hardware defect. Just make very sure the login console is not running. – goldilocks Oct 11 '16 at 14:34
  • I haven't tried either of those. (Though the a loopback test only check that the Rx/Tx pins work and are in the same mode, not that they are in the correct mode. Still, that's something I don't known now.) – BCS Oct 11 '16 at 18:12
  • @goldilocks, I tried that. It's a bit more production than before because it's easy to play with, but the results are just as bazaar and uninformative to me. (See edit #1 above.) – BCS Oct 12 '16 at 4:32
0

"Any suggestions?" Yes.

Restore an unmodified image.

Don't fiddle with it - don't dtoverlay=pi3-disable-bt.

Use /dev/serial0 NOT /dev/ttyAMA0.

Add enable_uart=1or enable serial in raspi-config

This works for the rest of us.

See How-do-i-make-serial-work-on-the-raspberry-pi3 for background.

  • The first thing I tried was enable_uart=1. I guess I can try it again, but I fully expect to get the same result. --- Besides why is that UART preferred over the AMA one (given I have no use for it and so would rather not have the BT turned on anyway). – BCS Oct 12 '16 at 13:35
  • @BCS As in the linked answer "The mini UART is a secondary low throughput UART intended to be used as a console", it is NOT "preferred". It is perfectly adequate as a console. There has been copious discussion on this subject. You can use your Pi as you wish, my answer was to use a plain vanilla setup - which works for most of us. I posted the linked answer after I got a Pi3 and some research into serial problems. The Foundation has since tidied up the code e.g. by introducing /dev/serial0. – Milliways Oct 12 '16 at 23:15
  • Citing from your answer (which BTW, might even have been what got me looking at using i3-disable-bt in the first place): "Unfortunately[...] the mini Uart has [a] Baudrate derived from system clock" which kind of sucks. -- And from reading the archives, it looks like (until BT support was added) it was the preferred UART (as in the one that was actually used by default) for the console. – BCS Oct 13 '16 at 0:54
  • I reverted to just using enable_uart=1. No joy. – BCS Oct 13 '16 at 14:38
  • Did you ever get this working? – NomadMaker Jul 27 '18 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.