Difficulties w/ EVAL-ADAU1467Z and TDM I/O

Hi. It does sound like a configuration issue. The '66 and '67 configuration should be nearly identical, but I'm happy to take a look. Can you post your project?

Thanks,

Ken

Hello rg1,

I think you do not have the core synchronized with the incoming sample rate. Try to set the core sample rate to follow either the serial input 3 or serial output 3 since they both have the clocks from the streamer.

Here is where you find it:

If this does not fix it then zip up the project and attach it to your post. Then Ken or I can have a peek at it.

Thanks,

Dave T

Here's an archive with the project file. I'm working on exploring your suggestion now.

1467 TDM16 Comms test 1.dspproj.zip

Hello Dave,

Unfortunately, your suggestion has not solved the issue. I no longer see the positive feedback instability, but there is still a substantial amount of noise present. I've attached an archive containing in input/output file pair (recorded using Logic Pro X), perhaps it will help track down the issue.

TDM16 IO samples1.zip

Hello rg1,

Thanks for the files, they were helpful.

The clicking noise is where you are getting some missed bits being clocked in. The one with the loud noise is where a lot of bits are being lost.

This is all signal integrity issues where the clocks/data are not making it to the destination in time or have a lot of reflections. Another possibility is that the waveshape is so bad that the signal is not staying above or below the thresholds of a 1 or 0 for long enough. This can also cause double triggering.

So reading back at the thread I see you are using an eval board and an external streamer. So how you are jumpering over these signals is paramount in trying to make this work. I2S is fairly easy but going to TDM8 is a little more difficult and TDM16 is really difficult.

The other thing is that when using TDM16 the timing margins are very close. The optimum setup is to have the serial input ports of the DSP be a slave, which you are doing, and the serial output ports be a master, which you are not doing. I understand that you have to do it that way because the streamer has to be the master.

So you need to do what you can to keep the timing margins good and not flaky. The most important thing will be the jumper wires you are using. If you can post a photo of your setup that would help to make specific comments.

Basically, you have to keep lines as short as possible.

You have to run grounds along with the clock and data lines. I mean right along with them as in either around them with a coax or the wire next to them on a ribbon cable. If you do not do that then the impedance is undefined and you can get very bad waveforms.

The other thing you will have to do is to increase the drive strength of the SDATA out of the output serial ports.

In your project the current setting was minimum. This will make the timing margin too long to even work on the output side. In the ADAU1452 datasheet I had included specification showing the delay of the SDATA output when in slave mode with different settings. With it set to minimum the delay for the SDATA to appear when the bitclock changes is 35ns. The period of the entire frame is 21ns so it is way too slow. Set it to max and that should help some. I am guessing the drive strength of the USB Streamer is not adjustable.

Also, the Start Pulse was still set to the internal clock, You MUST set it to follow the clocks coming in on clock domain 3. which seems to be where you have the USB Streamer plugged into. Not doing that will also cause the clicks and pops you have experienced. There is more than one way to get those symptoms.

Thanks,

Dave T

I must have neglected to save the project after changing the Start Pulse setting and before archiving it. My apologies for any confusion; the I/O sample files were recorded with the Start Pulse set to domain 3.

For clarity, the TDM16 in the project filename refers to the firmware for the MCHStreamer, which uses one hardware data pin for each eight channels (i.e. TDM8.)

I won't be able to experiment with your suggestion regarding SDATA output drive strength until Monday; I will be sure to update then. In the meantime, I've attached a couple photos of the wiring connecting the EVAL-ADAU1467Z and the MCHStreamer. The colorful wires are clocks and data, and the black wires are grounds.

The other development setup I have (MCHStreamer to EVAL-ADAU1466Z via two channels of TDM8) works fine with all channels playing content; this seems to suggest that the drive strength from the MCHStreamer (which as far as I know is not adjustable) is sufficient.

Hello rg1,

Well, I have not complaints about your setup. Lines are about as short as is reasonable, you twisted the grounds around each signal line individually. So you have done all you can to keep the data transmission as good as you can. It is still jumper wires so it can be tough.

Can you take a quick picture of the lower part of the eval board? We have a data code there so I can pull up the exact schematic. I would like to check to see if there are any issues with the codec on the board. I am pretty sure you are in the correct place, Serial port 3, but it is good to check.

So at the moment you are only trying to run at TDM8? I think that is good to start there.

You are correct that it is a good test that it worked with the other eval board.

I also see the scope probes. Can you take some screenshots of the clocks and data?

Thanks,

Dave T

Dave,

I've attached images of the bottom corner of the eval board and the clocks and data with the SDATA3 pin drive strength at the default (lowest) level, and at the highest level. Waveform integrity looks OK to me for both settings, though I do see some overshoot on the highest setting (not surprising.) The higher drive level does not resolve the problem (also unsurprising, given the digital waveform data.)

Lowest pin drive:

Highest pin drive:

Hello rg1,

This is a bit of a head scratcher. I see you are in the USA, can we talk on the phone when you have the setup in front of you?

Just send me a PM with your phone number and when it is a good time to call. Keep in mind I am on the east coast but my hours are flexible right now.

Thanks,

Dave T

Dave,

I wanted to let you know that I was ultimately able to finish debugging my project. The feedback was coming from a routing error in the DAW software; the correct settings for TDM 8 were those you suggested (delay-by-1.)

Thanks so much for your assistance in solving this problem!