i.MX6 SGTL5000 hangs with EIO error

i.MX6 SGTL5000 hangs with EIO error

[Ross Wille]

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).

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

Re: i.MX6 SGTL5000 hangs with EIO error

[Caleb Crome]

On Thu, May 12, 2016 at 10:54 AM, Ross Wille <audio@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@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: i.MX6 SGTL5000 hangs with EIO error

[Ross Wille]

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.

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).

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

Thanks!

-Ross

On Thursday 12 May 2016 14:13, Caleb Crome wrote:
> On Thu, May 12, 2016 at 10:54 AM, Ross Wille <audio@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@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> 

Re: i.MX6 SGTL5000 hangs with EIO error

[Caleb Crome]

On Fri, May 13, 2016 at 9:56 AM, Ross Wille <audio@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@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@alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > >
> >
>

Re: i.MX6 SGTL5000 hangs with EIO error

[Ross Wille]

Caleb,

Yes, it's a Jensen JT-11P-1HPC (10k 1:1) line transformer.

I have a custom isolation PC board, which includes the XLR jack, isolation 
transformer, variable attenuator, and transient protection.  The board has 
separate "shield" and analog grounds.  The output of this board feeds into 
a standard, unmodified Wandboard via the 3.5mm LINEIN1 jack.

I'm not plugging/unplugging the Wandboard connector (well, I started out 
that way, but the results were terrible).  With the transformer and the TVS 
diode the problem is MUCH better than it was initially.  When I was driving 
the LINEIN1 jack directly from the signal generator plugging/unplugging the 
audio connector had a significant chance of making this happen.

Now, the isolation board is always connected to the Wandboard.  And 
plugging/unplugging the XLR connector is pretty reliable.  The easiest way 
I've found to make the problem happen is by keeping everything connected 
and toggling the power switch on my signal generator repeatedly.

I don't think I'm getting any ESD during my tests, although when this device 
gets put into service I'd expect to get some ESD when they plug into the 
XLR jack while the device is powered.  (Maybe I'll tell them not to do 
that, but they're talking heads, not geeks.)

Most of the time a reboot fixes the problem, but I've seen rare occasions 
when it does require a power cycle.

The SGTL5000 doesn't have an external reset.  It has an internal reset 
circuit which waits 8 clock cycles after power-on before it comes out of 
reset.  So, a hardware reset of this chip requires a power cycle.

There may be a way to force a software reset if I can still talk to the 
chip, but if the chip is latched up only a power cycle is going to fix 
that.

The LINEIN1 is capacitively coupled to the SGTL5000 (I assume that's because 
the SGTL5000 input has a DC bias on it).  I'm clamping +/-1V relative to 
the Wandboard's signal ground, but that's on the AC-coupled side of the 
signal.  It'd be better to clamp it going into the codec as you've shown in 
your sketch.

You asked where the TVS diode is located.  It's a ESDARF01-1BM2 on the 
custom isolation PCB and it's connected between signal and ground just 
before it goes out the cable (which is only 6 inches long) and into the 
Wandboard's LINEIN1 connector.  It would definitely be better if the 
protection was on the Wandboard itself, especially after the coupling 
capacitor.

No, breathing on it doesn't affect it. :-)  I can run all night with a 
nearly full-swing sine wave at 1kHz and it never fails.  It used to fail 
regularly when I messed with the audio connections, but now it's much 
harder to reproduce it.

Thanks again for all your thoughts and ideas.  It's close to being good 
enough, but it's not very professional for a piece of gear to stop working 
just because someone plugged in an XLR cable.

-Ross

On Friday 13 May 2016 13:23, Caleb Crome wrote:
> On Fri, May 13, 2016 at 9:56 AM, Ross Wille <audio@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@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@alsa-project.org
> > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > >
> > >
> >
> 

Re: i.MX6 SGTL5000 hangs with EIO error

[Caleb Crome]

On Fri, May 13, 2016 at 1:45 PM, Ross Wille <audio@cornerbrick.com> wrote:

> Caleb,
>
> Yes, it's a Jensen JT-11P-1HPC (10k 1:1) line transformer.
>
> I have a custom isolation PC board, which includes the XLR jack, isolation
> transformer, variable attenuator, and transient protection.  The board has
> separate "shield" and analog grounds.  The output of this board feeds into
> a standard, unmodified Wandboard via the 3.5mm LINEIN1 jack.
>
> I'm not plugging/unplugging the Wandboard connector (well, I started out
> that way, but the results were terrible).  With the transformer and the TVS
> diode the problem is MUCH better than it was initially.  When I was driving
> the LINEIN1 jack directly from the signal generator plugging/unplugging the
> audio connector had a significant chance of making this happen.
>
> Now, the isolation board is always connected to the Wandboard.  And
> plugging/unplugging the XLR connector is pretty reliable.  The easiest way
> I've found to make the problem happen is by keeping everything connected
> and toggling the power switch on my signal generator repeatedly.
>


Ah Ha!   Hint hint!  Yes, not ESD, but electrical overstress -- too much
current I think.  There is still some nonzero inter-winding capacitance
even in the Jensen transformer, and flipping that power switch gives a nice
big 340 V p-p (120Vrms) shove across those inter-widning capacitances &
impedances, (plus who knows what kind of currenets due to inductive
switching) and even with the protection you have, there isn't enough
protection to prevent latchup.


> I don't think I'm getting any ESD during my tests, although when this
> device
> gets put into service I'd expect to get some ESD when they plug into the
> XLR jack while the device is powered.  (Maybe I'll tell them not to do
> that, but they're talking heads, not geeks.)
>
> Most of the time a reboot fixes the problem, but I've seen rare occasions
> when it does require a power cycle.
>
> The SGTL5000 doesn't have an external reset.  It has an internal reset
> circuit which waits 8 clock cycles after power-on before it comes out of
> reset.  So, a hardware reset of this chip requires a power cycle.
>

Ah, bad on the designers of STL5000.


>
> There may be a way to force a software reset if I can still talk to the
> chip, but if the chip is latched up only a power cycle is going to fix
> that.
>

Who knows, maybe not latchup then.  May simply be a glitch that causes it
to stop functioning.  I hadn't looked and noticed there was no hardware
reset.  A friend of mine once had a similar problem and was able to force
the chip to come back to life by toggling the I2C SDA and SCL lines a bunch
of times (upon advice from the chip maker).  You might have  a hard time
getting Linux to give you back the pins and toggle them like GPIOs, rather
than treat them as an I2C bus.




>
> The LINEIN1 is capacitively coupled to the SGTL5000 (I assume that's
> because
> the SGTL5000 input has a DC bias on it).


Correct.


>   I'm clamping +/-1V relative to
> the Wandboard's signal ground, but that's on the AC-coupled side of the
> signal.


Right, which should get the job done.  The bias is probably something like
1.3V or something, so your clamp should do a decent job of preventing much
negative voltage getting through.


> It'd be better to clamp it going into the codec as you've shown in
> your sketch.
>

Right, but you need access to VDDA.


>
> You asked where the TVS diode is located.  It's a ESDARF01-1BM2 on the
> custom isolation PCB and it's connected between signal and ground just
> before it goes out the cable (which is only 6 inches long) and into the
> Wandboard's LINEIN1 connector.  It would definitely be better if the
> protection was on the Wandboard itself, especially after the coupling
> capacitor.
>
> No, breathing on it doesn't affect it. :-)  I can run all night with a
> nearly full-swing sine wave at 1kHz and it never fails.  It used to fail
> regularly when I messed with the audio connections, but now it's much
> harder to reproduce it.
>

so, it's definitely due to the transient of connecting the signal generator.

Can I ask why you're using a signal generator?  I've found that a good
pro-audio sound card (like RME, or any of the other pro-audio stuff) do a
much better job of creating and capturing audio signals than most lab gear
(except the audio-specific lab gear like Audio Precision, etc).

For that matter, you can probably do just great using your iPhone with
AudioTools as your signal generator.  Then you definitely won't have this
problem. :-)


>
> Thanks again for all your thoughts and ideas.  It's close to being good
> enough, but it's not very professional for a piece of gear to stop working
> just because someone plugged in an XLR cable.
>

No problem!  I'm glad I could help.

-Caleb






>
> -Ross
>
> On Friday 13 May 2016 13:23, Caleb Crome wrote:
> > On Fri, May 13, 2016 at 9:56 AM, Ross Wille <audio@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@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@alsa-project.org
> > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > > >
> > > >
> > >
> >
>

Re: i.MX6 SGTL5000 hangs with EIO error

[Caleb Crome]

On Fri, May 13, 2016 at 3:01 PM, Caleb Crome <caleb@crome.org> wrote:

>
>
> On Fri, May 13, 2016 at 1:45 PM, Ross Wille <audio@cornerbrick.com> wrote:
>
>> Caleb,
>>
>> Yes, it's a Jensen JT-11P-1HPC (10k 1:1) line transformer.
>>
>> I have a custom isolation PC board, which includes the XLR jack, isolation
>> transformer, variable attenuator, and transient protection.  The board has
>> separate "shield" and analog grounds.  The output of this board feeds into
>> a standard, unmodified Wandboard via the 3.5mm LINEIN1 jack.
>>
>> I'm not plugging/unplugging the Wandboard connector (well, I started out
>> that way, but the results were terrible).  With the transformer and the
>> TVS
>> diode the problem is MUCH better than it was initially.  When I was
>> driving
>> the LINEIN1 jack directly from the signal generator plugging/unplugging
>> the
>> audio connector had a significant chance of making this happen.
>>
>> Now, the isolation board is always connected to the Wandboard.  And
>> plugging/unplugging the XLR connector is pretty reliable.  The easiest way
>> I've found to make the problem happen is by keeping everything connected
>> and toggling the power switch on my signal generator repeatedly.
>>
>
>
> Ah Ha!   Hint hint!  Yes, not ESD, but electrical overstress -- too much
> current I think.  There is still some nonzero inter-winding capacitance
> even in the Jensen transformer, and flipping that power switch gives a nice
> big 340 V p-p (120Vrms) shove across those inter-widning capacitances &
> impedances, (plus who knows what kind of currenets due to inductive
> switching) and even with the protection you have, there isn't enough
> protection to prevent latchup.
>
>
>> I don't think I'm getting any ESD during my tests, although when this
>> device
>> gets put into service I'd expect to get some ESD when they plug into the
>> XLR jack while the device is powered.  (Maybe I'll tell them not to do
>> that, but they're talking heads, not geeks.)
>>
>> Most of the time a reboot fixes the problem, but I've seen rare occasions
>> when it does require a power cycle.
>>
>> The SGTL5000 doesn't have an external reset.  It has an internal reset
>> circuit which waits 8 clock cycles after power-on before it comes out of
>> reset.  So, a hardware reset of this chip requires a power cycle.
>>
>
> Ah, bad on the designers of STL5000.
>
>
>>
>> There may be a way to force a software reset if I can still talk to the
>> chip, but if the chip is latched up only a power cycle is going to fix
>> that.
>>
>
> Who knows, maybe not latchup then.  May simply be a glitch that causes it
> to stop functioning.  I hadn't looked and noticed there was no hardware
> reset.  A friend of mine once had a similar problem and was able to force
> the chip to come back to life by toggling the I2C SDA and SCL lines a bunch
> of times (upon advice from the chip maker).  You might have  a hard time
> getting Linux to give you back the pins and toggle them like GPIOs, rather
> than treat them as an I2C bus.
>
>
>
>
>>
>> The LINEIN1 is capacitively coupled to the SGTL5000 (I assume that's
>> because
>> the SGTL5000 input has a DC bias on it).
>
>
> Correct.
>
>
>>   I'm clamping +/-1V relative to
>> the Wandboard's signal ground, but that's on the AC-coupled side of the
>> signal.
>
>
> Right, which should get the job done.  The bias is probably something like
> 1.3V or something, so your clamp should do a decent job of preventing much
> negative voltage getting through.
>
>
>> It'd be better to clamp it going into the codec as you've shown in
>> your sketch.
>>
>
> Right, but you need access to VDDA.
>
>
>>
>> You asked where the TVS diode is located.  It's a ESDARF01-1BM2 on the
>> custom isolation PCB and it's connected between signal and ground just
>> before it goes out the cable (which is only 6 inches long) and into the
>> Wandboard's LINEIN1 connector.  It would definitely be better if the
>> protection was on the Wandboard itself, especially after the coupling
>> capacitor.
>>
>> No, breathing on it doesn't affect it. :-)  I can run all night with a
>> nearly full-swing sine wave at 1kHz and it never fails.  It used to fail
>> regularly when I messed with the audio connections, but now it's much
>> harder to reproduce it.
>>
>
> so, it's definitely due to the transient of connecting the signal
> generator.
>
> Can I ask why you're using a signal generator?  I've found that a good
> pro-audio sound card (like RME, or any of the other pro-audio stuff) do a
> much better job of creating and capturing audio signals than most lab gear
> (except the audio-specific lab gear like Audio Precision, etc).
>
> For that matter, you can probably do just great using your iPhone with
> AudioTools as your signal generator.  Then you definitely won't have this
> problem. :-)
>
>
>>
>> Thanks again for all your thoughts and ideas.  It's close to being good
>> enough, but it's not very professional for a piece of gear to stop working
>> just because someone plugged in an XLR cable.
>>
>
> No problem!  I'm glad I could help.
>
> -Caleb
>
>

By the way, I just found this circuit:

http://www.eevblog.com/forum/projects/input-protection-question/msg123612/?PHPSESSID=cbedb3ec4d28bcfa8395e300665f2ee8#msg123612

It  might not be great for audio, but gives good ideas how to make a bullet
proof input.  One that can be shorted to 240V and still survive just fine.




>
>
>
>
>>
>> -Ross
>>
>> On Friday 13 May 2016 13:23, Caleb Crome wrote:
>> > On Fri, May 13, 2016 at 9:56 AM, Ross Wille <audio@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@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@alsa-project.org
>> > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

i.MX6 SGTL5000 hangs with EIO error

[Ross Wille]

Hello,

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).

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!

Wille