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.

DAC8830: SPI Timing Compliance & Reliability

Part Number: DAC8830
Other Parts Discussed in Thread: DAC8831, DAC8831EVM

Hi e2e community,

I'm attempting to control a DAC8330 with 5V TTL lines. The output of the DAC updates unreliably, unless I repeat the command in a burst of about ten sequences. I'm not having problems with other SPI devices on the board, so I'm wondering if anyone has any thoughts on what might be happening. The circuit is pretty simple with a 2.5 V reference and 5V digital in lines.

I think I am following the timing compliance. I do not have proper high frequency probes, so please ignore the coupling from having the leads attached:

The clock is in blue and the chip select is magenta. I thought perhaps something could be wrong with my clock cycles. What I'm inputting seems to be consistent but the output does update consistently.

Has anyone observed behavior like this in terms of output reliability?

Thanks,

Ian

  • Hi Ian,

    Can you share a schematic? This cross-coupling looks pretty extreme, are you confident that a digital line is not floating?

    What are you doing with the LDAC pin?

    Thanks,

    Paul

  • Hi Paul,

    I verified that digital lines (SCLK, CS, DIN) were all connected to the appropriate pins of the DAC8830, and swapped one of my testing leads for a 10M ohm one, and measured signals with reduced probe coupling as expected:

    The schematic is as follows:

    The output continues to update unreliably (a burst of repeated SPI commands seems to work, whereas spaced out repetitions seem less reliable).

    If you have any thoughts on what might be going wrong, I'd love to hear!

    Thanks,

    Ian

  • I did some further study of the datasheet, and I just wanted to remark that the issue I'm seeing resembles a DAC8831 where the LDAC pin is not being pulled properly so the output is not updating despite good SCLK/CS/SDI signal integrity. I don't know the internal differences of the chip but perhaps something is coupling to whatever triggers the equivalent LDAC mechanism in the DAC8830.

    Ian

  • Hi Ian,

    Can you provide a screen shot of the CS, SDI, SCLK and VOUT during an update? I wonder if some timing is being violated.  Can you also double check for potential assembly issues, such as weak solder joints on the VDD and GND pins? Sometimes that will cause unreliability on writes.  

    Also, it might be worthwhile to monitor the  VDD pin during these writes.  Is it possible that the output is actually latching, but some transient load is causing the supply to collapse?

    Thanks,

    Paul

  • Hi Paul,

    Thanks for your reply. I thought it may be a layout issue as well, so I obtained a DAC8831/32EVM rev. A, and unfortunately had a similar issue with the output of the chip loading.

    The VOUT remains its previous value about 14/15 times the SPI write sequence is run. The other 1/15 of the time it will update to the correct value. Here is a screenshot of the SPI signals:

    I had previously uploaded the CS and SCLK only, since I don't think the SDI would affect whether or not the chip updates.

    Here is the VDD triggered to the CS falling edge:

    I had mentioned this previous too but I've haven't yet seen significant disturbances to the rails when simply issuing my SPI commands.

    Could it be because my analog and digital grounds are shorted? Or perhaps there could be a timing issue based on the waveforms above?

    Thanks again,

  • Hi Ian,

    The timing looks okay, but the voltages look really low, about 0.5V.  Is there some strange scaling with the scope? VIH is 2.1 to 2.2V, your VHIGH should be greater than that.

    Otherwise, can you see if scaling the SPI speed as an effect? Try a very slow clock, maybe 10kHz.  If that works then I suspect some kind of routing issue.

    Thanks

    Paul.

  • Any updates?

  • Hi Paul,

    To your first remark, I mentioned in an earlier reply that I had switched to 10M leads to reduce the inductive coupling that was distorting my measured waveforms. My oscilloscope has 1M inputs, so based on this the 10x attenuation of the observed waveforms is expected. I should have just updated my attenuation setting on the scope to be 10x though, to avoid this confusion!

    Secondly, I have not had time to do a slower (kHz) clock test. The slew rate would be the same though (tied to the FPGA) so there would still be high-frequency components.

    To maybe help us isolate the issue, let me outline the hardware configuration:

    We have a motherboard with a Xilinx Spartan-6 FPGA, which uses a multi-wire connector to jump signal lines to a daughterboard, where the DAC8830 is.
    The measurements I have shown are have been taken at the connector, though I have probed the pins of the DAC8830 to verify the signals are the same there.
    I obtained a "DAC8831EVM Rev A" board, configured and attached it directly to the motherboard in place of the daughterboard, and observed the same results. (The output of the DAC seems to update about 1/15 times).


    Since the signals look good coming out of the motherboard, and both our daughtboard and the EVM are behaving the same, this made implies to me that the issue isn't due to layout. In both configurations though, the Digital and Analog grounds of the DAC are shorted, so I thought that could plausibly cause an issue.

    Let me know what you think and thanks for your advice on this!

    Ian

  • Hi Ian,

    Are the edges as clean if you measure directly at the pin? As long as the AGND and DGND are shorted and shorted with local ground of the FPGA, it should be okay.

    Thanks,
    Paul

  • Hi Paul,

    The waveforms looked the at the pins as they did the connectors. There are only very short traces between them. I can repeat this test at a later date though!

    Since the EVM behaved the same when hooked up to the same connector leads though, I don't think it's a problem with the daughterboard layout... I can repeat the test with the EVM too though, but in the meantime if you have any ideas about what could be causing both our PCB and the EVM to update unreliably, I'd be very happy to hear.

    Thanks again,

    Ian

  • As both systems have the same issue (even the EVM is intermittently updated?), then I suspect this is a timing or digital issue.  Can you confirm that all the repeated writes are the same? Can you try slowing down the SCK?

    Thank,
    Paul