TM4C123G ADC high current issue

Hello Taivo,

Let me thank you for a very well documented issue and experiment list. There is no room for us to misinterpret any data. There are some basic questions I would like to ask

1. Is this behavior on every TM4C123GE6PZ part or it behaves this only on 1 part.

2. You can send the details as mentioned by you to the Local FAE and they ask them to route it to me for analysis.

We haven't seen any issue like this so it would interesting to look into it.

Regards

Amit

Hello Amit,

This has happened on more than just one board. Early this day when I was writing the post, such behaviour was 100% repeatable - when adc input ch18 dropped it caused high current and that remained until adc input was lowered more below 1V and then it recovered. Later in the evening I tried more and then adc input also dropped when the neighboring input switch was pressed/grounded, but not so much, the drop was temporary and the part recovered to the correct voltage, no such high current, but drop was still clearly observable. So, even the same board running the same s/w can react to pin #19 switch event differently, but clearly there is some kind of dependence between pin #18 as adc input and pin #19 as gpioinput.

Who would be the local fae in Europe to contact to?

Thanks,

Taivo.

Our group uses many ARM MCUs - from multiple vendors - have observed similar behavior - but not to your (150mA) extent.  In the few cases we've encountered the ADC signal either ranged above or below the MCU's ADC input spec.  And - in other cases the "grounded gpio input" returned to "other" than real/proper circuit ground. 

Have you voltage probed the pin #19 gpio input - both before & after grounding?  Suspect 3V3 is the best voltage for that pin when the switch is inactive.  Now that 3V3 may emanate from MCU's internal - WPU - or an external one.  We've seen cases where external pull-ups were orders of magnitude lower than is normal/customary.  Such could explain your observation.  (a proper test would measure the pull-up R's resistance)

Unstated - during your test have all other interconnects been removed?  (clients always assure us, "No way is the interconnect related - could cause."  And - our cash register rings (rather loudly) when we prove them wrong!

You state, "This has happened on more than just one board."  And - while this suggests other than a single board anomaly - it may be that your test equipment/methods have added to (or even caused) this difficulty.  (your interconnect may be introducing "illegal" signal levels into pins 18 and/or 19 - if such interconnects are employed...  Again - we've encountered this.)

If you've a "bare board" that pin #19 should be systematically probed and visually inspected to insure that it does not create any "undesired" interconnects.  (we've seen that)  While not so quick/direct - that same test could (and should) be performed upon a fully populated board - as well.

Your SW is not entirely, "off the hook" either.  Have you tried to repeat your test - but with the MCU either "fresh" (from the factory) or freshly erased?  Passing such test signals that your SW is impacting...

If possible - can you interrupt the trace back to pin #19 - and route it instead to another, properly performing gpio input.  (interrupt all connections to that "properly performing gpio - first) 

We realize that you have, "strong beliefs" but experience teaches that the "unexpected" best yields to methodical, independent testing by a separate party.  (I've stared at a line of code or schematic - had no clue - another has glanced and said - "here it is!"  Sometimes you can be, "too close" to an issue...)

Thanks for your inputs!

I did some more experiments and here are the results:

* I disconnected pin #19 from uC, near its pin by maintaining all the possible parasitics. Next I connected it to another unused pin #2, where adjacent pin #3 happened to be adc input ch13. Everything worked as expected, no drop at any adc input. I also tried to put the switch to pin #1 and still all ok.

* Next I disconnected another input switch from pin #24 which has never indicated any issues. I connected it to pin #19 and everything described in my first post was totally repeatable again.

So I conclude that board related factors cannot cause such behaviour. Definitely one may propose not to put sensitive analog signal next to noise digital signal, but right now this cannot explain it. There is even the case where pin #88 in gpiooutput configuration is mirroring uart_tx and adc input ch21 on pin #89 next to it does not read any change in 8bit code when transmitting @31kHz.

Understanding the mechanism why adc input on pin #18 when at max position drops to 1V when input on pin #19 goes to ground, is essential to design future products on that part. Right now I don't have any sw workaround and need to route pin #19 to another spare pin for current patch of boards.

Thanks,

Taivo.

Thanks your considered/detailed response.   And - feel your pain!   Yet - what you report is so unusual - I'd condemn the MCU only much later.

What you've not tried - or reported - is the introduction of those same analog signal levels into MCU pin 18 and then the proper grounding of pin 19, into a fresh, unprogrammed (or fully erased) MCU.  (there's been no feedback on presence and/or correctness of the (assumed) pull-up Rs - pin 19 in particular)  Conducting such test upon a fresh MCU may further support the theory of MCU problem - it eliminates all of your SW from, "usual suspect" list.  (yes - often we've seen misconfigured MCU pins/functions cause excess current draw - other misbehaviors)

Should the unprogrammed or fully erased MCU "pass" the analog signal + ground test (per above) it appears logical to program just the set-up/config to ADC for pin 18, and the gpio input for pin 19.  (assure correct pull-up R @ 19)  Perhaps the pin 19's internal pull-up R makes it "vulnerable" to such "neighboring" pin's ADC config.  Thus - suggest an external 10K R serve as pull-up to 3V3.  (not 5V)  That minimum MCU program can then be tested & observed.

I made the effort to see if I could replicate your findings on our existing LX4F and TM4C (custom) boards.  These MCUs do not allow pin 18 to serve as ADC but we did configure pin 62 (PD1) as ADC and pin 63 (PD2) as a gpio input - tested per your direction - with no fault found.  (those 2 adjacent pins the only ones which we could re-config to meet your issue)

Testing fresh/blank MCU - and then one programmed only with Pin 18 config'ed as ADC and Pin 19 as gpio input (external pull-up) seems a proper means to cause the vendor to "accept" that yours may be an MCU issue...

Again - we've seen "close" but not to your degree (150mA i adder) with over 12 years ARM experience & 4 different ARM vendors...  May be worth your time/effort to try (then report) methods herein suggested...

Thanks cb1, I followed your suggestion to try it on blank unprogrammed part and surprisingly the issue was repeatable on every single board we tested. The boards were fully assembled.

On pin #18 there is wiper of 5k potentiometer with 1u filtering cap to ground. Its top contact is tied to uC VDDA pin #7 and ground to pcb common ground plane. The switch has 10k pullup to uC 3.3V VDD. It also has 100n filtering cap to ground.

So the test case is: turn pot to max position, pin #18 gets 3.3V as expected, short pin #19 to ground -> pin #18 drops to 1V and huge current starts flowing to pin #18. The part recovers when pin #18 voltage is decreased below 1V, then the current stops and potentiometer draws its wiper back to correct ~3.25V.

When I said 150mA, then it is not totally true, it is even worse. Directly we can only measure supply current of the entire board which at normal condition is 70mA. When the issue occurs the supply current jumps to 350mA, but need to take into account that there is DCDC @9V on the supply path which creates 3.3V for uC and filtered path for uC VDDA. We calculate ~600mA going into pin #18.

From here I will wait for Amit to investigate what is going on inside the uC and see if he also can replicate the event. He has full schematic of my board to check if we have issues on the application side.

Regards,

Taivo.

I am surprised - yet there's still a chance (admittedly remote) that an illegal current path exists between that 9V and pin 18.

[edit] 14:05 - made the time/effort to dig thru past client, "somewhat similar" issues.  While a, "long-shot" - a client noted similar behavior (this vendor's MCUs) and the issue was a, "missed" connection to Vdd and/or Gnd - on that same side of the MCU.  (i.e. assuming QFP - MCU has 4 sides)  If either a Vdd or Gnd connection is missed - excessive current flow was reported.  (records don't reveal as > 200mA - but this does suggest that "fresh eyes" double/triple check your board layout and proper solder paste reflow to each/every MCU power pin.  (Vdd & Gnd)

Taivo Saarts said:

On pin #18 there is wiper of 5k potentiometer with 1u filtering cap to ground. Its top contact is tied to uC VDDA pin #7 and ground to pcb common ground plane. The switch has 10k pullup to uC 3.3V VDD. It also has 100n filtering cap to ground.

 Hi Taivo, just to try is processor and not ringing when you short input capacitor, try insert a 47-100 Ohm  resistor between pin 19 and switch then try again the sequence.

Roberto - you raise a valid point - but poster's mention of ~600mA into/thru pin 18 seems (to me) unlikely to result from, "ringing."  Of course poster should employ a series R - as you direct - yet I'd wager tall chip-stack (Vegas chips) that some, "sneak path" exists between pin 18 and some portion of poster's 9V.  (I'd still bet on his board - not the MCU - as being prime suspect...)

I agree it is a good practise to have series resistor on input switch, though on Lauchpad there is 300Ohms on SW2, but none on SW1 so I believe it cannot be the root cause in my case.

I wonder if anybody has TM4C123GE or GH to try my issue on real board to narrow down speculations? Have pin #18 to 3.3V and pull pin#19 from 3.3V to ground. Observe supply current and voltage on pin #18. The part can be unprogrammed.

Launchpad does not have portH on package pinout, but dev board has, but I am not sure if it contains the same die as 100 pin package, but it may be worth to try if anybody has it nearby.

Thanks for ideas,

Taivo.

Made the effort to dig thru past client files - find that case most similar to yours.  And - as I recalled - they had "missed" one Vdd pin on their MCU.  (routing it instead - as a gpio)  Behavior on that "missed" side (1 of 4) of that MCU became uncertain - ADC readings varied (not to the extent you report) based upon the digital levels upon certain pins (again same side as the missed Vdd pin).

Too aggressive (too low) an external pull-up R @ your pin 19 may cause/contribute - I can't find where you've detailed.  If you're using the MCU's internal (weak) pull-up - I'd kill that & replace w/different value external pull-ups - and retest.

Might it be that your analog signal into pin 18 (your ADC input) "beats" the arrival of Vdd to your MCU?  Such may occur if that pin 18 signal is not derived from the same voltage source (i.e. 3V3 regulator) as feeds your MCU.  And - might that analog signal, "over-shoot" the MCU's 3V3 max - especially upon power-up?  Further - have you tried limiting the pin 18 analog signal to 3V0 - at what voltage level (beneath 3V3) does this unwanted (p 18-19) behavior occur?

Yet another test (only child imagination run amuck) change pin 19 from input to push-pull output and see if/how the transition from high to low (or vice versa) impacts pin 18's ADC reading.  I'd try @ manual speeds - and then maybe w/1KHz output freq @ p19.  (I remain doubtful of an "input only" link - which is all you report having tried/testing)

Wouldn't you better encourage others to assist by "identifying" the "Dev Board" (i.e. provide vendor's part no.) which includes your errant pin pairing?  Such "external" confirming of your findings may, "Make your case" - yet you've left that path vague.  You want to ease the path for your helpers...  (I think)

One last gasp - suggest that you employ a series of tests - progressively increasing the resistance value - between your pin 19 and MCU ground to attempt to identify "just where" the issue strikes.  This may cause an oscillation (@ pin 19 or pin 18 - or both) and the frequency & extent of that oscillation may prove useful in issue diagnosis/resolution...

Hello Taivo,

We ran the test on a 100LQFP part flash erased part (to make sure we can reproduce the same on a non-programmed part as well). Following was the procedure (for all to review)

1. Set a Power Supply for 100mA (current limit) and applied it to pin-18 (PH2)
2. Connected Pin-19 (PH3) to a switch with Pull Up of 10K
3. Increased the voltage from 0V to 3.6V in steps of 0.1V and every time we pressed the PH3 Switch nothing happened. The current remained the same in uA.
4. We checked the power supply’s current measurement after connecting the same to power the main board and it was working fine.

Regards

Amit

Almit's comprehensive test substantially clears your, "blame the MCU" claim/theory.  That as we've long observed - and were taught.  (blame the IC last)

That extra current draw does concern - and I persist in the belief that your "higher voltage" (9V iirc) is some way/how improperly intruding into the MCU space. I remain wary of your pcb and/or its build/component fill. 

We always build our pcbs so that a 0-ohm, SMT R, can "open" the 3V3 regulator's output.  (such enables the test/verify of that regulator prior to 0-ohm's insertion - and enables the easy insertion of a current measure)  Mention this as that illegal, excess current must source from your "higher voltage" - but your monitoring the 3V3 current draw (alone) may prove diagnostically useful. 

Another test would have you progressively lower that "higher voltage" - monitoring the degree and continuation of your issue. 

And - you are silent as regards results following multiple, past diagnostic suggestions - embodied my last post... 

Thank you Amit and cb1 for you inputs. We will take further test end of next week when we are back in the office again.

Regards,

Taivo.

Hello Taivo

Sure. No problems. We are keeping this issue open for further investigation as well.

Regards

Amit