Marc,
Can you please specify your hardware p/n, revision, and CPLD revision?
Thanks

Hey Kurt.

The CE has P/N 80000113-057 rev e04. The CPLD reports revision number 0x20a which might be 0xa. My code reads 16 bits, but I think the revision registers are always 8 bits.

Is this a known problem on one of the revisions?

For this product, the CPLD does support a 16 bit revision code, and 0x020A is a valid revision.
Version 0x0200 supported 8bit only
Version 0x0201-0x020A supports 10bit
Version 0x020B supports 16bit

Have you followed the process in these application notes for communicating with the CODEC?
http://www.logicpd.com/do...N_70000187_Rev_A.pdf
http://www.logicpd.com/do...N_70000194_Rev_A.pdf

The documentation states that the CPLD will shift out 10 bit per sample. The oscilloscope shows that only 8 bits are emitted. As usual, there are only two possible reasons.

I've read the application notes. There isn't much to them and it looks like a binary sort of scenario. Either it works or it doesn't. There isn't any place I can see where the width could be truncated. The audio playback is correct in that I can hear the waveform.

Is there a way for you to verify that the output from rev 0x20a is really 10 bits?

Marc,
I tracked down a 80000113-0057 rev E01 board with CPLD code 0x020A and Logic Loader revision p1.2.5. While using the Lolo "beep" command I was able to play a sound and use an oscilloscope to capture the I2S BCLK, DI, and LRCIN signals. After capturing a few unique screen shots for each channel, I was able to confirm 10bits of data was correctly transfering out of the CPLD to the CODEC.

I checked the revision differences between E01 and E04, the only difference that would affect the product is that R27 was removed because it was a duplicate pullup on the MSTR_nRST signal. This should have no affect on the CPLD or CODEC. The other changes were Lolo software updates.

A few things you might want to check to help debug your issue:
- Ensure CPLD chip select area is defined to 16bits.
- Add a waitstate to the CPLD chip select to ensure that the CPLD has sufficient time to latch in the correct data on the bus.
- Ensure audio file being played is 16bit per channel.
- Ensure software that converts the audio sampling rate doesn't also change resolution.
- Fill audio buffer with 0xAAAA for each channel, then use an Oscope to watch the data for each LRCIN change, the data should toggle for 10 bits, if not, the CPLD isn't getting the correct data.
- If not getting correct data to the CPLD is suspect, use a logic analyzer to trigger on the chip select to the cpld and capture the data on the bus to ensure that the data is truely what you expect to be sending.

Good Luck.

Most of those I've either done or verified. I don't have a logic analyzer, so I'll have to see what I can do elsewize.

Thanks a bunch for checking on this for me.

I got dirty and used three scope probes. I was wrong in thinking that I was only seeing eight bits. There are definitely ten being sent. I spologize for making you chase a phantom.

BTW, there was a post about some sort of difficulty with the 2.4 kernel driver for audio on this target. Do you know what the issue is? I'm about ready to finish up my 2.6 driver and I want to make sure to fix anything that was broken in previous releases.

Cheers.