• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 45 subscribers
  • Views 474 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC8718 Read-Back of DAC-0 thru 7 not working per datasheet

John Weber
Prodigy 160 points
Other Parts Discussed in Thread: DAC8718

I can successfully read and write all of the registers on the DAC8718 except for the DAC-0 thru DAC-7 DAC Data Registers which do not read-back according to the information on the datasheet.

With A/B = 0 (D15 in Configuration Register) I get all zeroes even after writing to all the data registers. All other registers read-back with the expected data.

With A/B = 1 I get the Input Data Register data, NOT the DAC Data Registers. 

I am using LDAC# to load the data registers and this is working properly - outputs all respond as expected so I know that the data has transferred to the Data Registers.

I am operating the SPI bus on a 16MHz clock, signals look clean and no timing violations that I can find. The correction engine is NOT enabled.

AVDD = 24.6V, AVSS = 0V, DVDD = 5V  and Configuration Register is loaded with either 0x0180 or 0x8180 depending on which registers I am trying to read.

I do single register reads using the method shown for "Single Reading" on p.46 - perhaps the explanation on the A/B configuration bit is in error?

Since the outputs are doing what I expect I do not have a show-stopper, but it would be useful to be able to read the DAC Data Registers to validate that data has been written and loaded correctly.

  • 0
    TI__Genius 10615 points
    Hi John,

    If I understand correctly, you are reading back the registers of the DAC and by changing the A/B bit, you expect to differentiate between input data register and DAC data registers, which is how the DAC is supposed to behave.

    In order to make things a little bit clearer, can you share with me the sequence of codes that you are sending to the DAC after power-on until read-back? This will help me understand the setup and flow of your application.
    If possible a oscilloscope capture of one of the read-back sequences as well as a schematic might be useful.
  • 0 in reply to Eugenio Mejia
    Prodigy 160 points

    After power up, RST# is set HI and then 0x000180 is written to set the Configuration Register for our application.

    There are 8 writes to the DAC-x registers, loading 0 with 0x1111, 1 with 0x2222 up to 7 with 0x8888 for debugging purposes. LDAC# remains high the entire time these writes are occurring.

    If I read-back those registers at this point all I get are 0's for all of them, though other registers will read correctly - this is with the A/B bit set to 0 which SHOULD be giving me the Input registers so that I can verify that the data is read correctly. At this point the Data registers should all be 0x0000 and the voltage outputs are all at 0V as expect.

    Without asserting LDAC# at this point, if I write 0x8180 to the Configuration Register and read all the registers I get the values previously written - but with A/B set to 1 I should NOT be seeing the input registers.

    After asserting LDAC# (low for ~100ns) the output voltages go to their expected values indicating that the Input Registers have all been transferred to the Data Registers. However, the same situation for read-back occurs as described previously: A/B=0 returns 0's, A/B=1 returns the written values. 

    If I write different data to the Input Registers without asserting LDAC# afterwards I will read-back the new data when A/B=1 and 0's when A/B=0. 

    A scope capture of a read of the DAC-0 register is shown below - A/B=0 in this instance but the value in both the input register AND the data register are 0x1111 (verified based on the output voltage).

    Since it seems that A/B=1 returns the INPUT register I can rely on this for verification that data has been properly written prior to asserting LDAC#, but I am always concerned when a part does not behave per the datasheet and want to make sure I am not doing something wrong that will lead to other issues later.