No Serial Output Via Pins 14/15

[lantzvillian]

Hello all,

I have spent a good while attempting to figure out why I cannot get any output to the serial console from GPIO pins 14/15 (BCM numbering). I am using Rasbian 2014-09-09 on a Raspberry B+, and have verified that the pins are operational via LEDs on a breakout board.

Code: Select all

stty  -F /dev/ttyAMA0 -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

I have also verified cmdline.txt and config - they look okay; EXCEPT console=ttyAMA0,115200 console

Code: Select all

root@atom:~# cat /boot/cmdline.txt 
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait

Code: Select all

root@atom:~# cat /boot/config.txt 
# For more options and information see 
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800


# NOOBS Auto-generated Settings:
hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0

I have tried screen@ 115200, minicom with numerous settings etc... no output just a blank screen. The PI is working other than that, but I NEED serial. I am also using this: https://www.modmypi.com/USB-to-TTL-Seri ... spberry-Pi

[DirkS]

Are you using GIO14 / 15 (physical pins 8 / 10) or physical pin numbers 14 / 15?

Gr.
Dirk.

[lantzvillian]

As said above - I am using the Broadcom (BCM) number so I guess that is physical pins 6(for ground)/8/10

[joan]

Could you confirm that you have RX, TX, and ground connected?

What is at the USB end of the link?

[lantzvillian]

Confirming that is a bit tricky (do you need a photo?) - I have the Black wire from the TTL/USB cable as ground, white for pin 14 and green for pin 15. I left off the power (red). I also tried flipping the green and white wires; RX/TX around, but no luck.

On the receiving end of the male USB, I have a Linux VM which recognizes the receiver as a Prolific chipset. Minicom in whatever speed (115200, or 38400) with 8N1, and no flow for either software or hardware set.

[joan]

Are you running minicom on both ends of the link?

At the Pi end you can try this.

stty -F /dev/ttyAMA0 38400 # or whatever rate used by the other ends minicom

echo "Hello World" >/dev/ttyAMA0

[lantzvillian]

No, I am running minicom on ONLY the end trying to communicate to the PI (the VM).

Nothing regardless of speed settings (115200, 38400) and wire placement. Potentially the adapter is a dud...

[joan]

So you are trying to log in to the Pi over the serial link?

If so make sure the line

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

in /etc/inittab is not commented out.

[lantzvillian]

Yes that is what I am trying to do, and yes it is not commented out. Unfortunately, what can I do to troubleshoot this because this is stupid.

I also just tried jigging up a FTDI usb DB9 connection which I know works and its receiving nothing. The pins can/do work as I can light up LEDs using them... I'm starting to wonder if this is a bug in the Rasbian configuration, the serial adapter and/or both.

[joan]

Unfortunately there is precious little to go wrong with serial links.

You could download a piscope pre-built image and pigpio which would let you check the serial gpios for activity.

[lantzvillian]

hmm.. maybe. The only other thing to note is I am powering the PI by mini-USB. Maybe there is some board erratta..

[joan]

hmm.. maybe. The only other thing to note is I am powering the PI by mini-USB. Maybe there is some board erratta..

microUSB?

I've used the serial link to log in using every model B hardware revision, microUSB, back-powered via USB, or powered via expansion header.

[lantzvillian]

ahh sorry, micro-USB; I am dumbfounded as I use serial almost daily on several appliances I develop on (albeit using the USB-to-serial)....

[joan]

ahh sorry, micro-USB; I am dumbfounded as I use serial almost daily on several appliances I develop on (albeit using the USB-to-serial)....

You need to get piscope and check for activity. If there is activity perhaps one of the dongle wires is broken.

[lantzvillian]

I just tried OpenWRT and I have the same issue it seems. Polyfuse?

[klricks]

Try a loopback test on the RPi.
Configure the port as a general purpose port.
Note you can now enable / disable the console port using the latest version of sudo raspi-config
Short TX & RX with a jumper wire.
Run mincom on the RPi and verify that typed characters are echoed back.
Make sure local echo is off when you do that. With local echo on you should get 2 characters ...aabbcc..

[mahjongg]

do you realize that the UART I/O uses 3V3 levels, like the other GPIO'S may not work with hardware expecting 5V levels, and the PI may be damaged by received 5V levels so you might need level converters.

[lantzvillian]

I haven't had a moment to hook my PI up, but I know there is an immense amount of beginners and that I am not one of them; I've written kernel modules, performed physical and software modifications to the PCM in my race car and develop embedded industrial security appliances.

I read the documentation and understand the limitations of the GPIO pins and their lack of circuit protection before hooking it up. I also chose the adapter from modmypi; I suspect they and Adafruit wouldn't see the same cheap Prolific one otherwise, but if thats the case - someone owes me a new PI.

PS. I took apart the adapter and soldered working wires onto the RX, TX and ground points. Wiring should not be an issue.

If the hardware for those pins was broken, I doubt I would be able to manually activate the GPIO pin and turn on/off an LED - correct? I just toyed with the python libraries, but I suspect that the registers and low level gadgetry they touch are unaffected.

Lets get some good troubleshooting into this conversation please.

[mahjongg]

well the prolific2303 seems to use 3V3 levels,

and the RX/TX pins are 3.3V level for interfacing with the most common 3.3V logic level chipsets.

so that isn't it.

still many other USB serial interface, use 5V levels, and many want a logic high of 3.5V, not this one though.

[lantzvillian]

Yes, you are correct it is the 2303 chipset.

[lantzvillian]

Hi guys,

So I opened two SSH terminals to the PI and logged in as root. I ran in the 1st terminal: stty -F /dev/ttyAMA0 -crtscts & in the second terminal: cat /dev/ttyAMA0.

I then looped pins 8 & 10, and echo'd "test" using: echo "test" > /dev/ttyAMA0. The second terminal that was monitoring the serial console's file descriptor echoed test quite quickly then a bunch of lines.

Now whats the next step gentle persons?

[joan]

You mention you have tested them by using a LED.

How?

If you used a standard library to set them as outputs the gpio mode would have changed from ALT0 to OUTPUT. The RX/TX gpios need to be in mode ALT0 to act as the UART destination (otherwise the UART drives nothing).

[lantzvillian]

Standard Python libraries - you mention this ALT0 which I assume means alternate output.

* Is more information available and where?
* Can this be done manually?


If so; IMHO there is something wrong with the default configuration or detection of serial output (it is the era of plug-and-work)

[joan]

Standard Python libraries - you mention this ALT0 which I assume means alternate output.

* Is more information available and where?
* Can this be done manually?


If so; IMHO there is something wrong with the default configuration or detection of serial output (it is the era of plug-and-work)

This is only relevant if you wrote a program to set the RX/TX lines high or low. They default to mode ALT0 and will still be ALT0 unless you changed them.

If you have changed them just reboot and they'll be switched back to ALT0.

Alternatively my pigs utility would let you set or check the mode.

pigs mode 14 0
pigs mode 15 0

will set them to mode ALT0

pigs modeg 14
pigs modeg 15

will show the current mode (confusingly mode ALT0 has value 4).

Code: Select all

tom /ram $ sudo pigpiod
tom /ram $ pigs modeg 14
4
tom /ram $ pigs modeg 15
4

[rpdom]

you mention this ALT0 which I assume means alternate output.

Each GPIO pin can have eight different modes. The basic two are Input (mode 0) and Output (mode 1). The rest are called ALT0 to ALT5 and their capabilities depend on the pin (Not all ALTn levels are usable on all pins).

These are listed in the BCM2835 ARM Peripherals document on pages 102-103
http://www.raspberrypi.org/documentatio ... herals.pdf