ADAU1701 I2C read

Hello Dave

Thanks for the detailed answer.

The main point is the missing ACK from the ADAU1701 device, if we look closly at fig 21 the first frame ends with such an ACK (which the I2C master would sample on the 9th rising edge of SCL). That is before we can continue with the additional frames of the exact register address inside the ADAU1701.

In other words, the first frame is to select teh ADAU1701 on the I2C bus, with the next 2 frames to select the exact ADAU1701 register . This is true for both read and write operations. the rest of the frames differ between read/write operations. Only on frame 4 you send a repeated start condition. The waveform indicates that the master sent a stop condition as it got a NACK. I believe that this was the right responce.

The same first frame with a write operation resulted in the ADAU1701 sending the required ACK.

I will try to check if the timing is marginal and is the culprit.

Is there anything we're missing?

Does the ADAU1701 needs an initial write before a read?

Thanks

Alon

Hello Dave

One more thing, the SCL high time is OK. As is its rise time

See on right of waveform these are measured as Thigh=843nSec & Trise=175nSec.

Hello Alon,

This is a good question... Your waveforms look good except that it is not going all the way down to ground but I don't think this is a problem.

Your clock waveform is not 50/50 ( which in itself is not a problem)  and the time high looks awfully close to the minimum time for SCL high which is 0.6us. Hard for me to read it exactly on your screenshot. It is a great screenshot but this specification was difficult to get off of it. You are at the max of the SCL rate, 400kHz so perhaps you should try to slow it down to something like 200kHz to see if it is time related.

I see in your schematics that you have ferrite beads/inductors between the DGND, AGND and what may be the main system ground. It is not a good idea to have the inductors on the path to ground. This will make the entire plane radiate with any high frequency currents so passing EMI spec would be difficult. So I recommend to remove those and tie all the grounds directly to one ground plane.

It looks like you have the ability to use the Selfboot feature. If you do use it you have to make sure the selfboot is complete before trying to address the part. Having an MP pin signal that the program is running is a good way to do that.

I see that your default is to stuff R17 and defeat the selfboot.

You have R31 and R26 as NC. I think you will want to stuff one of them.

Now, perhaps this is more fundamental. Did you look at Figure 21 in the datasheet? If you want to read from the part you first have to write to it the address of where you want to read from. Then you do NOT send a stop, instead you send a repeated start with the "Read" bit set. Then it will turn around the SDA pin to be an output and drive the data onto the buss with the following clocks from the master. It will continue to increment the address and send out data until it sees the stop condition.

So let me know if you make any progress.

Dave T

Hello Alon,

Yes, it needs a write before a read. That is the way the state machine is setup. You cannot just send a start with the bit set to read. It must be a repeated start after the write setting the read address.

Dave T

Hello Alon,

Thought I should explain it a bit more.

All I2C commands start with a write followed by the two byte address.

Then one of two things can happen:

1) If it sees clocks it will continue to accept the data and it knows it is going to write to the address. Then it another byte of clocks arrive without a stop then it will increment the address and stuff the new data into that address.

2) If it sees a repeated start followed by its chip address and the "read" bit set, then it will turn the SDA pin over to an output and start shifting out the data in the address it received. Then if it continues to receive clocks with no stop condition it will increment the address and send out the next address.

Then finally, a STOP condition will end both of these types of transactions and return the state machine back to its start point.

Hope that helps.

Dave T

Hello Dave

Yes, but on commands the first frame should end with an ACK.

Let me try to elaborate on the issue.

The board was powered up, and the customer tried to check his I2C design with all parts on the bus.

He tried reading from all devices, and the only one who failed (send a NACK) was the ADAU1701.

Than they tried a write command, and got an ACK from the part.

So, maybe for a part which hasn't been configured we need to do a write transaction (6 or more frames) before a read transaction?

If yes, this is undocumented in DS.

Thanks

Alon

Hello Alon,

I explained this all above but I will repeat. You must write the address of where you want to read data from first.

So what is going on is that they are sending a read command and the 1701 is saying "Read What? you never gave me an address!" and not acknowledging.

This is documented. Here is a screenshot from the 1701 datasheet:

Look at figure 24. This is what needs to be sent"

Start condition,

Chip address with R/W = 0 which is a write command

1701 will ACK

Send the high byte of the address

1701 will ACK

Send the low byte of the address

1701 will ACK

Repeat the start condition

Send chip address with R/W = 1 which is a read command

1701 will ACK

Send clocks and 1701 will output data

Master will send an ACK but the 1701 will ignore this ACK since there is nothing it can do about it should it not arrive.

If you send another set of clocks then it will increment the address and send out another byte.

Master will ACK

this will continue until a stop condition is sent by the master.

The next time they need to read this all has to start over.

Dave T

Hi Dave

does this (addr write before read)  equally apply to the adau1467 ?

not that it would pose a problem as the example code always writes the addr before read.

regarding the tcp protocol below , the "chip addr" is not specified in numbers of bytes.

also in the response format "address" has both bytes marked as "hi"

how can a bit have the value of 0x0A, if this is a byte , can wiki be updated to reflect that ?

TCP/IP Channels (ADAU144x / ADAU145x) [Analog Devices Wiki] 

best regards

Nicholas