• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 46 subscribers
  • Views 660 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DAC8563 Initialziation

Singular Engineer
Prodigy 20 points
Other Parts Discussed in Thread: DAC8563

For a recent project I got to work on DAC8563. The SPI communication works well with other parts on the board (with accelerator and EEPROM  and verified with a logic analyzer).

Pin connections:

VDD = 3.3V

LDAC = GND (using the DAC in synchronous mode)

Din = SPI MOSI

SCLK = SPI SCK

SYNC = SPI CS (chip select)

CLR = GPIO pin of the uC

VREF = 3.3V

After powering up the DAC the O/P ~1.66V as expected for the part. So far good..

The DAC does not reflect the input.. If i send 0x170000 i should expect ~0V or 0x17FFFF should give me ~3.3V. But the output is either 1.6V or 3.3V.

Here are the following steps I'm doing to initialize the DAC

SPI data in 3 byte bursts (using an 8 bit controller, so...)

//---------- Initialize ------------

Disable LDAC pin: 0x30, 0x00, 0x03

Powerup DAC : 0x27, 0x00, 0x03

//--------- DAC inputs to both A and B ---------

0x17, 0x00, 0x00  ; expected 0V but actual is 3.3V

0x17, 0xFF, 0xFF ; expected 3.3V but actual 3.3V, 

and

0x1F, 0x00, 0x00  ; expected 0V but actual is 3.3V

0x1F, 0xFF, 0xFF ; expected 3.3V but actual 3.3V, 

The reason to try command and address register to  0x17 and 0x1F is because the Table 17 in the data sheet was ambiguous and so was Table 12.

I think i'm missing something in the initialization steps. I tried enabling the internal reference (of course disconnected the Vref from 3.3V) and was able to get 2.5V on the Vref pin, but no change after that. It stays at 2.5V no matter what i gave as input. 

Some help will be useful!

Thank You!

  • 0
    TI__Mastermind 46290 points

    Hello,

    It is unfortunate that you are having difficulties interfacing the DAC8563 - I'm sure we'll be able to track down the root-cause, though.

    There are several methods of updating the DAC outputs which look sort of similar so I understand there being some confusion there.

    • Binary command 000 exclusively writes to the DAC data register but does not issue a latch command to update the DAC registers. If LDAC were enabled and tied low, the data would be latched anyway.
    • Binary command 010 writes to a DAC register and updates all DAC registers. The enable status of LDAC would make no difference using this update method.
    • Binary command 011 writes to a DAC register and updates that DAC register. The enable status of LDAC would make no difference using this update method.
    • Binary command 001 acts a software LDAC. In this mode most often the hardware LDAC pin would be disabled. This register would be written to after data has been written to the DAC data register to latch the data to the output.

    I hope that clarifies things regarding the different update modes.

    Could you provide oscilloscope captures (not logic analyzer, raw waveforms please) so I can check the clock phase and polarity of your SPI bus to ensure that the host controller is providing the correct critical edge that the DAC8563 is expecing? My concern is that there may be some bit-shift occurring as a result of incorrect clock phase and/or polarity which is causing the device to misbehave. Please include SCLK, SYNC, and DIN in the oscilloscope capture.

    Additionally if you have a schematic you can share for review that would be beneficial as well to eliminate any potential hardware issues.

  • 0 in reply to Kevin Duke
    Prodigy 20 points

    Resolved!

    SPI polarity was the issue.

    Thanks!

    ~Prem

  • 0 in reply to Singular Engineer
    TI__Mastermind 46290 points
    That is great news! Let us know if you need any further assistance with your design.