1

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.

Community
  • 1
BCS
  • 119
  • 4
  • 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 04:32
  • The TX/RX pins on the Pi output serial data at 3v TTL (like all the other GPIOs) so if you may need to check your USB/serial converters are not expecting 5v TTL levels. – Roger Jones Dec 07 '18 at 12:20

0 Answers0