AnsweredAssumed Answered

No discernible output at Iout

Question asked by Ryan-G on Apr 9, 2016
Latest reply on Apr 15, 2016 by Ryan-G

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?

Outcomes