MSP430FR5994: ADC Internal multiplexing, trapped charge

Hi, Michael, 

Does the "updates the last channel to cause a blip in the FIRST channel" mean to cause a pulse noise on the first channel? Sorry, I couldn't understand 'blip' well. 

In the section 34.3.2 of user's guide slau367, there is a descrption

• " The ADC12_B uses the charge redistribution method. When the inputs are internally switched, the switching action may cause transients on the input signal. These transients decay and settle before causing errant conversion. " 

I think it is better to delay for a moment after switching the input channel of ADC to wait for the channel signal stable. 

Thanks, 

Lixin 

Trapped charge seems very unlikely.

First off, your diagram is incorrect. That block off three transmission gates controlled by MCTL IS the mux. The TG to ground discharges the parasitic capacitance between the other two switches.

The TI documents on their ADCs (slyt176.pdf) show that the sampling capacitor(s) are connected to ground until the sampling period starts.

In any case, your external signal source should have a low enough impedance to charge the sampling capacitance during the sampling period no matter what its initial state of charge was. So something else is going on.

Does it matter that it is the last channel in the sequence that you are changing? What happens if you alter the first? Something in the middle?

Hi Lixin, 

thanks for the reply.  

sorry i see i could have described it better. it is actually a small step change every time i switch the input

yes i seen that statement but thought if it settled quickly it would not look like a step as it would settle back after a few samples. 

Above is a live view of the data. Every minute, i change the last channel's input. 

The purple trace is the first channel showing the steps after changing the input to the last channel. 

The red trace is the second channel. The first channel should look the same, but it changes by 20~40 bits. 

Hi David, 

Thanks for the reply, i see what you're saying that makes sense, about the source driving the sampling capacitance, and if its grounded between until sampling, then does suggest its something else. 

I know the gates are the mux, and the ground switch should discharge, i was just drawing in my logbook as I was thinking it through. I didn't redo it to put the gates inside.  i have updated it slightly to hopefully help future reference. I've added a reply with a view of the data as well. 

I'll try changing a first/middle channel and see what happens.  

i have tried altering the first channel in the sequence, and confirm that there is similar problem in the 2nd channel. 

I could see that perhaps changing the last channel in the sequence might have an effect if the MCLT value was controlling the mux. But if you are seeing a problem with an earlier channel that can't be the case. It appears as though your signal sources care about the order they are sampled in.

It may be worth one more audit for more prosaic causes:

1) Are you fairly certain your sample/hold times are right? That's a pretty good way to create illusions. [Ref User Guide (SLAU367O) Sec 34.2.6.3. In a pinch, just increase SHT0/1 and see if that changes anything.]

2) Are you fairly certain there's no way you could be changing MCTL while the ADC is running? From your description, you're using CONSEQ=1, MSC=1, SHS=0, and setting ADC12SC in the DMA ISR, which should be safe enough.

I'm still not sure I understand your scope trace. Your description seems to say we're looking at 3 samples, but the scale at the bottom says we're looking at (180*8000) samples.

Thanks Bruce.  

The scope trace does show 180*8000 samples (well its actually 8192 samples, should have said 8.192kHz). The purple trace shows the first channel in the sequence.  The last channel in the sequence is not shown, but it is switched to a different input once per minute. This is causing an error in channel 1, which can be seen in the trace every 60 seconds. The red trace shows 2nd channel, which is not affected. Ignore the orange trace. 

1 - i have a passive rc anti-alias of 10k - 4.7nF.  The 4.7nF should be low enough impedance and i have set the sample time to 4cy (0.75us worst case adc clock).  Because of the t switch I thought this would just be a gain error and not cause any cross channel problem.  It has given the expected performance in gain and frequency up until i added this 'aux' channel stuff. 

Don’t know if relevant but i've set up so that the main channels end on mem7, and the aux channel is on mem8, so that I can also change the sample time of the aux channel depending on what input it is (SHT1), and keep the main channels as they are (SHT0).

• mem slot 1~7: main channels, all with 10k/4n7 rc,  1us typ sampling time
• mem slot 8: aux channel, different inputs / impedance, varying sample time.

I have tried increasing the main channels to 16 cycle and the plot looks exactly the same.  i also tried without changing the aux channel sample time (sht1 always 4cycle), and no change. 

2 - Yep, almost except the adc sequence is triggered by a timer at 8192Hz instead of setting ADC12SC (SHS=4). The way its managed is slightly complicated, so it might be something to do with it:   

Once sequence is done the adc EOS triggers a dma channel to transfer results transfer, and another dma channel to toggle ENC off then on. 

After 16 of these sequences the dma triggers an interrupt to wake cpu and process results. The first line in the dma isr checks if its time to change the aux channel. If so it turns ENC off, so it can change MCTL8 (aux channel), then turns it on. so in that respect im not changing MCTL while running. 

With ref to the Sequence-of-Channels Mode state machine in UG Fig 34-9: 

At the end of a sequence, EOS.x = 1 - goes back to 'wait for enable'. the dma is also triggered which turns enc off, then on (uses a 2 element array written to ADCTL0). This pushes it into 'wait for trigger'. if dma has completed (block size 16), it triggers an interrupt. This processes the data (16 sequences). 

If its time to switch the aux channel to a different input (flag set every minute), the ISR turns ENC off (back to 'wait for enable') updates MCTL8, then turns end on ('wait for trigger').  if all this happens before the next timer trigger (minus latencies, settling etc) then it should be ok (i think!?)

Had checked and thought all this should happen with enough margin (pic below is exaggerated) before 122us when a new adc sequence is triggered.

But, maybe Lixin's point about letting the adc settle after switching input channel is related? ie the bottom line on the pic below shows the mux being touched closer to the next trigger - what is the settling time on those transients? 

Whats strange is that its a step change, and doesn't just cause a small blip in the first few samples after switching. 

The reason for all this is that its very power critical, and found there is a problem in the adc, in that it doesn't power down in 'wait for enable' state, until after enc is turned off then on again. using the dma for transfer, and for enc~toggle, means the cpu only needs to wake up after every 16th sequence, and the adc is powered down between samples. 

Don't know if its a flaw in the design or the adc has to be this way, but i would be great if the ADC would auto power down after end of a sequence automatically in this mode. 

Hi, Michael, 

Sorry for the late reply.

I calculated the sampling time needed for your ADC input circuit 10k+4.7nF following the formula in the section 34.2.6.3 of slau367. It is about 641us (Checked the MSP430FR5994 datasheet, the Ri = 4k, Ci = 15pF). So the sampling time you set in the code is incorrect. (It seems you use MODCLK as ADCCLK.)

Could you try to decrease the 4.7nF to 100pF or less and set the SHT1 to 0011b (32 ADC12CLK cycles) (10k+100pF will request about 15.6us sampling time)? 

If the test result shows the same blip in the first channel when channel 8 switches to new input, please help to delay some time (100us or 200us) for the trigger of ADC starting conversion to let the switch getting stable. Please add the delay after setting ENC=1. It is supposed the switch should be fast. My idea is to check the if it is because of the switch to cause the noise. 

Thanks, 

Lixin