EK-TM4C1294XL: AIN16 leakage volts

Hi BP101,
Everything you mention on the custom board, can you replicate on the LP?

Hi Charles,

Yes issue effect EKXL/EVM exactly the same. Looks like the higher MUX channels 19:16 are overlapping the lower sequencer step 0. Overlap effects the amplitude of the analog signal even with DMM probe being placed on AIN17. Typical  750uV with 10k to ground on all SS2 channels (below )gets dragged down to 50uV on CH17 only. Appears to be Tivaware MUX configuration error for step 0 when ADCSSEMUX bit is being set for 19:16 channels.

BP101,
Do I understand correctly that you have four ADC channels each connected to ground through a 10K resistor?

I can think of three sources of an offset voltage with that high of a source impedance (in this case, your source is ground). The first is the leakage current. It can be as high as 2.0uA, but can be as low as zero. That means the voltage created across the 10K resistor can be from 20mV to zero volts. If some channels have leakage that create 750uV and another channel the leakage creates 50uV, they are all within specification. (With a 3.3V reference, the 12 bit ADC cannot resolve a difference between 50uV and 750uV.)

The second source would be charge sharing with the sample capacitor. If you have a high source impedance (such as 10K) and a small source capacitance (maybe just the 2pF for the pin), the change on the sample capacitor from a previous conversion will affect the next conversion. The solutions here are to use lower source impedance, larger source capacitance and/or longer sample time.

The third source is coupled noise. If the source impedance is high and there are switching currents nearby, a voltage will be induced in the loop created by the analog input and ground by the magnetic field of the switching current. Isolating A to D inputs from switching currents and reducing loop areas with ground planes and twisted wires will help.

I am not sure what applies to your circuit as you were not specific enough about the circuit you tested.

It Would seem ADCSSEMUX being set to 0x1 in order to select MUX channels (19:16) is being ignored. Thus SSMUX2 AND's 0xF00 >> 8 any bits of MUX0-3 to form the AINx channel decodes. So PIN_IPHASEA (0x101) after AND right shift 8 = 0x001, any sequencer steps CH19:16. In this case directly over top of CH1 makes a fine short circuit in the analog MUX.

May explain why AIN16 (PK0) custom PCB with LM94022 temp sensor starts rolling with AD0 SS2 input of step 0 AIN1=0x1. Anytime PIN_PHASEA has signal it disturbs ADC1 SS1 when CH16 or MUX0 = 0x1, when likely it should be configured as 0x100. Explains how Input current flow from CH1 into CH16 of analog MUX eventually caused an LM94022 to short output, 2K9 to ground. Sensor data from CH16 still rolls seemingly with activity from CH1 after replacing the sensor.

That is the only logical explanation for why the INA240 output signal can not be properly acquisitioned by SAR of TM4C1294. We never could get a correct analog voltage and had to make the software compensate for incorrect hardware configuration.

HI Bob,

The point EKXL/EVM the ADCSSEMUX channels (19:16) are somehow overlapping CH1 of ADC1 SS1 step 0 and ADC0 SS1 step 0 sequencers configuration in the analog MUX. No matter that ADCSSEMUX bit is being set to select (19:16), all channel decodes are being right shifted. This is not cross talk in the EK/EVM it current flow result of pin configuration overlapping in the analog MUX.

Either the right shift of the ADCMUXn channel bits for ADC0/1 channels (19:16) is correct or is not! If it is correct then ASCSSEMUXn bits are being ignored and an overlap occurs in AINx pin configurations in the analog MUX (19:16) and (3:0).

It is not by any means correct behavior for an analog input voltage to drop further than the 10K pull down, let alone the INA240 output being similarly tested EKXL/EVM doing the exact same to only AIN16 or AIN17 being tested. Simply placing 30 MEGOHM DMM probe measuring millivolts on AINx partner pins of SS1 or SS2 with same 10K pull down does not effect the voltage but only on AIN16 (PK0) or AIN17 (PK1), so far AIN1 of opposing step 0 of ADC1 SS1 is overlapping in the analog MUX.

I disagree with your conclusion. I created a simple project that converts AIN1 and AIN17. On the EK-TM4C1294XL launchpad, I connect AIN1 to 3.3V and AIN17 to GND. If what you suggested were true, the pins would be shorted through the multiplexer and return the same value. My results are what I expected, the two channels are separate. I repeated the experiment putting AIN1 to GND and AIN17 to 3.3V. The example project is attached.

/cfs-file/__key/communityserver-discussions-components-files/908/ADCtwoChannel.zip

Bob Crosby said:

. My results are what I expected, the two channels are separate. I repeated the experiment putting AIN1 to GND and AIN17 to 3.3V. The example project is attached.

Perhaps your misunderstanding the conditions that exist are not full on and off voltage related. The 3v2 102Hz signal revealed more is going on than simple on off conditions of CH16 being interfered from some other channel data.

They are over lapping in a sense in the MUX that does not mean are directly shorted though it seems like a short between these channels in the ADCSSMUX. Specifically talking about periodic signals, bleeding into CH16 via the FIFO step 0 data via the ADCSSEMUX channel signals (19:16). Oddly CH16 (excessive) MSB gain goes away after disabling step 0, moving CH16 to step 1, how can that be explained? Also changed the array pointer to match CH16 was moved to SS2 step 1. The same large MSB gain of step 0 occurs on all programmed sequencers, step 0 has more MSB gain than any other steps. How does that constitute special care was taken in channel matching to minimize cross talk between channels as the datasheet states. Certainly there is mayhem in the sequencers configurations that is not intended yet it exists!  

Datasheet below claims ADCSSEMUX bit is set ADCSSMUX0 19:16 AIN17 will be 0x1, that contradicts Tivaware ADC channel decodes for 19:16 being exact match for channels 3:0 in the ADCSSMUXn.

One thought:   

Over lapping AIN0 may somehow be inflicting AIN16 pure analog FIFO data of LM94022 sensor, AIN16 has higher than typical voltage coming out,10K to ground. Fact is any capacitance added on AIN16 makes it more difficult to stabilize PK0 (AIN16) data ADC1 SS1. Again PE4 (AIN9) ADC1 SS1 2nd LM94022 analog FIFO data quiet as church mouse, how can that be explained if cross talk was to blame? It would seem AIN0 errata #13 may somehow be inflicting FIFO step 0 data. Also noting the FIFO Head/Tail pointers are not changing in CCS debug register view. Note AIN0 was not configured, the MCU pin was left floating! Exact same sequencer conditions exist EKXL/EVM and custom PCB with AIN16 and FIFO step 1 excessive MSB digital data amplitude.

Register 15: ADC Sample Sequence Input Multiplexer Select 0 (ADCSSMUX0), offset 0x040

The MUX7 field is used during the eighth sample of a sequence executed
with the sample sequencer. It specifies which of the analog inputs is
sampled for the analog-to-digital conversion. The value set here indicates
the corresponding pin, for example, a value of 0x1 when EMUX7 is clear
indicates the input is AIN1. A value of 0x1 when EMUX7 is set indicates
the input is AIN17

Note: Channels AIN[31:20] do not exist on this microcontroller. Configuring MUXn to be 0xC-0xF
when the corresponding EMUXn bit is set results in undefined behavior.

Perhaps try 10k to ground on each channel and inject a period analog signal into AIN16 and AN1 or AN2. To make it a real comparison, port the FIFO data via UARTprintf() showing CH16, CH17, CH1, CH2, configured in multiple steps of the same sequencer, CH16 on step 0. All channels FIFO steps printed data should be within +/-30 LSB of any adjacent channel.

Apologize for confusing the church mouse channel ADC1 was actually AIN9 (2nd LM94002) above post. It was ADC0 PE2 CH1 data inflicting PK0 CH16 in ADC1 configurations, not only ADC0 in this issue.

Had to move the MCU internal Temp sensor from ADC1 to ADC0 as it kept triggering over temp faults, same issue inflicting CH16 (PK0) LM94002 sensor. That same issue with ADC1 SS1 step1 may be where ADCSSEMUX being set for CH16 (PK0) is passing FIFO data from ADC0 SS1 step1 CH1 (PE1).

ADC0 and ADC1 have to be configured SS1 step 0/1 for the errata to unleash it's plague upon humanity, where ADCSSEMUX bit of ADC1 is seemingly being ignored by ADC0. Who would know in this scenario as ADC0 CH1 data is only present with PWM0 activity and that is when ADC1 CH16 step 0 starts to have real issues. Yet AIN9 (PE4) ADC1 step 1 the other LM94002 sensor has very quiet readings at all times.

Next chess move; get out of ADC1 completely, that should remove issue of ADC0 CH1 FIFO data bleeding into ADC1 CH16.

While 'church mice' are (often) confused - might the 'fast & loose' presentation of 'errant conclusions' (as identified by multiple vendor agents & this reporter) - and the introduction (most always) of 'far too many variables' (some even, 'off-subject')  - 'aid & abet' such (ongoing) confusion?

Seriously - do you 'expect'  this busy vendor to follow your directive to: 

• Perhaps try 10k to ground on each channel
• inject a period analog signal into AIN16 and AN1 or AN2.
• port the FIFO data via UARTprintf() showing CH16, CH17, CH1, CH2
• above - configured in multiple steps of the same sequencer, CH16 on step 0
• and perform 'all of the above' while 'rubbing his belly in a (descending radius) circular motion' - at/around 2 Hz

In the (highly) unlikely event that (your) 'periodic signal' - (really) caused the signal 'bleed' you reported - I'd (almost) certainly attribute that to,

• 'Signal Over-Drive'
• and likely 'RICH in harmonics!'
• ineffectual match of impedance - and/or 'other' ADC spec violation
• ineffectual common ground  (this has caused 'similar' to a client of ours - when the (commopn) Gnd connection failed!)
• Stick-Pin - not having received - its most recent (required) calibration

I am told that the 'over/under' (re: another 'Poster Self-Awarded Resolution'(?)) stands at '3.'     (note that 'chess' demands (great) discipline - checkers ... far less so...)