Test Circuit to check if DAC is working

Question

I have a DAC that I am trying to design a circuit with. The goal of the circuit is to check whether the DAC is working or not, plain and simple.

The DAC in question is the PMI PM-7545 12-bit DAC. A link to the datasheet is below:

http://robot-and-machines-design.com/Files/Datasheets/Analog%20Devices%20Inc/PM7545GP.pdf

I can power the chip, but I'm not sure how to set up a simple circuit to check whether it is working or not. All of the tests that I read about seem to use something like a Raspberry Pi to drive the 12 inputs and read the output on a multimeter, but I don't have anything like the Pi that can drive each of the 12 inputs. What kind of simple circuit is recommended to check whether a DAC is working or not?

The datasheet of the 7545 contains a diagram of a burn-in circuit. I never heard of this term before, but from what I researched, a burn-in circuit is used to test the operation of the circuit under long periods of time to ensure functionality over time before the device fails. Looking at it, I'm unsure whether it would ensure that it is working, since the outputs are driven to ground, and the inputs are driven to high-rated voltage.

EDIT: Thanks to Glenn W9IQ for his answer. Below is my proposed testing schematic:

^{simulate this circuit – Schematic created using CircuitLab}

The inputs would vary depending on what I'm trying to get at the output, so depending on the bits, they would be at ground or 5 volts, and the switch would just be a wire that I would short to GND to enable it.

Answer 1

Yes, it is simple to test this chip. Apply the supply and the V_ref voltages. Tie the not WR line to V_CC with a 10k resistor. Now tie the DB lines to ground or V_CC to simulate the desired DAC output value. Briefly short the not WR pin to ground. The output of the DAC should now reflect the value of your DB pins in relation to V_ref.

Answer 2

Glenn already answered your question, but I'd like to share some more thoughts for those that are actually connecting a micro.

Wherever possible in my designs I always add test modes to the firmware in the code package. These modes are entered either through a dip switch or jumper setting or other predefined set of inputs that are detectible by the code.

Once in those modes the micro will execute the following kinds of routines.

For DACs, I generate an incremental writing pattern which is easily monitored via an oscilloscope as a regular saw-tooth waveform. Maximum and minimum amplitudes are easy to measure and missing or shorted bits generate an easily identifiable waveform.

For memory devices, I usually write and read to binary addresses, and data, sequentially, i.e. address 0, 1, 2, 4 etc. Triggering one channel of the scope on bit 0 it is a simple matter to view each bit offset appropriately on the second waveform.

Various other stimulation procedures can be added as appropriate with the intent that as much of the board can be exercised in a predictable and repeatable manner as possible.

The above is normally used to test the board in a stand alone configuration on the bench. You can also add a more complex mode which exercises the board while it is attached to the rest of the system to include whatever peripherals are attached.

One further test mode I always add is a "Legs-Up" mode. When selected the micro will turn all IO pins into high-impedance inputs. Once in this mode you are free to stimulate normally driven outputs with test equipment as desired without risk of damaging the micro. This mode may be especially required if the board is to be tested with a "bed-of-nails" type board tester.

You can of course make it a little smarter by using whatever feedback circuits you have available to self-test if things are working, however, if you have to add circuitry to do so, remember that added circuitry reduces the reliability of the whole thing. If it is not mission critical, for safety reasons, it's normally something to avoid.

Of course this all adds a little development time for your code, but it pays for itself in board debug time.

Answer 3

If you have a microcontroller lying around that would be a quick way to test the thing any way you want. You'd need one with enough output pins to save having to use an additional demultiplexer circuit. For instance the PIC16F1776 has enough pins (28) and onboard doodads to test lots of things both digital and analogue, and they cost only a little over £2.00 each here in the UK.

Or to go a bit more old skool you could make up a 555 clock connected to a discrete logic counter circuit (4x 4 bit counters, cascaded) circuit to run it through all the possible input values in order.