Electronic – DAC multiplexer glitch

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