Hi, Yesterday, Roh and I replaced the video chip on my board with the broken video input and replaced the LM4550 codec on a RC1 board with a WM9707 chip. After hours of struggles with (de)soldering problems, copper planes spreading and dissipating the heat from the air gun (solution: use a larger nozzle to heat more pins at once) and the tendency of lead-free solder to make shorts between the chip body and the pins (lesson learned: use lead for hand soldering of *QFP packages), we managed to properly replace the two chips.
VIDEO INPUT Replacement of the ADV7181 chip on my board restored the video input functionality. This supports the theory that the chip was damaged because of a voltage surge coming from my camera when it died. Let's just add the Littelfuse transient voltage suppression devices on the video input connectors of the RC3. AUDIO After replacement of the codec, when playing the test tone with the test program, the audio output was remarkably noise-free. However, when running Flickernoise, the demo firmware, or the recording tests of the test program, one or more of the following symptoms appear (they are very marked with Flickernoise): 1. "white" noise comparable to that of the LM4550 codec 2. very loud noises, beeps and screeches, sometimes periodic, happening especially with Flickernoise and the demo firmware. They depend on the activity of the software, e.g. moving windows, typing text, activating certain functions affect the produced noises very significantly. 3. recorded audio data is garbage My guess is that there is some subtle and probably timing-related FPGA design bug that causes the AC97 link to become randomly corrupted depending on other SoC activity. This would give a simple explanation to the audio problems we have seen so far: 1. "white" noise on the ML401: same bug, same noise 2. loud noises with WM9707: the two different codecs react differently to the AC97 corruption (maybe because of slightly different timing specs) 3. audio input apparently not working in Flickernoise on Norman's board. With the help of Murphy's law, process variations could have hit the sweet spot that made the audio input pass the factory test and fail in Flickernoise, because of different SoC activity with the test program and Flickernoise. Other (improbable) suspects could be: 1. crosstalk, i.e. strong SDRAM signals aggressing the AC97 link. The PCB layout has a good separation between the two, and increasing the AC97 drive to 24mA on the FPGA does not change anything to the problems. So this is unlikely. 2. strong power supply noise - we did not measure any 3. strong EM emissions - we did not measure any I'd say go ahead with the RC3 board run without any change to the audio. S. _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode Twitter: www.twitter.com/milkymistvj Ideas? http://milkymist.uservoice.com
