I have a problem with the i2c Interface of the AD5696R.
I wrote a test procedure with the intention to test my read an write function for an EEPROM which shares the bus with two of these DACs and some other IC. This functions sends multiple bytes starting with value 0x10 and increasing it by 1 with each byte.
For some strange reason the AD5696 responds to a bit-pattern that matches its address (one is configured ad 0x0E, the other 0x0F) in the middle of the transfer.
As result the master (an Atmel SAMA5D3) does release the clock line when it recognizes the "second master" that drives against it's data line. This Situation is shown on the screenshot. The test procedure sends the Bytes 0x1A, 0x1B, 0x1C and at last a 0x1D which matches the 0x0E address followed by 1 bit for a read transfer. I assume the DAC now sends it's ack which is transparent for the master as the regular adressed slave also sends an ack. Now the DAC sends 3 additional zeros witch are also transparent because the master is sending the first 3 bits of 0x1D. In the moment the master releases the data line to send the first 1 it recognizes someone forced the line to zero and stops sending data
I'm not able to end the transfer by manually generating clock cycles. The AD5696 is freezed in its state. Only a reset can release the data line.
If I disconnect the DAC with adress 0x0E from the bus the same problem appears with a pattern matching the 0xF address of the second DAC.
Do you have any idea?
Can someone answer?
I have same issue.
We have the same problem but with AD5697R i2c interface, which i suspect AD use same block for the i2c interface on all of its i2c devices.
In our projects we have other i2c devices on the bus - two NV memory another ADC,two PCA9555 devices and ARM CPU.
When accessing the NV memory chip 24LC512 on the i2c bus and on reading only operation, at some addresses we see the SDA line get stuck at low. It eventually after a lot of SCL clocks gets released. We disconnected one by one all of the i2c devices and found that it was the AD5697R chip currently at address 0x0C that was causing this.
We change the chip address to 0x0F and now the same problem but in different part of the NV memory reading.
We focus on the AD5697R chip and try to 'reset' command or 'three state' command to see if this will make it not behave like this - but no success.
We did some continues read on the chip and see that if we read odd number of bytes it get stuck in SDA low, this kind of explain why we have the SDA low - the chip have this behavior when is read, it doesn't explain why it gets activated when it is not addressed.
I thing it has a bug in the i2c interface in the chip and cant find any work around it.
I'm sure that our i2c timing and frames are correct - as seen on digital oscilloscope with i2c decoding. None of the other i2c devices has any problem with same i2c interface. Our speed is 400kHz, we try with lowing the speed but no success - still problem.
Please help with some work around or tell us of known problems - errata.
Hi sss and msar,
We sincerely apologize for the i2c bug you experienced, you may get more information from your distributor for replacement of affected units.
You may also refer to this thread:
Possibly severe bug in AD5695 I2C interface?
this explains the problems we are having.
Now our problem is that we can't find any of these new AD5697 devices as stated in :
As of today 6/3/2017, we can't find any of the new devises with DC 1636 and we looked very hard all over the continents and distributors, as we are having a dead line with new product .
Can ADI tell us when actually the new devices is coming, so we can make decision on our design.
If you have any samples, can we get some, to evaluate if the problem is fixed.
I forwarded your concern to our right contact, I'll update this thread once I can give you an update.
Can you please contact your distributor with regards to your concern?
We did contact them and nobody has the new chip with date code 1636.
They all have the old date chip.
Thanks for your reply.
You can also ask the distributor regarding the availability, in that way they can ask their contact.
At the same time kindly send a query here.
This document was generated from the following discussion: AD5696R I2C SDA stuck on GND
It's best to get the devices with date codes later than 1636. Just in case you want to order directly from Analog Devices, they all have date codes >1636.
We are working with Digi Key right now to get the proper date code parts.
One question is the date code appears to be truncated on the chip marking.
Parts marked with a #144 do not work in our system where as parts marked with a #743 do work.
Have you tried communicating withe the distributors? Regarding the question if a direct order will result to the latest die to be delivered, I will ask our local contact and will get back to you.
I am having the same issue as in this document. We have two chip date codes 144 = bad operation, 743 = good operation. How do I make sure I can get the updated die when I order through distribution? I can see stock at Digi Key, Mouser, Rochester Electronics (I thought this was an active part usually Rochester has older going obsolete parts?). Or can I order from Analog Devices directly to make sure we get the latest die?