• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 45 subscribers
  • Views 649 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DAC8734 Serial Data Corruption

GARY SKANTAR
Prodigy 30 points
Other Parts Discussed in Thread: DAC8734, DAC7716

I was having trouble with the DAC8734 experiencing serial data corruption until I changed my serial data timing to also surround the leading clock edge.   The corruption would include having DAC-0 data written to the command register.  During the debug of the problem I slowed the serial clock rate down from 20Mhz to 10Mhz and the corruption actually got worse.   I couldn't even load the command register without several attempts.    Several scope shots of the problem are included.   Does anything look obvious from these timing traces that would account for this anomaly?   I've also checked with the analog scope probes and the data and clock look fine at the converter itself.  The LDAC- line is continuously low in all cases.

10MHz SCLK Serial Clock Rate Overall Picture FAILS

10MHz SCLK Serial Clock Rate Expanded Data FAILS  (Note data trails clock at leading edge - this breaks it really bad...)

20MHz SCLK Serial Clock Rate Overall Picture GOOD

20MHz SCLK Serial Clock Rate Measuring Clock GOOD

20MHz SCLK Serial Clock Rate Expanded Data GOOD (Note data at leading clock edge meets same set-up/hold as trailing edge.)

  • 0
    TI__Genius 10615 points
    Hi Gary,

    Thank you for the scope captures, this will really speed up the debugging process. I can't really see anything wrong with the plots right now. Do please keep using the ≤10 MHz while we debug the issue in order to avoid running into any timing constraints. Once we have this working, we can attempt to get the 20 MHz problem resolved.

    I have a few questions to help me debug this issue.

    Can you share with me a few of the codes that you are attempting to write data to the command register and DAC-0?
    Can you try to get a capture of the digital signals using an analog probe? I want to see if the signals have any overshoot that may be causing some issues. In this case I would like to see the digital input signals at 10 MHz and at 20 MHz.
    What supply voltages are you using?
    What is the voltage of the digital inputs?
    Are you following the power supply sequencing outlined in page 22?
  • 0 in reply to Eugenio Mejia
    Prodigy 30 points

    Just to clarify, the problem occurs with either 10Mhz or 20Mhz serial transfers.

    The code that is written to the command register is "dac_ser_data <= { 4'b0, 4'b0000, 6'b0, unipolar, 3'b0, 4'b1111, 2'b0 };".  This sets the gains to 4 and sets/resets the GPIO-1 which is used for bipolar/unipolar control.  I can immediately observe the GPIO-1 bit to see whether a command register operation is occurring when it should or should not occur.  This was my trigger point to debug this problem.  The code that is written to DAC-0 register is "dac_ser_data <= { 4'b0, 4'b0100, (dac_data[15:0] };".  This is the DAC-0 address along with the data field.

    The analog signal traces follow below.

    The supply voltages are IOVDD = DVDD = 5V,  AVDD = +15V and AVSS = -15V.  The power supply sequencing on page 22 is being followed.

    This picture is with a 20Mhz serial clock.  D4/Blue trace = SCLK.  D3/Green trace = SDI.  This mode fails.  Note that there is a buffer between the digital signal on all of these traces and the analog trace.

    This picture is with a 10Mhz serial clock.  D4/Blue trace = SCLK.  D3/Green trace = SDI.  This mode fails most frequently.

    This picture is with a 10Mhz serial clock.  D4/Blue trace = SCLK.  D3/Green trace = SDI.  This was a test where I changed the slew rate of the SDI output from slow to fast.   The end result was that the SDI was aligned with the leading edge of the clock as opposed to trailing it.  This mode worked all the time.  This led me to my conclusion that the leading clock edge data set-up/hold was important.

  • 0 in reply to GARY SKANTAR
    TI__Genius 10615 points

    Hi Gary,

    Thank you for your patience. I am still evaluating this problem, I will get back to you tomorrow with some comments.

  • 0 in reply to Eugenio Mejia
    Prodigy 30 points
    I noticed that "DAC7716 SPI Problem" is describing the same sort of data corruption problem related to the timing of the serial data line at the leading edge of the clock. This is the pin compatible 12-bit version of DAC8734.