Post Go back to editing

Reading the AD5696R

I am investigating a problem we are having with reading from the AD5696R. When following the "read operation" procedure, the value returned is nearly always 0x91. I attached a Corelis BusPro-I I2C monitor to the EVAL-AD5696RSDZ and performed a read, and noticed that it did not seem to be following the procedure. When reading from DAC C, the command following the first address byte was 14, not 04 as I understood from the datasheet. Can you explain why I am seeing a different read operation than is described in the datasheet? 

  • Hi Kevin,

    Can you provide the datecode of the AD5696R you are using? Thanks



  • Neither the ACE software or the datasheet happen to mention a datecode. The AD5696R on my EVAL-AD5696RSDZ has the letters BRUZ and a #713. It will require considerably more effort to get at the AD5696R we are using in our application.

  • Hi Kevin,

    Unfortunately we need the datecode (i.e. #713) of the AD5696R which you had problems in communicating using the Corelis.



  • Hi,

    the date code #713 refers to a unit before the device was fixed. 

    This may explain why you cannot communicate with the device.

    The faster option to get latest silicon is by requesting samples thru the ADI web page.

    Answering your question, the DS recommends a NOP command BUT, as the command is just to point to the register, and the restart condition aborts the command, the command transmitted is irrelevant.

    Best Regards,


  • Because I observed a problem in my application, I attached a Corelis to a EVAL-AD5696RSDZ in order to observe its operation and see how my attempted reads differ from EVAL-AD5696RSDZ successful reads. So far, I am able to write but unable to read with the Corelis. Also, I have observed that EVAL-AD5696RSDZ reads use a "write" command(0x1) while reading even though the datasheet specifies "NOP" (0x0).


    I hope to learn how to control the AD5696R on my EVAL-AD5696RSDZ using my Corelis. If this succeeds, I will attempt to control the AD5696R in my application the same way. So, the problem in front of me right now is my AD5696R with date code #713.

    above, the Corelis monitoring the EVAL-AD5696RSDZ read of DAC B. Below, the Corelis tries reading DAC B.




  • This eval board was ordered directly from Analog last month (order #9396705). When I retrieved the box it arrived in I found a date code of 1751 printed on the box. 

    1. The data sheet should explain how to find the date code.

    2. I don't have access to the boxes the parts used in my application arrived in. Please tell me how to find the date code.

    3. I am still interested in knowing why reads attempted through the Corelis fail.

  • Hi Kevin,

    Can you get the latest AD5696R please? Or have it replaced by the vendor.



  • Hi ,

    Could you try this sequence if this will work for you please?

    When reading data back from the AD5696R DACs, the user begins with an address byte (R/W = 0), after which the DAC acknowledges that it is prepared to receive data by pulling SDA low. This address byte must be followed by the COMMAND BYTE, which consists of the higher nibble COMMAND CODE = 0x9 or the READ INPUT REGISTER COMMAND, and the lower nibble DAC ADDRESS CODE equivalent to the DAC channel (multiple DAC channels not applicable), which is also acknowledged by the DAC. The COMMAND byte must then be followed by a 2 BYTE DUMMY DATA (0x0000 or 0xFFFF) to complete the write operation. Following this, there is a repeated start condition by the master and the address is resent with R/W = 1. This is acknowledged by the DAC, indicating that it is prepared to transmit data. Two bytes of data are then read from the DAC. A NACK condition from the master, followed by a STOP condition, completes the read sequence.



  • Lines 1-5 are a read triggered by the board, DAC A reads 0x7EA8 

    Lines 6-9 are a write from the BusPro-I, setting DAC A to 0x6543

    Lines 10-14 are another read triggered by the board. DAC A reads 0x6543, showing that the write was accepted by the AD5696R

    Lines 15-21 are an attempt to follow the procedure suggested above:

    Line 15 writes the address, R/W = 0

    Line 16 writes 91

    Line 17&18 writes two bytes of dummy data

    lines 19-20, repeats the address R/W=1, followed by two reads

    I tried many times, with both 00 and ff as the dummy data bytes

  • Hi ,

    You are getting NAKs from lines 15-19. Can you delete lines 1-14 please and do these:

    1) write to DAC by using command 0011 on Channel 1 (0001), then stop and check DAC channel 1's output if the voltage is correct.

    2)  Repeat Lines 15-21.