CC2564MODN: CC2564MODN I2S Config Questions

Jason,

We, will review the audio configuration and get back. Please, take a look at section 6.4.3 in data sheet - www.ti.com/.../cc2564c.pdf
You can configure the bit positions of the channels to select only 16 bit (MSB) of a 24 bit PCM from the codec..

Thanks

Alright so I think I have the codec configured a bit better, but the CC2564MODN is not driving the audio bus low at the end of the 16-bit frame.  The ADAU1772 codec does not support 16-bit mode because the CC2564 requires a wait block in between audio channels, and so I am afraid the drooping line is occasionally being picked up and interpreted as lower-order bits of noise.  We've also observed the codec's automatic gain control getting confused and begin stuttering unexpectedly.  

Attached is a waveform showing how the CC2564 is just letting go of the line (yellow trace) of its 1 channel of 16-bit audio data.  The blue trace is both channels of the 24-bit ADAU1772. 

And this is with a 10K pulldown added on.  We will try with a 1K pulldown, but a better solution would be for the CC2564 to correct it by driving the line to the correct state.  

Thank you,

- Jason

Well using a 1K I was able to get the droop almost completely gone, but the out-of-sync remains.

When in Dual SCO mode I have clear audio going on both input and output channels. But occasionally the phone connected on the second SDO channel will flip out and begin a rapid loud click. If I tell the codec driving both channels of audio to the CC2564 to mute/unmute that channel, clicking goes away, but could come back later. A workaround has been to mute/unmute the codec every second and then this isn't really a problem, but that would be a horrible way to resolve this.

The I2S data all looks properly formatted during this time, so I am wondering if this might be the result of the CC2564 not keeping up? Ever seen anything like this before? The audio to the CC2564 from the phone, and the audio channel to/from the first SDO connected device are all clear during this time.


Thanks,

- Jason

Hi Jason,

Reading through your description above, it looks like the data in/out edge selection may be causing the occasional tick sound you are observing. In addition to the data in/out offsets for both channels, you can also configure the CC256x to use either rising or falling edge of the bit-clock to sample/assert (depending on the data in/out signal) the data. The general idea is to use the opposite edge on the CC256x than that of what the audio codec is using. In the screenshot of the logic lines above, it appears that the ADAU1772 codec in your system asserts data on the falling edge of the BCLK. So the data in edge (for both channels) on the CC256x should be configured for the rising edge. This way, the high-low transitions on the line do not result in corrupted data packet on the other device. Please revise your codec configuration settings to make sure the opposite edges are selected in both directions.

Best regards,
Vihang

Hello Vihang,

   Yes, I understand that the codecs must be configured to properly clock in/out data on the appropriate edge.  And I do believe we have that configured properly, with both devices accepting data on the rising edge.  As a quick test I tried adjusting the edges and that only resulted in ear-shattering screeches throughout the system.  ADI is assisting on their end with duplicating the setup to rule out anything unusual taking place with the codec, or a mis-configuration with either part.  

   Attached are some additional screen captures showing the left channel and right channel.  Yellow is FSync, Green is BCLK, Purple is the CC2564MODN and Cyan is the ADAU1772 codec.  These were taken with persistence on to better illustrate the edge transitions, and I used a vertical cursor to flag the rising edge transitions. 

   Please note the CC2564 in purple is just letting go of the line and not zeroing it out as would probably be helpful... and this is with a 1K pulldown added.

   The right channel (phone) where we are having the issue has one artifact in that screaming into the phone fails to change the 3 highest order bits.  But screaming into the ADAU1772's mic input does toggle the highest order bits.  Not sure what might be causing that, but it isn't directly related to our issue as the Audio quality from the phone is fine.  It is only audio to the phone that becomes corrupted.

   I'll provide an update next week when ADI's results are available, and after we've had time to test with clock edges some more.     

Left (Bluegiga Base) 

Right (Phone) 

Thank you! 

 - Jason

Hi Jason,

Thanks for the update. I will keep an eye on the thread for your additional results.

Jason Gossiaux said:

  Please note the CC2564 in purple is just letting go of the line and not zeroing it out as would probably be helpful... and this is with a 1K pulldown added.

Can you please elaborate on the 1K pulldown? The I2S/PCM pins on the CC256x already have an internal pull-down. Please refer to pin attributes in the device datasheet for details. Could you please double check that your system design complies with the reference schematic provided in the datasheet (and EVM design files)?

Best regards,

Vihang

Hello Vihang,

  If you are referring to the schematic Figure 6-1. Reference Schematics, then yes... we have single traces with no other components connecting the AUD_* signals from the CC2564MODN to the Codec.  Both parts are 1.8V logic so no need for isolation or level translation.  

   On multiple designs with multiple I2S interfaces from the CC2564MODN to other codecs and MCUs we've observed the Audio Out signal failing to settle quickly after an audio transfer is complete, despite (as you can see from the scope capture) where the edges are clean and transition fast during data delivery.  Only when the output goes High-Z does the I/O takes time to settle.    What value internal pulldown is present?  The datasheet did not seem to specify it.  

Our designs do not have an additional pulldown in them, as we were relying on the CC2564MODN's internal pulldown.  But, given the issues we were having we decided to mod one in to try and clean up the line.  Can't quite make it work though.  If the pulldown is weak (100k?) there may be too much gate capacitance to discharge in a few microseconds?

- Jason

 

Jason Gossiaux said:

What value internal pulldown is present?  The datasheet did not seem to specify it.  

The internal pull-down is a weak pull-down. The value is somewhere around 90K to 120K. 

Ok, that would match our measurements and explain the scope captures.  I believe the CC2564 should be driving the IO low after the audio bitstream is completed - to match the behavior of our other codecs.  Letting the weak pulldown slowly take care of things is insufficient for higher BCLK rates.  

We are working with ADI to better understand the pin capacitance of their CODEC and better evaluate what size pulldown will be needed to address this.  But again - this is not related to or involved in the noise issues we are having.  It is just an observation of something that could be improved.  They are also working to duplicate our setup and perform further testing on the ADAU1772.  Hopefully we know more soon.  

Thank you,

 - Jason

Hi Jason,

Any new information on this thread? If not, I will close this thread while we wait for more information from your investigation with ADI. You can reopen the thread by posting a reply.

Best regards,
Vihang

Hello Vihang,

 I'd hate to get into a situation where we must navigate a trail of disjointed threads to reach a conclusion for this problem, so please give me another couple days to see where ADI is at.  I'll be attaching some additional waveforms that may provide additional insight into the I2S timing.  

Thank you,

  - Jason

Hi Jason,

No worries. In that case, let's keep posting a reply every few days to keep the thread from getting locked. I'll wait for further news from you.

Best regards,
Vihang

I appreciate it.  The ADI engineer has provided me with some new configuration options that I am setting up to test.  Not rushing and jumping to conclusions is the challenging part of this.  More to come soon.

Thanks,

- Jason

The real challenge here seems to be the requirement for 1 BCLK delay between both audio channels. The ADAU1772 is not capable of supporting the 1 BCLK delay on both CH1 and CH2, it wants to tightly pack both sets of 16-bits of data into the 32 BCLKS. But according to the CODEC config wiki page -

Channel 2 data out offset - Number of PCM clock cycles between rising of frame sync and data start. NOTE:
Please note that the offset of CH2 must be a minimum of CH1 DATA LENGTH + 1.
This requirement is important also when CH2 is not used.

From this I conclude the CC2564MODN requires one BCLK delay before the CH2 audio data. Am I reading that correctly, or could I set the offset equal to the length of CH1 and safely remove this delay? Because when set to CH1 DATA LENGTH + 1, I am getting the additional BCLK delay on my scope capture.

Thank you,

- Jason

Hi Jason,

Jason Gossiaux said:

From this I conclude the CC2564MODN requires one BCLK delay before the CH2 audio data. Am I reading that correctly, or could I set the offset equal to the length of CH1 and safely remove this delay?

If you do not have any BCLK delay for CH1 (in other words offset 0 for CH1), you can try setting the CH2 offset to the CH1 DATA LENGTH. I haven't come across the reason behind this note in the VS command documentation, but this setting is worth trying out.

BR,

Vihang

Hi Jason,

Thank you for sharing your findings.

Jason Gossiaux said:

Would it be possible to confirm that the CH2 OFFSET does not need to be +1?  And if so, would it be possible to get the documentation updated to reflect this?  This would be of great benefit to future designers with this part.  

It is possible that there is an error in the documentation regarding this. I have raised this issue internally and we will review it. If the offset of 1 is not required, we will update the documentation to add the correction.

Best regards,

Vihang

Would it be possible to contact me when this functionality is determined?  It seems unlikely a response would be posted here given the urgency to close this thread.

Our product will be used in industrial and safety environments where a misoperation could create liability issues.  Much more than a glitch in a consumer product would.  So, it is necessary for us to have these basic modes of operation documented accurately.   It is also of concern that a future silicon or stack rev could suddenly become faithful to the documentation and brick our shipping product.  This has happened previously to us, and from within the TI product line no less.

Would it be possible to expedite this determination with a contract or some other arrangement?  We are faced with inconsistencies within both pieces of hardware that just cannot be solved on our own.  Even just a timeline would be very helpful.  

Thank you,

- Jason