Hi All,
Here's background before I delve into the question. 5 years ago, we successfully ported, created and customized a AIC33 driver that works well with the ALSA API on our custom target platform, which is a OMAP-3430, running Montavista Linux 2.6.29.6. We're able to customize the driver to control the various AIC33 registers (volume, gain, etc). For the most part the AIC33 is working very well on our OMAP-3540 custom target; now here's the "but" part. Occasionally (maybe less than 1% of the times), when we power up the target, one of the following AIC33 problems occurs: 1) No-Input: in this instance, our application software reading (8KHz, 16-bit signed PCM data) from the audio device just returns sample data with all "0" (just dead silence); we have 2 input channels and neither of them provides samples with any "valid" non-zero data (even in a quiet ambient environment with no sounds, not all 16-bit samples should be 0). 2) No-Output: in this instance, our application software writing (8KHz, 16-bit signed PCM voice data) to the audio device produces no sound (just dead silence); we also have 2 output channels for audio output and neither of them plays any audible sounds, just "silence".
The above 2 problems NEVER happen at the same time; when #1 happens (just recording silence), we're still able to play audio on the output channels. And vice-versa, when #2 happens (playing audio produces no audible sounds), we're still able to record "good" audio on the input channels. And this ONLY happens on power up from cold start; if both are working, they remain working fine.
As a software developer, I have verified all the interfaces are working fine without any errors when either of the above problems occurs:
1) for problem #1, the application software maintains reading the correct # of bytes requested, with no error status
2) for problem #2, the application software maintains writing the correct # of bytes, with no error status
3) the kernel log shows no error messages from any of the audio-related kernel or driver processing
4) the AIC33 registers (read via I2C) show the expected values set to them; none of the status registers shows value(s) that indicates an error condition
5) the McBSP bus shows no error conditions
6) the McBSP DMA interface shows no error conditions
If we kill our application software and launch it again, it re-opens the audio device, resets and initializes it again, the problem doesn't go away (either for #1 or #2). If we soft-reboot the target (software reboot), #1 is fixed but not for #2. If we power cycle the target (cold restart), the problem goes away.
Based on the details I have described above, we don't understand either of these problems or know the cause of each, especially when there are no obvious error conditions and one side (input or output) continues to work fine. Since it only happens on power up, I'm thinking it's some kind of initialization problem or race condition.
I have emailed TI for help on this but they asked us to make sure the RESET pin to the AIC33 is held low for at least 10ns. I have confirmed that with our digital engineer; the RESET is hooked up to a companion chip and it's held low for 61us during powerup, so I don't think that's the problem.
Can anyone here with relevant expertise or who faces similar issues give us some advice on resolving this problem? This problem has been an ongoing issue and we need to resolve as soon as possible. Thank you!
Regards,
Andy
