Post Go back to editing

AD5696R  I2C SDA stuck on GND

Hi.

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?

Parents
  • Hi all,

    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.

    regards,

    msar

Reply
  • Hi all,

    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.

    regards,

    msar

Children
No Data