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