Post Go back to editing

AD5760 Default Register Values

Category: Datasheet/Specs
Product Number: AD5760
Software Version: N/A

I have a board with a number of AD5760s. I am having a problem where the output voltage is not matching the DAC value I am setting. As part of the diagnosis process I am reading back the registers after reset.

I am reading 0x80000 as the 20-bit value for reg 1 (the DAC register) as expected. However register 2 (the control register) is consistently reading 0x00006. From the datasheet I would expect to see 0x0000E, because RBUF, OPGND and DACTRI all default to 1. This is the case whether I reset the device with a hard power-cycle, hardware reset line or soft reset via register 4. Subsequent write and reads return the expected values so the SPI interface is behaving reliably.

Please can you confirm that I would expect to see a value of 0x0000E in the control register after reset.

Thanks

Parents
  • Hi  , 

    The expected readback on the control register is indeed 0x0000E. Tha main issue you're having is with inconsistent voltage output and DAC code right? Could you send a scope shot of one SPI transaction with SDIN, SCLK and SDO? How far apart is the actual voltage at the output with respect to the code, is there a pattern offset or vastly different values observed? If you could also share your schematic and we can get a quick look into it, that would be great. 

    Best regards,

    Ian

  • Hi Ian,

    The primary issue is indeed the output voltage, however I am working through the other issues. The AD5760 has a Vref = +/-12V, but I cannot get a negative voltage from it. A full-scale negative value gives me 6V and a positive value saturates at 11V from 0x60000 (twos-complement) upwards. If I select OPGND then I get 1.7V and DACTRI gives me 10.5V. The DAC is followed by an LM7171 in the unity gain/bias current compensation configuration. I have just tried replacing that with an ADA4898-1 just to match the data sheet as closely as possible which made no difference.

    At the moment I have traces of the signals from the FPGA end but do not have good tests points at the DAC end. Probing pairs of lines has given me confidence in the timing of the SPI. It is worth noting that the behaviour is consistent between multiple chips on the same board. I can do tests where set the same voltage using twos-complement or offset binary form and get the same result. I can also read back the DAC values reliably. I am therefore happy with the digital interface.

    I am going to remove one of the output amplifiers removed so I can probe the output pin without any other circuitry. I am also investigating whether the Vref lines are being powered before Vdd/Vss and the devices have been damaged. I will try to get a trace of the SPI lines while I am at it.

    Meanwhile, please could you clarify the absolute maximum rating table, where VOUT to AGND is rated as −0.3 V to VDD + 0.3 V.

    Thanks,

    Phil

  • Hi Ian,

    Please see attached the captures of the SPI bus reading the DAC register and the control register immediately after a reset.

    Control register read:

    DAC register read:

    Start of transaction:

    End of transaction

    The captures are made from some quite long probe wires so are not perfect but the timing seems okay. The signals are driven from a 100MHz clock in the FPGA so 10ns is the granularity of pretty much everything. The clock is stretched 9:1 during configuration (and hence for readback) and is 2:1 when writing DAC values continuous. At present I am seeing the same output level issue in both modes.

    With the output buffer chip removed I see the same voltage levels as before. From the PCB design I can see there is no protection to ensure that Vdd/ss are stable before Vrefp/n are. The rails are both generated on another board and then regulated down via LDOs on this board. I cannot therefore say with confidence that the Vref has not exceeded Vdd/ss, however it is not likely to have been sustained.

    I am not able to share the schematic at the moment, but around the AD5760 output itself it does follow the design in the data sheet.

    Thanks,

    Phil

  • 0
    •  Analog Employees 
    •  Super User 
    in reply to PM1013

    Hi Phil, 

    Thanks for the scope shots. The SDIN, SCLK timings seem ok but could you check this one? This is supposed to be t6 from the datashet, minimum sync high time in between transactions (min. 40ns). Couldn't see clearly from your scope shots. Do you have access to the FPGA code? I was hoping we could try and change the pulse width for the sync high time (40ns++) to see if the issue still happens.

    For normal operation of the DAC, OPGND and DACTRI should be set to 0, the rest of control register bits could be left default. Is this the configuration of your dac?

    Best regards,

    Ian

  • Hi Ian,

    Good spot. I have (over-)corrected the SYNC timing to 100ns.

    Sadly it hasn't changed the result. I have also just confirmed that I can set the configuration register to 0x0000E and read it back successfully during my configuration phase.

    With respect to the other problem regarding the output DAC values. Here are some captures when the firmware is free-running and writing samples at 1MHz.

    In normal operation OPGND and DACTRI are set to 0. The amp configuration is as you show with the one oddity that the LM7171 at the output is driven from the same supply that drives Vrefp/n.

    Thanks,

    Phil

  • Hi Phil, 

    We did some test in the lab using the eval board and we are getting the same result for readback on the control register. I think this should be fine since the state of OPGND supersedes the state of DACTRI during powerup. meaning, since OPGND is set to 1 (clamped to gnd, output is tristated), it doesn't matter what state DACTRI is. 

    Are you still getting problems with getting the output voltage setup? could you share your commands sequence sent to the device thru SPI. 

    The amp configuration is as you show with the one oddity that the LM7171 at the output is driven from the same supply that drives Vrefp/n.

    this setup should be fine, but you might have issues with outputs close to rail as the opamps tend to have a few mV of headroom needed. 

    Best regards,

    Ian

  • Hi Ian,

    Thanks for that confirmation - I had concluded that the data sheet must be wrong because what I was seeingon the scope matched what was coming out of my firmware. Presumably that will be updated in the next version of the datasheet. I presume it will impact the other similar devices like the AD5780, AD5790 etc.

    I have reduced the command sequence down to programming the control register (0x00002) and writing a value to the DAC register and still get the wrong voltage outputs.

    I am going to try replacing one of the mis-behaving devices with a "fresh" device from the thermal profiling board. Unfortunately I cannot find any brand new devices in stock anywhere so this is my best option. I will put in place a fix for issue I have regarding the Vrefp/n inputs preceeding the Vdd/ss supplies and see if I get the same behaviour.

    I will capture the command sequence when I do this test and report back, although it may not be until next week now.

    Regards,

    Phil

Reply
  • Hi Ian,

    Thanks for that confirmation - I had concluded that the data sheet must be wrong because what I was seeingon the scope matched what was coming out of my firmware. Presumably that will be updated in the next version of the datasheet. I presume it will impact the other similar devices like the AD5780, AD5790 etc.

    I have reduced the command sequence down to programming the control register (0x00002) and writing a value to the DAC register and still get the wrong voltage outputs.

    I am going to try replacing one of the mis-behaving devices with a "fresh" device from the thermal profiling board. Unfortunately I cannot find any brand new devices in stock anywhere so this is my best option. I will put in place a fix for issue I have regarding the Vrefp/n inputs preceeding the Vdd/ss supplies and see if I get the same behaviour.

    I will capture the command sequence when I do this test and report back, although it may not be until next week now.

    Regards,

    Phil

Children
  • HI Ian,

    Just to close this one off, we have managed to put down a "fresh" AD5760 from the thermal profiling board and used resistors to set Vrefp/n to provide some control over the sequencing. This works correctly, as per the slope that I can generate below. It is not going to be a long term solution as the references will now be relatively noisy.

    My assumption is that the devices on the board have been damaged by the power sequencing which may bring up Vrefp/n before Vdd/ss.

    The issue regarding the initialisation register values seems to be a red herring and the data sheet is incorrect.

    Thanks for your help,

    Phil