[alsa-devel] i.MX6 SGTL5000 hangs with EIO error

[Caleb Crome]

On Thu, May 12, 2016 at 10:54 AM, Ross Wille <audio at cornerbrick.com> wrote:

> Hello all,
>
> I am doing an ALSA capture on a Wandboard Quad (i.MX6 quad core with
> SGTL5000 codec chip) from the LINEIN1 jack.  I'm using a 4.6.0-rc3-armv7-x0
> kernel.
>
> Sometimes when the audio glitches (for example, when I plug/unplug the
> audio
> cable or adjust my signal generator) the snd_pcm_readi() function will
> start returning -5 (EIO).
>

This sounds like an ESD strike. (when you plug in the cable the ESD on the
cable wacks some electronics internally).

See if you can ground yourself, the signal generator, the wand board, and
anything else with some ESD straps, and see if you can reproduce the error.


Looking at the wandboard baseboard, the linein1 jack *does* have ESD
protection diodes on it.

Interestingly, the mic1 jack does not have ESD diodes.  not sure why.

This shouldn't be a software issue, because there's no microphone detection
going on in hardware -- the software doesn't know you've inserted anything.


Another possibility is a different type of electrical over stress.  There
might be a large voltage between your wandboard GND and generator GND.
This is common, and is a result of the inter-widing capacitance on the
respective 'isolated' power supplies.  If that capacitance is large enough,
it might be able to drive enough current into the pins to wreck up the
SGTL5000 until re-power.   But... the wandboard's transient suppression
should be enough to deal with that.

Oh, looking at the schematic again, there are TVS, diodes D36/D37, but
there is *no* series resistance between the connector and the codec!  That
could easily be the problem -- an external signal can drive lots of (ac)
current in through those lines and cause latch-up.  That's why you require
a power off/on to reset it.   Even a hard reset won't fix latchup.

See if your codec starts to get warm when in this state :-/  Definitely
damaging to the codec though.

-Caleb





>
> Once this happens, the only way I've been able to recover is to reboot the
> computer.  Calling snd_pcm_close(), snd_pcm_prepare(), snd_pcm_start(),
> etc. doesn't help.  When in this state, running arecord returns IO errors
> as well.
>
> It's interesting that, on rare occasions, I must do a power cycle in order
> to recover.  When a reboot is not effective I've noticed that the capture
> device doesn't appear in /proc/asound/devices.
>
> I don't believe my specific ALSA settings are important, but I'm calling
> snd_pcm_readi() with ALSA set to a sample rate of 48000, format of S16_LE,
> channels=1, frames per period of 960 (20 mS periods), and 4 periods per
> buffer.
>
> This same problem happens on two different Wandboards, so I don't think
> it's
> a defective board or chip.  It has happened on older kernels as well.
>
> Any ideas?
>
> Thank you!
>
> Ross Wille
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>