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.

DAC7716 SPI Problem

Other Parts Discussed in Thread: DAC7716

Hi,

I am investigating a problem which we have using the DAC7716. The problem we see is, that controlling the DAC depends on the capacitive load on the MOSI line. As the signal integrity of all lines is very good (verified with a 6GHz scope and 1Ghz active probes), this indicates very much that the timing of the SPI bus is the problem. The SPI is clocked with 10MHz, so there should be no speed issue. 

A slight capacitive load (10pF) on the MOSI line makes the device work. This indicates that the data line needs some additional delay. In order to verify what the device internal SPI registers "see" I observed the MISO output of the DAC. This does reflect the input data shifted by one access (i.e. 24 bits/ 1 chip select cycle) later.

Now here comes the interesting part. The MISO does reflect the input data well with the capacitive load, but is shifted "forward" by one bit without the load. This would indicate that the MOSI line is sampled just around the time where the MOSI line changes. If we delay a little, it gets the right bit, if we don't delay it is one bit early. Now, the datasheet says that the device samples at the falling edge, but I see this behaviour at the rising edge!!! 

To sum up, a day's worth of measurements indicate that MOSI is sampled at the rising edge of SPI CLK, not at the falling edge as the datasheet says.

Could that be the case?

There is one additional thing you should know: We don't quite keep the power sequence which is described - we start up with the digital supplys, then with the positive analogue supply, followed by the negative analogue supply (the datasheet says we should start up the negative analogue supply before the positive one). However, I would be surprised if this would influence the devices SPI logic side.

I would appreciate a quick answer!

  • Update - I tried start the device with a corrected power sequence to be able to tick this one off the list of possible causes. The behaviour is not different with the corrected power sequence.
  • Alexander,

    Could you share an oscilloscope capture of the SPI bus for me to look at?
  • Hi,

    I was out of office for a few days, so it took some time to get the pictures. I only got an old scope from the lab - so I did a screenshot like back in the old days - this time though using a Smartphone and not a Polaroid.

    Channel 1: Clock
    Channel 2: MOSI
    Channel 3: CS
    Channel 4: MISO

    Channel A=zoom of 1
    Channel B=zoom of 2
    Channel C=zoom of 3
    Channel D=zoom of 4

    I had to swap the device under test as well as the test equipment. The effect is less pronounced in  this DUT but still there.

    The first picture shows the correctly working SPI bus. The lower half contains Clock and MOSI zoomed to be able to observe the timing. There is one flaw in the whole timing which I am aware of, but that should not be the cause of our problems: the first rising edge of clk is practically at the same time as the falling edge of CS. I'll get a fixed FPGA on Monday where I can make sure I can rule out that this caused the problem. I do not think that this is the problem, because I cannot relate the effect we see in the second picture to double clocking at the beginning of the access. The second picture  zooms the CS and CLK timing (but this is not the main thing I want to show in the second picuture.)

    The second picture shows the non-working SPI bus. The difference is that I removed the active probe from the MOSI line. That's why you don't see MOSI in this picture. On this DUT, just the timing difference by the 0.9pF probe makes it work so I cannot show it. The second bus shows, that the SPI chain clocks two "highs" instead of one. I.e. it samples wrongly. The only explanation I can think of, is that the SPI bus actually samples and clocks the SPI registers at the rising edge of the clock line. It would explain all symptoms. A double clocking at the start could not explain why the SPI chain see's two high bits instead of one. It would explain a shift by one bit. BTW: if I distort the timing of CS to force double clocking, the sensitivity to delay on data is the same, but only the result is shifted by one bit. 

    So please could you inquire if my assumption is right or help me finding a different explanation to what I am seeing...

    best regards

     Alex

  • Alex,

    Give me some time to get a bench setup for this for a first-order investigation. I will update this thread when I have those results - most likely by COB on Monday.
  • Alex,

    I have my test bench set up, but I have no units on hand and unfortunately my sample units have not arrived yet. Theoretically (hopefully) they will arrive tomorrow and I will be able to test this here.

    I will update this thread once I have tested units.
  • Alex,

    Thank you for your patience as we waited for sample units to arrive.

    I received units this morning and began testing. My test is a simple first-order test - I am repeatedly writing full-scale data to the DAC and watching for the output to respond. In the capture below, you will see clock polarity 0 and clock phase 1 - so data is settled/clocked on the falling edge.

    In this case you can see that the DAC output, the green channel, has risen to full-scale and responded to the full-scale write command. In the next capture I set polarity 0 and phase 0, so data is settled/clocked on the rising edge. 

    In this case channel 1 does not respond by rising to full-scale because the address word is incorrect for communicating with channel 0.

    These test results conclude that the device indeed samples on the falling edge as is indicated in the datasheet. It seems unlikely that this is a unit-to-unit or lot-to-lot variation, though you did mention that the current unit behaves a bit differently than the unit you initially observed. If you can remove one of the worse units from your board and send it to me, I would be happy to run tests here myself as well.

    Are you probing the bus near the device? Could it be possible that there are other parastic delay sources skewing what the DAC actually sees?