Raspberry Pi 3 UART doesn't pull TXD high

[jwatte]

I'm using a Raspberry Pi 3 with latest Raspbian.
I have disabled console on the UART, but enabled UART swapping and turbo mode in config.txt.
I am hooking a scope to pins 8 and 10. It seems like pin 8 doesn't ever go high (idle.)

The serial devices exist, and are linked appropriately:

Code: Select all

[11:11] [email protected]:~ $ ls -l /dev/serial[01]
lrwxrwxrwx 1 root root 7 Dec 31  1969 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Dec 31  1969 /dev/serial1 -> ttyS0
[11:11] [email protected]:~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi
[11:11] [email protected]:~ $ ls -l /dev/ttyAMA0 /dev/ttyS0
crw-rw---- 1 root dialout 204, 64 Dec 29 11:10 /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Dec 29 11:10 /dev/ttyS0

Trying the "serial debug" program from another thread, that uses PySerial to send and echo through a loop-back cable, does not actually loop the data back, and I can see no wiggles on the scope.

Sending data from an external MCU to pin 10 (at 3.3V level -- it's a Teensy 3.2) shows on the scope, but I cannot read the data from the serial0 device. (I've also tried serial1, ttyS0, and ttyS1.)
In fact, as user in group "dialout," I get the error "device or resource busy" when trying to read them. I have to use "sudo" to even open the drivers.

When sending data from the MCU as a USB device, it works with the same test programs, so it's not a problem with the test software.
(I mainly use "dd if=x bs=1" but also minicom and the serial loopback test program from the other thread.)

I've heard that some boards are bad, and that could be the case here -- but given that "dd if=/dev/ttyAMA0 bs=1" returns "resource busy," I'm wondering whether something else is the matter?

Here is my cmdline.txt:

Code: Select all

dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=73230579-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Here is my config.txt:

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# 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

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
start_x=1
#gpu_mem=256
#hdmi_ignore_edid=0xa5000080
#hdmi_pixel_encoding=2

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

# Waveshare recommendations to make the 7" display go
max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0


# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=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=2

# uncomment for composite PAL
#sdtv_mode=2

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

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
dtoverlay=i2c-rtc,pcf8563
#dtoverlay=i2c-rtc,ds3231

# Additional overlays and parameters are documented /boot/overlays/README

#enable_dpi_lcd=1
#display_default_lcd=1
#dpi_group=2
#dpi_mode=87
#dpi_output_format=454661
#hdmi_timings=800 0 40 48 88 480 0 13 3 32 0 0 0 60 0 32000000 6

# Use the slower UART for Bluetooth
dtoverlay=pi3-miniuart-bt
enable_uart=1
force_turbo=1
dtoverlay=vc4-kms-v3d

What can I try to verify whether the problem is that some software/module is keeping me from using the serial port, or whether this is a bad board?
If something else was using the port, wouldn't pin 8 go high / idle?
And if the problem was pin 8 shorted to ground, wouldn't input data on pin 10 at least be returned through the device?

[joan]

I would check your GPIO to see if they operate properly.

wiringPi has a pintest utility and (my) pigpio has a gpiotest utility.

Both tests should be run with nothing connected to the expansion header (the 40 pin header).

[mahjongg]

I've heard that some boards are bad, and that could be the case here -- but given that "dd if=/dev/ttyAMA0 bs=1" returns "resource busy," I'm wondering whether something else is the matter?

Boards bad? I don't think so, the only part of the board that could go "bad" for the serial port is a few copper-traces between the main chip (system on a chip) and the GPIO pins, copper traces of a PCB don't just break., that is not possible.

In fact the whole serial device is embedded in the SoC, there are no parts that could go "bad", and I do not believe a tiny part of a chip just stops working, that is just not possible.

[jwatte]

Thanks for the answer:

Code: Select all

[13:54] [email protected]:~ $ sudo apt-get install pigpio
Reading package lists... Done
Building dependency tree       
Reading state information... Done
pigpio is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Code: Select all

[13:55] [email protected]:~ $ sudo pigpiod 
[13:55] [email protected]:~ $ ./gpiotest 
This program checks the Pi's (user) gpios.

The program reads and writes all the gpios.  Make sure NOTHING
is connected to the gpios during this test.

The program uses the pigpio daemon which must be running.

To start the daemon use the command sudo pigpiod.

Press the ENTER key to continue or ctrl-C to abort...

Testing...
Skipped non-user gpios: 0 1 28 29 30 31 
Tested user gpios: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 
Failed user gpios: None
[13:55] [email protected]:~ $ 

So the GPIOs seem alright.

[jwatte]

Boards bad?

According to other threads related to bad UARTs on this forum, some Pis had some kind of accidental junction (solder junction?) between the pin and GND. That would certainly cause the TXD to not go high!

However, I see the same behavior from a brand new Pi 3 I just got from Element14, so I don't think that's the problem here.

I do not believe a tiny part of a chip just stops working

Anyone who's had a particular pin on an Arduino go bad because it was shorted to ground while driven high, will know that that can totally happen.
Each output pin is driving by some kind of output driver stage, which is made of transistors; those transistors can totally burn out (from overcurrent) or short out (from avalanche failure, i e over-volting) without necessarily affecting other parts of the chip. So, it's totally possible for "just a part" of an IC to die, in addition to single pins or junctions being accidentally solder bridged in fabrication.
That being said, given that I, as a regular user, cannot open the device, even though I'm in the right group, and given that I can't read data that's written to the device, either, I think something else must be the matter.
I'm looking for what that particular "something else" may be.

[joan]

gpiotest does not report an error.

This means the following tests passed on TXD.

• it reads back as 0 when set as a low output
• it reads back as 1 when set as a high output
• it reads back as 0 when set as an input with the internal 50k pull-down set
• it reads back as 1 when set as an input with the internal 50k pull-up set

There is a chance that your wiring is introducing a fault and also a chance (unlikely) that you are using the wrong pins.

A photo of your wiring may help.

[mahjongg]

a PI doesn't behave the same as an arduino, on a PI shorting a pin doesn't normally destroy it (but I'm not responsible if it does, so don't go trying it, and blaming me when it does) ,instead the GPIO driver is much more complex. (see the datasheet of the SoC, section of the GPIO drivers) but if you put 5V on a PI you damage more than just the GPIO driver., as that will cause a latch-up effect which destroys a physical area on the chip around the GPIO driver.
But in general, yes, you can damage part of a chip, but what I meant was instead that in general chips are literally monolithic, and normally one part of them does not fail spontaneously while the rest works.
normally on a PI when you destroy a GPIO port you destroy the whole PI.

[jwatte]

Okay, so what software configuration is wrong, in that the TXD (pin 8 on the header) of the Pi doesn't go high, even though I have enabled the UART?

I have simplified the config.txt slightly, to the following:

Code: Select all

disable_overscan=1

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
start_x=1
gpu_mem=256

# Waveshare recommendations to make the 7" display go
max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0

config_hdmi_boost=2

dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

#dtoverlay=i2c-rtc,pcf8563
#dtoverlay=i2c-rtc,ds3231

# Uncomment to se the slower UART for Bluetooth
# dtoverlay=pi3-miniuart-bt
enable_uart=1
force_turbo=1

# KMS -- camera doesn't work, EGL doesn't work, desktop GL works
#dtoverlay=vc4-kms-v3d
# fake KMS -- camera works, desktop GL works, EGL doesn't
#dtoverlay=vc4-fkms-v3d

Also, the cmdline.txt is still the same:

Code: Select all

dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=73230579-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Here is the wiring (TXD is gray wire, red line on the scope)
https://photos.app.goo.gl/p2SiTypdgOewcOyT2

Here is the scope.
https://photos.app.goo.gl/woorNBXtPj6I5I7c2

I've seen this on two separate Pi 3 boards (with the same CF install.) Measuring TXD to ground with a continuity tester does not find a short.

Interestingly, when I go into "Raspberry Pi Settings" (the control panel in the GUI,) I2C and UART show as disabled?
Turning on the serial port, will also turn it on in the console; at that point, it crashes on boot with a double fault.
Removing console=serial0,115200 from the cmdline again makes it boot again.
Maybe I should just try a new NOOBS...

[jwatte]

Latest Raspbian (from 2017-11-29) re-imaged boots, and pulls both TXD and RXD high.
The previous image was older, and had been apt-get updated and dist-upgraded regularly, so apparently that's not good enough?