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

Caleb Crome caleb at crome.org
Fri May 13 21:23:11 CEST 2016


On Fri, May 13, 2016 at 9:56 AM, Ross Wille <audio at cornerbrick.com> wrote:

> Hi Caleb,
>
> Thank you for your response!
>
> The LINEIN1 protection on the Wandboard kicks in at around 5 to 5.5 Volts
> and, as you pointed out, doesn't include a current-limiting resistor.  The
> max-voltage range for the SGTL5000 audio input is spec'd at GND-0.3 to
> Vdda+0.3.  I believe the Wandboard Vdda is 2.5V, so the on-board protection
> is likely insufficient to limit the input voltage to the datasheet specs.
>
> To mitigate this I have done the following:
>
> 1. I've isolated the audio between the signal generator and the codec chip
> using a professional-grade audio transformer having a breakdown voltage of
> 250 V RMS, so ground loops should not be an issue, but it might not
> eliminate ESD completely.
>

Ah, a Jensen Transformer I assume?  Those things are great.  And the guy
(Bill Whitlock) really knows about dealing with hum issues.  His license
plate reads MR CMRR.  The DMV initially wouldn't give him that plate.
Until he explained that CMRR stands for 'common-mode rejection ratio' :-)
The stuff you learn at AES conventions...


>
> 2. For transient protection, I have a bidirectional TVS diode with a
> breakdown voltage of 1.0V(typ) between the transformer output and ground.
> The TVS diode meets IEC 61000-4-2 for contact discharge of 8 kV and air
> discharge of 15 kV and I don't believe its an ESD problem (see #3).  The
> circuit impedance at the TVS diode is about 10 kohms.
>



>
> 3. I'm working on a static mat and I'm grounded.
>
> In spite of doing all this, I still get the error.  If latch-up is the
> culprit (which is possible) I am running out of things to try.  I may need
> to add an active buffer stage to ensure the audio voltage never exceeds the
> voltage rails (but that'll require a new PCB design--sigh).
>

Is this your custom board + wandboard, or is it the standard wandboard?

Is it possible that the GND of the audio connector (which is what should
get hit first if you're plugging into the jack at the board side) isn't a
very good ground, and is letting ESD couple to some other lines?  ESD is
icky that way.    But, if you're ESD grounded, then this shouldn't be the
issue anyway.


>
> I was hoping to find a software recovery solution because rebooting and
> power-cycling the board are a rather drastic measures.
>

I doubt that's possible if a reset doesn't recover it -- it seems to be
really broken if you need a power cycle.  That's also a hint that it's
latchup causing the problem.



> Thanks!
>
> -Ross
>
>
Looks like you've got most of it covered :-)

Can you do some protection like this?
https://drive.google.com/file/d/0B0FeiEiLS9DzMVpTWm9QcDY5UHM/view?usp=sharing

using something like a BAT54S?  That should do a very good job of limiting
the voltage to the codec.  but, a 1V TVS should do the job too I think if
it's placed on the wandboard.  Where is your TVS diode placed?  Soldered in
close on the connector of the wandboard, or floating out in space.  But...
ESD just shouldn't be the problem if you're properly grounded.

What else could be the culprit I wonder?  This happens as soon as you plug
in, right?  Does the problem ever happen when nobody is near by and
breathing on it?  Or is always in response to some body coming close and
touching things?

I'm kind of out of ideas without actually getting in close to it and seeing
what happens and when.

Let me know if you can figure out any more details of when the problem
happens.  I just think it's got to be a hardware problem, but I've seen
stranger things end up being software problems.  :-)

Cheers,
  -Caleb



> On Thursday 12 May 2016 14:13, Caleb Crome wrote:
> > 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
> > >
> >
>


More information about the Alsa-devel mailing list