Page 1 of 1

ALSA UART conflict?

Posted: Mon Sep 10, 2018 8:12 am
by sgh
I have a Pi 3+ connected to an AT modem through /dev/ttyS0 on GPI HW/ PINS 8&10 (standard UART GPIO pins), and a sound device over I2S on GPIO HW/ PINS 12/35/37.

I can successfully talk to my AT modem via /dev/ttyS0, and record audio using ALSA, for example using arecord. However I cannot do both: arecord interferes with /dev/ttyS0 - garbage appears on the terminal window. I can cope with the garbage (if I must) however arecord also leaves /dev/ttyS0 not relaying any further incoming traffic.

I have tried various dtoverlays to get the UARTS assigned and re-assigned but no luck. I have traced the problem to the snd_pcm_hw_params(...) call that configures the ALSA port.

Any suggestions will be greatly appreciated!!


Re: ALSA UART conflict?

Posted: Mon Sep 10, 2018 8:40 am
by PhilE
There isn't an obvious point of overlap between I2S and UART1. I2S gets its clock from PLLD or the oscillator, while UART1 shares the VPU core clock which comes from PLLC.

Please post the content of your config.txt to help narrow things down, but in the meantime conceivable problems are:

1. The core clock is changing, throwing out the baud rate, but "enable_uart=1" in config.txt without "dtoverlay=pi3-disable-bt" or "dtoverlay=pi3-miniuart-bt" forces an implicit "core_freq=250", so this shouldn't be possible. You could add an explicit "core_freq=250" to eliminate this is a possible cause.

2. UART GPIO alt functions getting scrambled. Very unlikely, but post the output of "raspi-gpio get" to confirm.

3. Electrical interference between the I2S and UART data lines. Have you tried altering wiring placement, shielding some signals etc.?

Re: ALSA UART conflict?

Posted: Mon Sep 10, 2018 8:59 am
by sgh
config.txt and output from raspi-gpio below. I have replicated the same behaviour on different Pi 3+ and Pi Zero W, with different boards (and wiring), all giving very consistent results on all platforms (down to the same number of bytes of garbage received on ttyS0, so for me this rules out electrical interference.

Code: Select all

BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=0 func=INPUT
GPIO 3: level=1 fsel=0 func=INPUT
GPIO 4: level=1 fsel=1 func=OUTPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=1 fsel=2 alt=5 func=TXD1
GPIO 15: level=1 fsel=2 alt=5 func=RXD1
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=1 fsel=0 func=INPUT
GPIO 18: level=1 fsel=4 alt=0 func=PCM_CLK
GPIO 19: level=1 fsel=4 alt=0 func=PCM_FS
GPIO 20: level=0 fsel=4 alt=0 func=PCM_DIN
GPIO 21: level=0 fsel=4 alt=0 func=PCM_DOUT
GPIO 22: level=1 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=0 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=1 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=0 func=INPUT
GPIO 29: level=0 fsel=1 func=OUTPUT
GPIO 30: level=0 fsel=7 alt=3 func=CTS0
GPIO 31: level=1 fsel=7 alt=3 func=RTS0
GPIO 32: level=1 fsel=7 alt=3 func=TXD0
GPIO 33: level=1 fsel=7 alt=3 func=RXD0
GPIO 34: level=0 fsel=7 alt=3 func=SD1_CLK
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3
GPIO 40: level=0 fsel=4 alt=0 func=PWM0
GPIO 41: level=0 fsel=4 alt=0 func=PWM1
GPIO 42: level=1 fsel=4 alt=0 func=GPCLK1
GPIO 43: level=1 fsel=4 alt=0 func=GPCLK2
GPIO 44: level=1 fsel=0 func=INPUT
GPIO 45: level=1 fsel=0 func=INPUT
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

Code: Select all

# For more options and information see
# Some settings may impact device functionality. See link above for details

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

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

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

# uncomment to force a console size. By default it will be display's size minus
# overscan.

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

# uncomment to force a specific HDMI mode (this will force VGA)

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

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

# uncomment for composite PAL

#uncomment to overclock the arm. 700 MHz is the default.

# Uncomment some or all of these to enable the optional hardware interfaces

# Uncomment this to enable the lirc-rpi module

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

# Enable audio (loads snd_bcm2835)

Re: ALSA UART conflict?

Posted: Mon Sep 10, 2018 9:07 am
by PhilE
That all looks fine. Try with "core_freq=250", but it shouldn't make any difference.

What is the UART corruption like? Is it adding characters, losing characters, or modifying characters that are expected? Does any correct data get through?

Re: ALSA UART conflict?

Posted: Mon Sep 10, 2018 9:28 am
by sgh
It's adding a random byte sequence - looks like the raw audio stream. I have added the freq directive without success.
For what it's worth, the audio recording works fine, and I can deal with the garbage on the AT session. However the socket is left unresponsive, even closing and re-opening does not work. I can replicate the situation from the command line with three simple commands:

# first minicom session works fine
minicom -D /dev/ttyS0

# audio recording
arecord -D plughw:1 -c1 -r 48000 -f S32_LE -t wav -V mono -v -d 3 file.wav

# second minicom session does not connect
minicom -D /dev/ttyS0

Any ideas?

Re: ALSA UART conflict?

Posted: Mon Sep 10, 2018 2:25 pm
by PhilE
That looks like a software conflict. What does lsof say in the various states?:

Code: Select all

$ sudo apt-get install lsof
$ lsof /dev/ttyS0