DAC multiplexer glitch

Question

UPDATE 20th May:

Swapped the analog output regulator for an AZ1117-EH based on Peter Smith's suggestion, removed C1306, so now the 3.3VA output should be ok at least based on the datasheet. However, no significant improvement. See scope shots and discussion under the section market NEW MAY 20TH.

UPDATE 18th May:

More scope shots below, which do seem to be telling a story. See discussion marked NEW.

UPDATE: tried adding resistors to the DAC output which had some effect, see below.

EDIT: tested the dielectric absorption theory: not the culprit (see below).

I'm multiplexing a 4 channel 16 -bit DAC to 21 output channels via DG4052 multiplexers (exact part numbers and links to the datasheets below). There's a 10nF hold capacitor after the multiplexer, with the output going to the + -input of a TL074 opamp.

The relevant part of the multiplexer schematic:

updated and the DAC output schematic (though note below about adding a resistor in series):

The DACn channels come directly from the DAC outputs (but see below for a test with a resistor in between), and are in the range 0..3.3V. Update rate is 3kHz, and the charge time is about \$\mathrm{40\mu s}\$

The problem: The output of a channel, take for example VExpMCU, glitches by about 1.2mV when the enable toggles, and the address of the corresponding channel is selected. In the picture, the yellow trace is VExpMcu, AC coupled, and the blue trace is the MUX enable (which is inverting). The output value is held constant, so the ideal result would be a flat horizontal line:

As a test, I added a 270\$\Omega\$ resistor between the DAC1 output and the MUX input. The result was that the glitch level about halved, but the initial transient is still about the same as before. Note the different time scale, and also the cursors showing that the step is now smaller, at about 660\$\mathrm{\mu V}\$:

Interestingly, increasing the resistor to \$1\mathrm{k\Omega}\$ (sorry about the really bad picture here, vertical scale is 1mV/div) about further halved the step, but the initial glitch size remains about the same, with a much longer settling time. This suggests it may nonetheless be something similar to what Andy aka suggested, but there's still a downward step when the enable turns off, which means that somehow the hold cap immediately loses some charge:

NEW on May 18th: Setting all the channels to the same output value (so the DAC output would ideally be constant, and it's easy to scope slight glitches there) gives the following scope shot, yellow is enable (active low), blue is directly the DAC output:

The big glitch happens while enable is off, so it's irrelevant here. However, there seems to be something on the rising/falling edges. Zooming in on the glitches near the enable signal edges:

Then a scope shot of the power supply, yellow is still enable, blue is now the 3.3V analog power (AC coupled) measured at C1407:

which seems to tell us everything: the analog supply sags when the enable toggles, causing the DAC output to glitch, which causes the glitch in the mux output. However, one more scope shot throws a wrench in the works: triggering the scope from the DAC output glitch (the big one that happens while the enable is off) gives the following (Blue is DAC output, yellow is 3.3V analog at C1407):

Note the absence of the supply glitch. Basically, the scope shots of the 3.3V line are inconsistent, so one of them is wrong. So now I'm thoroughly confused.

So how do I check if the problem in the supply is real or a scope artifact? If it's real, how to fix it? There's over 50\$\mathrm{\mu F}\$ of capacitors on the power rail, so just throwing more won't help unless it's a lot more. Here's the power section of the board, in case that tells us something (EDIT: regulator has since been swapped):

NEW MAY 20TH:

Swapped the analog regulator for an AZ1117-EH, which shouldn't have problems with the 100n caps (removed C1306 which was too close, though). The glitch on the supply still persists, it's now actually a bit bigger though more symmetric:

As before, when triggering on the DAC the glitch on the supply line is not present, so that mystery still persists. It's also not on any other power rail when triggering from the DAC. However, it's there on all of them when triggering from the enable signal, for example this time with the yellow trace being +12V at the input to the analog 3.3V regulator:

This is making me think that the glitch on the power rail may be an artifact of my scope grounding, somehow leaking from the neighbouring channel when I'm triggering on the enable (I also tried to use channels 1 and 4 on the scope, just in case, no difference). However, it's always there on the DAC output, so that's probably real.

So what now?

EDIT: Here's the list of potential sources for glitches which I originally considered, most of these appear somewhat irrelevant now in light of the new pictures:

1. mishaps in the timing code, i.e. DAC not having settled, address being selected after the enable, etc etc. However, I believe I've squashed such bugs from the firmware now (there were indeed a few). Also, one would expect those to produce a glitch in the beginning or end of the update cycle, whereas this seems to be a square-like shape for the duration of the enable pulse (although it's hard to be 100% certain since we're at the limits of my modest scope). Anyway, I'm happy to provide scope shots of the address/enable/DAC output signals if you have a hunch it might be something related to that.

2. Charge injection from the mux. However, from the datasheet, the maximum charge injection is... uh... missing from the datasheet in the 12V case, but taking the worst of the cases there is, 0.38pC, which to a 10nF capacitor gives \$0.38\mathrm{pC} / 10 \mathrm{nF} = 38\mathrm{\mu V}\$ change, so about 30 times less. Update tried doubling the cap, as suggested by WhatRoughBeast. No change, so it's definitely not charge injection.

3. stray capacitance storing charge somewhere: if there'd be a stray capacitance of about \$1\mathrm{mV} / 3.3V 10 \mathrm{nF} \approx 30 \mathrm{pF}\$, then charge sharing could cause such a glitch (for a full scale voltage difference). However, \$30\mathrm{pF}\$ seems a bit big for stray capacitance here (although admittedly the biggest capacitances mentioned in the datasheet are about 10pF, so not that far off), and besides it's difficult to understand how it would cause the square-like shape, instead of the DAC output buffer correcting it after an initial glitch? Edit with the newer picture with the resistor, the squareness of the shape isn't quite that obvious anymore, but then it's difficult to see how increasing the resistance between the DAC and the mux would reduce the error if it's due to stray capacitance.

4. Stray coupling from the address/enable signals: the glitch only happens when that specific channels enable toggles, if it we're parasitic coupling I'd expect to see constant glitches at the enable rate.

5. Capacitor dielectric absorption (DA): I swapped the original X7R cap (specifically a TDK C1608X7R2A103K080AA) for a 10 nF C0G -capacitor (GRM1885C1H103JA01D) in the channel in question, which should have less DA, with no difference in the signal. So I think we can rule out DA.

6. as suggested by Andy aka: the DAC output buffer could be nearly unstable (the datasheet guarantees stability only up to 0.2nF for 0 ohm series resistance, up to 15\$\mathrm{\mu F}\$ for 500 ohms). To test this, I tried decreasing the update rate to 1kHz, which I'd expect to exaggerate the glitch, and potentially see the glitch starting to settle during the longer charge time. However, the glitch size remains exactly the same, and it still appears square-like, without showing signs of settling during the charge time (which has now increased to about 125\$\mathrm{\mu S}\$) Edit: however, see the new scope shots above:

Update: also tried to add a 10k resistor from DAC output to ground, as suggested by PeterSmith. No change.

Summary this far: the only change that has had an effect was adding a series resistor after the DAC. Interestingly, doubling the hold cap had no effect either, which means that the step at the end of the charge period is not a fixed amount of charge being drawn from the hold cap, but a fixed voltage step. However, the glitch seems to be present already at the DAC output, and there's something fishy about the power rails, see discussion above.

The promised part numbers and datasheets (don't hesitate to ask for more info, if you need):

• DAC: Maxim MAX5134AGTG+, Datasheet
• MUX: Vishay DG4052E, Datasheet
• OpAmp: TI TL074, Datasheet
• hold cap: TDK C1608X7R2A103K080AA, Datasheet
• Analog regulator: replaced an LM1117 with an AZ1117-EH

Answer 1

The problem could well be at the 3.3V regulators:

I have circled the output capacitors; the LM1117 datasheet states:

8.2.2.1.3 Output Capacitor

The output capacitor is critical in maintaining regulator stability, and must meet the required conditions for both minimum amount of capacitance and equivalent series resistance (ESR). The minimum output capacitance required by the LM1117 is 10 μF, if a tantalum capacitor is used. Any increase of the output capacitance will merely improve the loop stability and transient response. The ESR of the output capacitor should range between 0.3 Ω to 22 Ω. In the case of the adjustable regulator, when the CADJ is used, a larger output capacitance (22-μF tantalum) is required.

A ceramic capacitor will very probably be below this minimum value and the actual minimum value depends on load and input voltage which will vary across those conditions. A load step (which does not need to be very much) can cause instability at the output which would explain a great deal.

In addition to that, the output capacitance of the 3.3V digital rail does not appear to be sufficient (10\$\mu\$F minimum).

Whether you actually see that instability is going to depend on many things and even attaching a scope probe to the power rail will change those conditions, so it may do one thing without the probe and something different when you do probe the power rail.

[Update]

The usual way of dealing with this sort of issue is to either use a standard tantalum (not the low esr series) which typically have an esr in the required range (although there are other problems with tantalums) or to use a ceramic in series with a low value resistor on the output.

Where there are low esr local decouplers, they can sometimes be isolated by using a small inductor or ferrite on the output (we are trying to prevent instability caused by transients). If the devices are far enough away such that track inductance effectively isolates them from the output of the regulator then that may not be required.

Sometimes, low esr local decouplers simply cannot be used (I have had this specific problem in the past) and the output capacitance on the regulator has to be relied upon for transient response.

The output ESR issue for older LDO devices is well known and many newer parts do not have this problem.

Answer 2

There's a 10nF hold capacitor after the multiplexer

Another possible source might be made worse by a slow refresh time. For instance, the input bias current for the TL074 could be around 1 nA and using the capacitor equation below: -

$$I = C\frac{dv}{dt}$$

We find that the rate of change of voltage on the 10 nF capacitor is 100 mV per second.

So, if your refresh time is 1 kHz, you might see 1 mV ripple on the storage capacitor feeding the TL074 input. If your refresh time is 10 ms then you'll see 10 mV of ripple.

I'm not saying this is the culprit of course but, it's something to look into.

The DG4052 has an "off" leakage current of typically up to 1 nA and this may make the issue doubly worse.

There's also the problem of maximum capacitive load as specified in the data sheet: -

With 10 nF connected the internal DAC buffer amp may actually be going a little unstable with 10 nF connected.

Answer 3

I suggest you look into charge injection. The edges of the hold signal are capacitively coupled to the output, resulting in a step change in the output when feeding a cap.

The quick test is to change the value of the buffer cap, and see what happens to your step size. If it's charge injection, a smaller cap will give a larger step, and vice-versa.