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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
