Post Go back to editing

No discernible output at Iout

Thread Summary

The user is troubleshooting an AD9102 DAC that shows no discernible output signal. The issue was resolved, but specific details of the solution are not provided. The setup includes a PIC18F4455 microcontroller as the SPI master, with the DAC configured using various registers for SPI, power, clock, and DAC settings. Key connections include SDO, SDI, SCK, Trigger, Reset, CS, and clock lines, with IOUTP and IOUTN connected to ground via 500 ohm resistors.
AI Generated Content

To preface this, I have the AD9102 chip itself, not an evaluation board package.

When I measure at the output, I'm not seeing any discernible signal.

I tried using several different references from questions asked here (AD9106 Minimum Hardware Set and https://ez.analog.com/thread/35554#120890)), but I'm not seeing any changes in my output.

I have set up my system with PIC18F4455 as the SPI master. I am electing to use software SPI for unrelated reasons, and have verified that my SPI clock is being sent from the uC, as well as the data lines in and out.

At the connections of the DDS:

  • uC to DDS connections
    • My SDO on the uC is being fed to the SDIO pin
    • My SDI on the uC is being fed to the SDO pin
    • SCK to SCK
    • Trigger sent to Trigger
    • Reset sent to Reset
    • CS sent to CS
  • Clock connections (20 MHz clock)
    • Single-ended clock output to CLKP
    • CLKN is connected to ground via 0.1uF cap
    • CLKVDD connected to my voltage
    • CLKGND grounded
  • Other connections
    • IOUTP is connected to ground via 500 ohm resistor
    • IOUTN is connected to ground via 500 ohm resistor

The program that I'm using follows this order:

     output_high(CS); 
   output_high(Trigger);
   output_high(Reset);
   
   // SPICONFIG
   addr[0] = 0x0000;
   val[0] = 0x0000; 
   
   // POWERCONFIG
   addr[1] = 0x0001;
   val[1] = 0x0000;
   
   // CLOCKCONFIG
   addr[2] = 0x0002;
   val[2] = 0x0000;
   
   // DDS_TW32
   addr[3] = 0x003E;
   val[3] = 0xFFFF;
   
   // DDS_TW1
   addr[4] = 0x003F;
   val[4] = 0xFF00;
   
   // DACAGAIN
   //addr[5] = 0x0007;
   //val[5] = 0x0400;
   
   // DAC_DGAIN
   addr[5] = 0x0035;
   val[5] = 0x0400;
   
   // DACDOF
   addr[6] = 0x0025;
   val[6] = 0x0000;
   
   // DAC_CST
   addr[7] = 0x0031;
   val[7] = 0xFF00;
   
   // DACRSET
   addr[8] = 0x000C;
   val[8] = 0x801A; 
   
   // WAV_CONFIG
   addr[9] = 0x0027;
   val[9] = 0x0001; //0x0031;
   
   // PAT_TYPE
   addr[10] = 0x001F;
   val[10] = 0x0000;
   
   // RAMUPDATE
   addr[11] = 0x001D;
   val[11] = 0x0001;
   
   // PAT_STATUS
   addr[12] = 0x001E;
   val[12] = 0x0001;

   // RAMUPDATE
   addr[13] = 0x001D;
   val[13] = 0x0001;

The handling goes something like this:

      for(i=0; i< 14; i++)
      {
      
         output_low(CS);
         
         spi_xfer(addr[i]);
         spi_xfer(val[i]);

         output_high(CS); 
      
      }
     
      output_low(Trigger);

Am I missing a register operation somewhere? Or is it more likely that I have a mis-configured connection somewhere?

  • Through another forum, and in-person teamwork with my group, we have figured out our issues.

    As a reference to anybody else who has problems with configuring this chip to work, I'm going to write out what we did to generate a basic sine wave (note that this is not a perfect sine wave, but it should be a starting point).

    Note: This is for the chip itself, and not for the evaluation kit.

    Hardware connections:

    1. Connect voltage and ground pins appropriately. (I recommend using 3.3V, but it does work with 1.8V with modifications)
    2. Connect SPI pins
      • [uC] SCK -> [DDS] SCK
      • [uC] SDI -> [DDS] SDO
      • [uC] SDO -> [DDS] SDI
    3. Determine the following pins on your uC. (Assign them to a GPIO pin)
      • Trigger
      • Reset
      • CS
    4. Connect the pins to the appropriate pins on the DDS.
    5. Connect your clock source
      • Single-ended clocks can work, but aren't as clean as can be. Simply AC-couple CLKN with a 0.1uF capacitor to ground.

        For a basic uC program, include necessary files to compile, initialize SPI, and send a 32-bit word via SPI to your DDS. To verify that it's being programmed correctly, send two commands: one to write and one to read. The difference in the words will be the first bit, which is the read/write bit.

     

        A sample of how a basic program might look (written for 4-wire mode):

       unsigned int32 fullWrite = 0x003FFF00;
       unsigned int32 fullRead = 0x803F0000;
    
       output_high(CS);
       output_high(Trigger);
       output_high(Reset);
    
          while(TRUE)
          {
             output_low(CS);
              spi_xfer(SPI,fullWrite,32);
              spi_xfer(SPI,fullRead,32);
             output_high(CS);
                   
             delay_us(50);
        
          }
    

         If readily-available, you can use an oscilloscope with digital channels to measure your inputs. You should see the register data being sent back. (Note that I'm not processing the data in the uC, but on the oscilloscope.) Otherwise, you can connect additional peripherals such as UART or LCD display to verify the data.

         The above will not guarantee a waveform, since you need to program all registers.

         Some defaults to get you started:

    Register Name
    Address
    Value
    SPICONFIG 0x0000 0x0000
    POWERCONFIG 0x0001 0x0000
    CLOCKCONFIG 0x0002 0x0000
    DDS_TW32 0x003E [any val]
    DDS_TW1 0x003F [any val >= 0x0100]
    DAC_DGAIN 0x0035 0x0400 [supposedly is a gain of 1]
    DACDOF 0x0025 0x0000
    WAV_CONFIG 0x0027 0x0031
    PAT_TYPE 0x001F 0x0000
    RAMUPDATE 0x001D 0x0001
    PAT_STATUS 0x001E 0x0001

    Before you program, and assuming your connections above have been made, make sure you attach a resistor from the FSADJ pin to ground. In my case, we attached a 1k ohm resistor.

    Assuming you did the above, there should be a sinusoidal wave being output. through IOUTP and IOUTN.