ADAU1328 "TDM (8-Channel I2S Mode) question

I'm trying to get the ADAU1328 working in slave mode with 8 output channels and 4 input channels, and according to my oscilloscope, I am duplicating the timing shown in Figures 12 and 13 in the ADAU1328 datasheet. At the moment, I am just focusing on the 8 DAC channels.

While Figure 13 refers to this as "TDM (8-Channel I2S Mode)", I find no reference to that mode in the Serial Format Field in the DAC Control 0 register. The way I got anything at all to work was to select "Stereo (normal)" and set the "BCLKs per frame" field in the DAC Control 1 register to "256 (8 channels)", but this doesn't seem right to me. With these settings, channel 0 appears to work, but none of the others do.

In order to reproduce Figure 13 timing, I had to lengthen LRCLK from a pulse at the beginning of the frame (low during slot 1 only, normally called Frame Sync) to a 50% duty cycle square wave (low during slots 1 - 4, high for slots 5 -8). Is this correct? Is there a TDM8 mode which uses a more typical FS? Again, that doesn't appear to be a choice in the DAC Control registers.

So my main question:

1) In order to have just 8 output channels, is Figure 13 the correct timing diagram, and if so, what are the appropriate control register settings? If not, which is the correct timing diagram?



Added the fact that the ADAU1328 is in slave mode
[edited by: robertsonics at 1:24 AM (GMT -4) on 27 May 2021]
Parents
  • 0
    •  Analog Employees 
    on May 27, 2021 10:09 AM

    Hello robertsonics,

    This part was developed when TDM was still relatively new so the names and descriptions of some of the registers can be a bit confusing. 

    I am glad to hear that you are using a scope to look at this. At some point it would be good to post some screenshots if you have more questions. 

    Set it to TDM Mode. 

    DAC Control 0 register, bits 7:6 and set it to "01"

    Set the SDATA delay to the setting you desire. Usually it is set to the default which is setting zero for a delay of one bit clock period. 

    On DAC Control 1 register:

    For a TDM format of 32 bits per channel and 8 channels you have to tell the part that there will be 256 bitclock cycles to latch in 256 bits of data per frame. 

    Now if you are sending a pulse that goes low for the start of the frame then I am fairly certain that you have to invert the LRCLK polarity. This may have been part of the issue.   

    Let me discuss the LRCLK ( Frame Clock ) 

    This part has a few quirks. For some reason the designers did not give a choice for LRCLK format when in master mode. If you are set to stereo it will produce a 50/50 duty cycle and in TDM it will produce a pulse. No choice. 

    For slave mode it does not matter too much. The part only looks for the start of the frame and for some settings it does not pay attention to the transition in the middle of the frame. You should be able to get it to work with the 50/50 duty cycle. The LRCLK polarity will only swap channels 1-4 with 5-8. You should be able to get this to work with the 50/50 duty cycle. Then switch back to the pulse mode and try changing the LRCLK polarity. 

    What is the frequency of the master clock?

    Is the DAC in slave mode? ( it seems to be )

    Are the clocks ( LRCLK and BCLK ) derived from the master clock? Are they synchronous is the real question. If they are not then the DAC will mute.

    One other thing... What are you doing with the PLL? Are you using it for both the DAC and ADC? There is a strange little bug in this part that if you are directly clocking the DAC and using the PLL for the ADC and the PLL is not locked, it will mute the DACs. 

    One other little thing is that you can search the forum for help with the AD1938. This part is pretty much the same part so any advice for settings on the 1938 will apply to this part minus the additional ADCs of course. 

    Dave T

  • After looking at some of the AD1938 questions, I realize you may want more background info. I am driving the MCLK and TDM lines from a Microchip SAM S70 CPU. The ADAU1328 is replacing an end-of-life codec from another manufacturer in an existing product. The 11.2896 MHz MCLK is generated by the S70's SSC peripheral in master mode, as are LRCLK, BCLK and DO signals. I'm using a 44.1kHz sample rate. The previous codec had no internal PLL and the DAC and ADC were synced to the external MCLK and TDM signals, which is how I was hoping to use the ADAU1328 as a simple replacement.

    By the way, I tried setting the DAC and ADC clock source select to MCLK, but I got no output from the DAC.

  • 0
    •  Analog Employees 
    on May 28, 2021 1:55 PM in reply to robertsonics

    Hello robertsonics,

    If you want to directly clock the part and bypass the PLL you need to use an MCLK frequency of 512 x fs. I assume you still were using 256 x fs and hence that would be why the DAC output was muted. 

    It appears you are generating the master clock, LR clock and bit clocks correctly and synchronized with each other. When in the 256 x fs mode there has to be 256 master clock transitions per sample period. There is a counter so if it is wrong it will mute. So I think this is not the problem. 

    Based on my experience, I think I know what could be the issue. I am asking myself " what would cause the PLL to unlock every once is a while"? The answer is several things. 

    1) If the signal integrity is not good on the MCLK input then there could be edges missed or too many edges due to reflections etc. I actually do not think this is the issue but it is possible.

    2) Poor implementation of the PLL Loop Filter on the PCB or low quality components. With low quality components I usually see issues at cold temperatures where the caps change values a lot. Again, this is not what you are describing so probably not the issue however, PCB Layout issues is a possibility. 

    3) PCB layout problems with how the bypass caps are implemented, how the ground pins of the part is implemented and how the ground planes are implemented. I have seen this be an issue that causes the PLL to not hold its lock. 

    I am guessing this is a PCB issue. Can you send over some screenshots of the top layer, the internal layers and the bottom layer of the PCB around the codec? I do not need to see the entire PCB so you can protect your work by just showing the area around the codec. I will need to know where the bypass caps are located. A screenshot of your schematic showing the codec and the bypass cap numbers would be helpful. Also, I need to see where the loop filter components are located. 

    Thanks,

    Dave T

Reply
  • 0
    •  Analog Employees 
    on May 28, 2021 1:55 PM in reply to robertsonics

    Hello robertsonics,

    If you want to directly clock the part and bypass the PLL you need to use an MCLK frequency of 512 x fs. I assume you still were using 256 x fs and hence that would be why the DAC output was muted. 

    It appears you are generating the master clock, LR clock and bit clocks correctly and synchronized with each other. When in the 256 x fs mode there has to be 256 master clock transitions per sample period. There is a counter so if it is wrong it will mute. So I think this is not the problem. 

    Based on my experience, I think I know what could be the issue. I am asking myself " what would cause the PLL to unlock every once is a while"? The answer is several things. 

    1) If the signal integrity is not good on the MCLK input then there could be edges missed or too many edges due to reflections etc. I actually do not think this is the issue but it is possible.

    2) Poor implementation of the PLL Loop Filter on the PCB or low quality components. With low quality components I usually see issues at cold temperatures where the caps change values a lot. Again, this is not what you are describing so probably not the issue however, PCB Layout issues is a possibility. 

    3) PCB layout problems with how the bypass caps are implemented, how the ground pins of the part is implemented and how the ground planes are implemented. I have seen this be an issue that causes the PLL to not hold its lock. 

    I am guessing this is a PCB issue. Can you send over some screenshots of the top layer, the internal layers and the bottom layer of the PCB around the codec? I do not need to see the entire PCB so you can protect your work by just showing the area around the codec. I will need to know where the bypass caps are located. A screenshot of your schematic showing the codec and the bypass cap numbers would be helpful. Also, I need to see where the loop filter components are located. 

    Thanks,

    Dave T

Children
  • Hi Dave T,

    Thanks for your quick response here. Your insights are super helpful. I am the hardware engineer on this project, and so I can provide some screen shots of the layout as requested. See below.

    Also, I should mention that I think part of the problem might have been my value choices for the PLL filter. I chose the values suggested in the datasheet for the LRCLR, not the MCLK. I am currently working on swapping these out to see if that fixes the issue. Also related, when I press my thumb gently over these components, the output starts to clean up into a nice perfect sign wave. At first I thought this might have been cold joints, but maybe it has something to do with my thumb adding capacitance to some part of this loop? Or maybe it's warming up the caps?

    Thanks again, and I look forward to your feedback.

    Cheers,

    Pete

  • Also, I thought I'd share a screenshot of the MCLK trace route from the S70 to the Codec, as you said earlier this could be playing into this. Thanks for taking a look!

  • 0
    •  Analog Employees 
    on Jun 1, 2021 6:49 PM in reply to rockonaudio

    Hello Pete,

    Thanks for the info, sorry for the short delay in my response.

    The LRCLK values will make it optimum for using it with an LRCLK as a clock source. I find that it does not prevent the PLL from locking but it might take longer or not lock at temperature extremes. So this might be part of the problem but not the entire issue. So for sure replace the filter with the MCLK values as a good start. 

    Yes, touching it will filter the noise and change a bunch so I think you found the solution,... you have to be shipped with the product and stand there touching the loop filter! LOL 

    The test does show that we are closing in on the issue that it is a PLL locking issue. 

    OK, Layout... Hard to explain this in a post without making it a short novel. Download the ADAU1452 datasheet and look at the example PCB layout on page 193. This will show how bypass caps should be connected to the power planes. 

    The other detail is that you should not tie to a plane that is under the part. 

    Here is an example:

    I drew in red "x" where the traces should not be going anywhere. I drew a couple of red circles to show where you should place a via and connect to ground and power planes. You should make a small VCCA power plane under this section of the part. This will make the bypass caps much more effective. 

    On the corners you need to place the bypass caps between the power and ground pins and again, make the current path from the pin to HAVE to go past the bypass caps on the way to the power and ground planes. Here is a rough sketch: 

    I see you have two power planes. Analog and Digital. We always use only one ground plane for both the DGND and AGND ground pins. Inside the part they are connected. I understand you most likely have different grounds in your system. Connecting the bypass caps in the manner I am describing will help and getting the correct loop filter components will help a lot and you might not need to use one ground. 

    One funny little thing, my first look at your screenshot made it look like the LF pin was tied to ground and all the ADC input pins! But your software is showing something in yellow/green that is clearly not copper! I saw this elsewhere in the screenshot where it was clear that the part would not be working if this was truly connected! 

    Do don't tie the ground pins to any of the top ground fill unless it is going past a bypass cap. 

    Dave T

  • 0
    •  Analog Employees 
    on Jun 1, 2021 7:02 PM in reply to rockonaudio

    Hello Pete,

    I forgot to comment about the MCLK trace. 

    You probably should have a damping resistor in series with the MCLK signal. The line is close to the length where you should have one. The test point will cause a reflection but  as long as the drive strength is not too high it will probably not be an issue. To properly design the transmission line you should use a signal integrity simulation software to help determine the value of the resistor. 22 -33 ohms is a good ballpark but just a guess. I am not expecting this to be the issue. But, I am wondering if you have a four layer board? You need to have at least four layers with the power and ground planes on internal layers. 

    Dave T

  • Hey Dave T,

    Thanks for all your feedback. Good news, we swapped out the PLL filter values and it seems to have cleared up the issue!

    Nevertheless, I have also implemented your layout feedback. However, we are trying to stay at 2-layers, and so I do not have a VCC plane. In stead, I have it routed with a thicker trace on the bottom copper (and still trying to maintain good bottom copper AGND plane. I have also removed the analog GND from the top layer (underneath the IC) - and now am making all of the AGND connections with vias to the bottom copper AGND plane.

    Also note, sorry about the confusion about  the yellow layer in my previous images. That was the "tDocu" layer in Eagle, and it is not copper, and intended to help the designer keep track of actual leg length and part sizes.

    Here are my new cap placements and routes to vias.

    And here is a wider shot with the VCC net highlighted:

    And here is a closer shot of the PLL filter loop (I was able to tighten that up a bit):

    I wasn't sure how to handle this additional AGND pin at pin 32, so I just grounded to AGND with a via nearby. Is this okay, or should it be routed to the GND via next to the nearby bypass caps?

    Thanks again and I look forward to your response!

    Cheers,

    Pete