TM4C123GH6PZT - Enable ADC disconnects debug probe

Re: "Enabling the ADC "disconnects" debug probe."

That would be a "first!" (as the "likely" longest forum user - such may earn (some) weight.)

Your code shows function calls w/out any delays interspersed. They're quick/easy to add - and likely worthwhile.

The 123 part number you reference is NOT that found upon the LPad - so your inclusion of (proper valued) external pull-up resistors upon the JTAG lines must be met. Have you added these. (internal MCU ones are too high in value - we've encountered this again & again!)

Have you chosen an ADC which includes pins w/in Port C? (the JTAG Port) That may prove unwise - especially if PC0-PC3 are impacted.

And - might your custom board have shorts or improper handling of the multiple power pins - to include the abundance of closely spaced bypass caps. And Vddc's external caps must be of proper value - and again in close proximity to the MCU.

Hi;
>>Your code shows function calls w/out any delays interspersed. They're quick/easy to add - and likely worthwhile.

done, no change.

>>The 123 part number you reference is NOT that found upon the LPad - so your inclusion of (proper valued) external pull-up resistors upon the JTAG lines must be met. Have you added these. (internal MCU ones are too high in value - we've encountered this again & again!)

I am using the launchpad as debug probe. On EK-TM4C123GXL Rev A.sch there is 10K pullups on TCK/TMS. Programming lead to custom board is short (tag-connect TC2050). Do I need them on the driven lines? (TDI, TDO)

>>Have you chosen an ADC which includes pins w/in Port C? (the JTAG Port) That may prove unwise - especially if PC0-PC3 are impacted.

JTAG port is exclusively JTAG, no other connections.

>>And - might your custom board have shorts or improper handling of the multiple power pins - to include the abundance of closely spaced bypass caps. And Vddc's external caps must be of proper value - and again in close proximity to the MCU.

Possibly, but everything else runs in debug mode with no probe disconnects. VANA has .003mV of noise and is run by separate LDO with separate ground plane.

I have tried direct programming access in addition to TIVAware
//HWREGBITW(0x400fe638,0)=1;
//HWREGBITW(0x400fe638,1)=1;

I am thinking that the clock must be out of spec and the adc is bombing when accessed.

Just for sanity check, can you access ADC0 register in debug mode before it is enabled?

v/r, Rob

Hello Rob,

Does the same code work on the EK-TM4C123GXL?

Amit,

I don't know, I have the project targeted for the GH6PZ part. I could modify the project and retest..since that is what I am using as my debug probe. I desoldered the VDD jumper to solder in the JTAG cable so I will have to redo that in order to test.
So if it does the same I can assume it is software, and if it doesnt it is my hardware?
I am not familiar with the differences between the parts. The errata sheets have a lot of stuff. My silicon version is B1.
v/r, Rob

Hello Robert,

Since the device seems to be unresponsive at the point of

SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0); // problem is here

which is almost 4 functions down when entering into main, it should be an easy comparison between the two boards.

Pull up should appear upon TDI also. I'm advising to "for now" avoid ANY use of Port C as a programming mistake will KILL JTAG.

Are you introducing any signals into any of the ADC pins? I've never/ever seen nor heard of your issue.

As always - "Single Board Anomalies" are the bane of we "remote diagnosticians." Surely you've built more than one board! (one hopes) How do the others behave?

Too late now but I believe that the ADC Registers may become "disturbed" when open w/in the IDE and program is running.   If you can precisely detail what you're doing I may be able to attempt to duplicate tomorrow.

cb1
I will remove the GPIO pin assignments to PC4-7.
I always thought that TDI is driven by the debug probe so it shouldnt require a pullup while the probe is connected.
Not a single board fault, I have ten boards, will run these tests tomorrow after other job. Currently offsite at another job.
Thx

amit,
good idea to use the launchpad as a test. Is there a way in CCS to save both configurations in the project? By configuration I mean that the target file, the startup file, and the command files are different, when I use the IDE to change configuration it complains because it is processing all the files. Is that a feature of this IDE?
v/r, Rob

Hello ROB

Yes. There is an option to exclude files from a build, when you right click on a project file. This way you can have 2 copies of the same file for different target devices.

ROB said:

I always thought that TDI is driven by the debug probe so it shouldnt require a pullup while the probe is connected

And when it is disconnected?

Robert

@ Robert,

Bingo! Allowing MCU pins to "float" is rarely wise... And - should the debug probe "drive the pin" there's is "No harm - No foul!" Should it not - shipwreck, rocks, tall waves - one may "wash up" here...

Hi Robert,

If it is used exclusively for JTAG then JTAG shouldn't be active and therefore not an issue...right? Maybe I should set an internal pull-up resistor in the software but if my overall emi is good I won;t have cause to do either.

v/r,

Rob

ROB said:

If it is used exclusively for JTAG then JTAG shouldn't be active and therefore not an issue...right?

No, JTAG would be sensitive to input edges so any activity on the input could register as JTAG activity. In particular if the JTAG was disconnected or connected but not actively driving the outputs.

ROB said:

Maybe I should set an internal pull-up resistor in the software but if my overall emi is good I won;t have cause to do either.

I'm with cb1 on this, I don't think the built-in pull-ups are sufficiently strong.

Robert

First, my question using CCS Version: 6.2.0.00050, can you access ADC registers before the ADC is enabled? Answer is NO.
Verified with Launchpad board as target. Same behavior with custom board. This is good to know point for me.

Second, EK-TM4C123GXL Launchpad board requires different pinning, USB is on different port, and there are less pins so peripherals have to move around. Before changing pin configurations to reduce to the pins available on the TM4C123GH6PM (launchpad mcu), results were same as custom board, now with reconfigured pinout.c from Pin Mux Utility Launchpad does not fault at ADC enable when I break the program at/just after that point.

That leads me to believe my pinout.c is faulty and I suspect I will discover the root cause tomorrow.

That's good/logical detective work - thank you - myself/others appreciate your sharing of those findings.

While you've had to, "Engage & jump thru hoops" - much of this will build your understanding & capability.

I am in (bit) of disbelief that a pin error would cause the ADC Enable to fault... (we shall, "Stay tuned.")

Well it is a pin ..... sort of.

In the SYSCTL.RIS register there is this bit:

VDDARIS

VDDA Power OK Event Raw Interrupt Status

Value        Description

0 VDDA power is not at its appropriate functional voltage.

1 VDDA is at an appropriate functional voltage.

The voltage on VDDA is 3.15V with ,003 to .005VPP noise.

The spec on page 1397 states:   (From DS-TM4C123GH6PZ-15842.2741 SPMS377E June 2014)

Table 24-5. Recommended DC Operating Conditions
Parameter Parameter Name Min Nom Max Unit
VDD VDD supply voltage 3.15 3.3 3.63 V
VDDA VDDA supply voltage 2.97 3.3 3.63 V
VDDC VDDC supply voltage 1.08 1.2 1.32 V
VDDCDS VDDC supply voltage, Deep-sleepmode 1.08 - 1.32 V

Apparently 3.15VDC (which is in spec) is not good enough. Fortunately I can change the LDO out for a 3.3V and retest.

I do not see any mention of this in the silicon errata document ( SPMZ849F–August 2013–Revised April 2016 )

My silicon is revision B1. Starting a ticket with TI.

Geez. Who should get the answer this question points?

v/r,
Rob

Also found another note on the design guidelines (Section 3.5.5 SPMA059–October 2013)...Have to put VDDA and VREF on the scope and recheck that they sequence properly... I wait until all power has stabilized before attempting to enable the peripherals so it shouldn't make a difference (but it probably does!).

NOTE: Do not leave VREFA+ or VREFA- unconnected. VREFA+ must power up after or simultaneous to VDDA.

One final note,

    setting the ICM bit for the VDDA (before enabling the ADC) prevents the CPU reset as well.

 TI Support just responded saying support migrated here. If that is the case then I will spec another mfr part from ST or MCHP where I will get support.