TM4C1294KCPDT: Analog comparator external reference oddly effects ADC1 samples.

BP101 said:

// Unlock pin 23 PC6 GPIO for analog PIN0 +VREF.

Now neither firm nor I employ your '129 family MCU.    Yet - is not such "Pin Unlocking CONFINED" to the JTAG Pins of Port C - which usually are"  "PC0 - PC3" - and NOT extending to PC6 - as you've implemented?

Should PC6 be an "actual" JTAG pins - my apologies - but such change seems "unlikely."     Whether such "UNWARRANTED UNLOCKING" has disturbed that pin (or port) remains to be seen - yet I felt it wise to bring this (very quick FIND) to your attention.  

It is suspected that - rather than your "Unwarranted Unlocking" - you intended to "Re-Purpose that PC6 pin!"      There IS a significant difference - and as you report (again) "TROUBLE" - such must be flagged for your attention.     (I've looked nowhere else - am off to "Profit-Seeking" departing (one) "Vale of Tears."

I would BET - most all of "the farm" - that a (somewhat) careful read of your MCU manual - will reveal, NO/ZERO necessity to "Unlock" beyond PC0-PC3!

If that fact has been missed (after ALL of these years) ... might others have escaped note - as well?

Firm/I - for beyond past EIGHT years - have deployed FIRST the LX4F's Analog Comparator - and now 4C123's - NEVER/EVER encountering your issue.     As your subject notes: (external reference) we rejected use of the MCU's internal voltage comparison levels - as they were TOO COARSE for our (and our clients') taste.

It has been quite awhile - but have you checked the "acceptable voltage range" - of both Analog Comparator's (+) & (-) inputs - and insured that your signal inputs remain in compliance?    ("remain" - very much the "operative" word, here)     On "plain-jane" jelly-bean devices - usually those input voltage ranges are compressed - so care must be applied...   (cannot come too close to (either) supply rail (Gnd or VDD))    You must check...

BTW - would it not  "enhance your diagnostic effort"  to (temporarily) replace your (+) & (-) Analog Comparator signal routings (inputs) - with "KNOWN, STIFF, Adjustable Voltages" - which you can quickly/easily alter?    You then - can easily monitor & gauge the  switch-point performance - of EACH  MCU-based,  Analog Comparator.

I just "re-read" your thread's Subject/Title: MCU's Analog Comparator "EFFECTS" ADC1 samples!

From an (admittedly) very quick read of your (new/most recent) issue - it seemed that your MCU's Analog Comparators - "Were not switching correctly - based upon the applied voltages - impressed upon comparators (+) & (-) inputs!      What does that have to do with (either) ADC0 or ADC1?       (unless you route that same "analog signal" to (both) an ADC pin and Analog Comparator pin?)    If that was described - I missed it - and do apologize.       Might  you "be so good" as to clarify? 

We have clients here - (joint NEVER "looked/smelled" so good) so my time (& response) is (beyond) its normal  attention-scattered...

BP101 said:

Three analog COMPS use single C0+ source (PC6) setting the input threshold of -C0,-C1,-C2 configured for alternate +VREF C0+,C1+,C2+. Oddly COMP trips too occur below any thresholds of Internal +VREF with ASRCP_REF ladder resistors set for highest values of VREF table 22-3, 22-4.  Configuration for Analog COMPS to use external +VREF PINO is shown below.

I "re-read" the above - three times - beyond my comprehension!        (possibly that of others - as well)      Note too - that your subject line emphasizes "External Voltage Reference" yet your (overly long, unclear writing) notes "Internal +VREF and (clearly) INTERNAL ladder resistors!"      It is doubtful that (anyone) can "parse" your writing - is that not so?     Are not EXTERNAL & INTERNAL (voltage references/sources) - in EXTREMELY HIGH CONFLICT?     (as that long sentence - reveals?)

Might you describe differently - ideally indicating (in chart form)  "to what (each) Analog Comparator's  (+) & (-) inputs, connect?  

Your clause, "(PC6) setting the input threshold of -C0,-C1,-C2 configured for alternate +VREF C0+,C1+,C2+"  proves FAR TOO COMPRESSED - for my feeble brain.    (however - eager to assist...)

Both internal and external +VREF sources fail, internal ladder highest setting or 10 turn pot 2.8v fail to resolve the boot charge cap transient caused by UCC27714 HO/LO FET drives that stop <100ns LI to LO pulses. Transient seems to occur no matter how the pre-charge period is divided or even disabled since stopping < 100ns Cboot charge pulses is a killer to PWM open loop commutation. So disappointed in TI UCC27714 gate driver not keeping consistent with other vendors gate drivers allowing < 100ns HI/LI pulses. It seems to allow 1/2 bridge HO to LO shoot through to occur during Cboot charge cycles. How else could DC BusVoltage suddenly rise 24v to over 150v in the ADC0 samples?

Point is the Analog COMPS input timing revolves around other ADC peripherals and NVIC servicing the interrupt source/s. After trying numerous different ways to configure the COMPS output fault source it appears they are stopping the PWM trip event before even a 30Mhz scope single capture 10K cycles deep can capture prior to otherwise MCU POR event occurring disabled M0Fault inputs.

I apologize for not recognizing our custom PCB inrush DC current delay FET circuit LO side gate driver was regulating those ground transients. A 680uf electrolytic ground control reacted during any negative transient bypassing Cboot startup transient that ADC0 was rapidly sampling. After removing the FET delay circuit and populating inrush delay circuit with isolated relay contacts the Cboot charge transient could not be stopped by simple SW tweaks to the PWM period.

OMG

Is it fair & proper to note - that you opened this thread with, "Analog Comparator ... External Reference" -  then weaved in  "Internal Reference" - and  NOW  suddenly (abandoned the Ana Comps) - switching  "today's protest" to the hapless UCC27714.    Is this not,   "Krazy Making?"

You - once more - offer up a "reach" - w/out benefit of ANY supporting justification!      (that's becoming quite a habit - is it not?)     Follows your (latest)  unsupported conclusion:

"Point is the Analog COMPS input timing revolves around other ADC peripherals and NVIC servicing the interrupt source/s."      Who authored this "point" - can you, Get your money back?    And - how soon?

There is NO SUCH point - not close!      If indeed you have not confused the MCU's "Digital Comparators" - with their "Analog Comparators" (the analog comparators "expose" the comparator's (+) & (-) inputs - to the outside world)  - it is my belief (which I can prove) that :IN NO WAY WHATSOEVER - do these  essentially PURE Hardware Comparators - "Revolve around (other) ADC peripherals - nor the NVIC!     From WHERE do you "get this stuff" - and  then form such (mistaken) conclusions?     Pray tell - just HOW - the Analog Comparators  "REVOLVE AROUND (other) ADC Peripherals!      (Let the ducking & diving commence...)

If you've properly set-up & configured the MCU's ANALOG COMPARATORS - they should operate as an (almost) entirely  "FREE"  hardware sub-system!      Ours run - even when - especially when  - the MCU's ADC sub-system is engaged/enabled - or completely OFF!      Thus there exists  NO/ZERO "revolves around other ADC Peripherals!"      That "revolves may  (somewhat) apply to the Digital Comparators - you have (likely) confused the two - yet your thread title casts no doubt as to your "Analog Comparator" being your central subject...    

The fact that you have "such trouble" - with the Analog Comparators - suggests strongly - that your set-up/configuration of the "Analog Comparators" was improper - or that you've (earlier) "damaged" those MCU pins.    It is firm's & my belief - that post Analog Comparator "Set-Up/Config"  -  any Software or (other) ADC Peripheral involvement - is MUTE - and has,  "Left the Building!"

BP101 said:

Point is the Analog COMPS input timing revolves around other ADC peripherals

Both this reporter - and here now YOUR "1294 MCU manual" - stand in solid disagreement w/your  "point."

As my past writing identified - have you NOT (likely) CONFUSED the Digital Comparators - with the  Analog Comparators?    The Digital Comparators (very)  much appear - w/in the ADC Module Block Diagram!   Yet there is NO SIGN WHATSOEVER - of ANY Analog Comparator - thus (your)  "ANA Comps input timing"  (WHAT TIMING?) "revolving around other ADC peripherals" - is hugely incorrect!    

Poster's Subject claim - that the Analog Comparator  "oddly effects" ADC1 Samples  - appears also -  (very) mistaken - and  (of course) unsupportable...

And follows - the "Analog Comparator" Section of the SAME MCU Manual:    Should it NOT be noted - that there is NO direct linkage - to ANY ADC Peripherals - as (one here) claimed!     While the analog comparator (may) trigger an ADC conversion - there is absolutely NO IMPACT WHATSOEVER - upon the Analog Comparators "input timing" as (erroneously) claimed!

When "Making a Point" - there should be (some) justification - to offer in support.    (i.e. as presented here - and now!)   Otherwise - as proven here - one's "point" is naked "opinion" - and may be (very) WRONG & UNSOUND!

Would it not prove  "far safer" for you to present issues in a question form - as opposed to your "point" - which (too often) proves (very) Off-Mark?

Perhaps your forgetting conditions around sensors do change in overall application timing relative to how fast ADC0/1 samples interrupt NVIC. Especially in this scenario PWM0 is not in the same time domain as ADC0/1. So it don't matter how static you perceive Analog comps to be, sensors reporting functions are throttled by application execution timing.

During that time a lot of things can go wrong or right depending on HW surrounding the MCU and applications execution speed. I simply did not believe the INA240 could or should be capable to violate its own VDD 3v3 rail output into Analog COMPS. Single scope captures of ALGCOMPS trip point events did not indicate OV was occurring. Disabling ALGCOMPS inputs then tripped MnFault events, POR MCU every time at less than 3v5P, makes no sense. 
  
BTW you might have missed opening post GPIO PC6 was not even required and made no difference to the ALGCOMPS configuration and over written by the very next line. The OV problem still remains CB1, no matter the source it must be rectified. Perhaps is safe to believe ALGCOMPS are working properly, internal or external +VREF. Yet still no answer to opening post "where can external +VREF voltage PC6 be verified in CCS debug ?"

Perhaps you now see I was referring to ALGCOMPS fault status reporting delayed by ADC0/1 events timing relative EMAC0 packets sent to GUI. Other times no M0nFaults being tripped since ALGCOMPS were effectively disable just to have small drive motor run. 

Once again - you resort to,  "point is" - which has served you ... LESS than WELL!

You have claimed:  "Analog Comparators input timing to REVOLVE around the ADC & other analog peripherals" - yet when (repeatedly asked) for "source justification" - none has been provided!    (The reason for such "source denial" is (beyond) obvious - is it not?)     And - such unfounded "POINT IS" - does not serve you - nor follow-on readers - who may,  "Partake of your Kool-Aid."

Your reread (or possibly more "focused" read) of  "your" MCU manual further reveals your  (almost certain)  CONFUSING of the MCU's  DIGITAL COMPARATORS - (which ARE closely coupled to the ADC) with the (essentially) "Stand-Alone - almost hardware exclusive"  ANALOG COMPARATORS!     

Do you serve your,  "Quest for Help" - by (continuing) to deny this confusion - and misstatement?    Are those here - trying to guide/assist - to "welcome"  (such obvious) misstatements?

Analog-to-Digital Converter (ADC)

An analog-to-digital converter (ADC) is a peripheral that converts a continuous analog voltage to a discrete digital number.    Two identical converter modules are included, which share 20 input channels.

The TM4C1294NCPDT ADC module features 12-bit conversion resolution and supports 20 input channels, plus an internal temperature sensor.    Each ADC module contains four programmable sequencers allowing the sampling of multiple analog input sources without controller intervention.

Each sample sequencer provides flexible programming with fully configurable input source, trigger events, interrupt generation, and sequencer priority.    In addition, the conversion value can optionally be diverted to a digital comparator module.    Each ADC module provides eight digital comparators.

Each digital comparator evaluates  the ADC conversion value against its two user-defined values to determine the operational range of the signal.    The trigger source for ADC0 and ADC1 may be independent or the two ADC modules may operate from the same trigger source and operate on the same or different inputs.     A phase shifter can delay the start of sampling by a specified phase angle.    When using both ADC modules, it is possible to configure the converters to start the conversions coincidentally or within a relative phase from each other, see “Sample Phase Control” on page 1060.

Nowhere does "ANALOG COMPARATOR" appear here - yet there are THREE MENTIONS OF "DIGITAL COMPARATORS" - your claim of the  "ANALOG COMPARATOR's  REVOLVING" around  "ADC/other Analog Peripheral" - despite (repeated) requests - remains UNSUPPORTABLE!   

The ability to "Digest vast MCU data" - and to then come to "Sound & Justifiable CONCLUSIONS" - is highly valued.    "REACHING for - and then Defending - Conclusions SO CONTRARY to the published data - (thus indefensible) - may well explain your cascade of  "ON-GOING" issues...

BP101 said:

The ALGCOMPS detection is constrained by other peripherals eating CPU MIPS during SW interrupt cycles.

ABSOLUTELY - PATENTLY  UNTRUE!     The ARM MCU's "ANALOG COMPARATORS" ...  SUFFER "NO/ZERO" SUCH CONSTRAINT!     Again - from where do you DRAW such UNFOUNDED CONCLUSION?

Your quote - substantially reveals - your understanding of  "ANALOG VS. DIGITAL COMPARATORS"  to require MASSIVE RE-THINK!

I HAVE "TRIED MY BEST" - REPEATEDLY - to convey the SURE FACT that the MCU'S ANALOG COMPARATORS - ONCE SET-UP/CONFIGURED - are ESSENTIALLY PURE HARDWARE ELEMENTS - AND ARE UNCONSTRAINED BY OTHER PERIPHERALS!     Note that STILL - after at least three requests - you provide,  "NOT ONE DOCUMENTING SOURCE FACT" - TO  JUSTIFY YOUR (FAILED)  OPINION!

It would  prove -  NOT at all hard or delaying - to provide properly driving inputs to your  Analog Comparators - while monitoring the comparators'  Outputs.    Once that's  established - one could  "Vary MCU Peripherals"   to one's "heart content" - seeking to observe/confirm (this poster's belief) of   "Constraint - Forced upon - the Analog Comparators!"     And of course -  there will be NONE!

It is useless for me to persist (although hope (almost) Did spring eternal) - your  undocumented  methods -  AGAIN are Failing!     FEW (beyond myself) appear  willing to deal w/such intransigence - at some point - it proves,  Time to,  "Fold the Tent."

I do hope you succeed - yet hopes are NOT HIGH.    YOU claim to know best - yet  ALL EVIDENCE,  (VAST EVIDENCE)  -  (POINTS)   FAR FROM THAT!

Your rejection of the FE explanation this forum 2 years ago does not bode well for giving best advise to posters, especially when being reminded. The analog comparators of the TM4C1284x are SYSCLK controlled, allow among other controls (ACCTLn REG-8,9,10) triggering internal interrupts, triggering ADC events, edge control of output, polarity of output. FE explanation was brief yet made clear the device is being clocked effecting the timing on the CnO outputs.

Recall CB1 voicing opinion that ALGCOMPS behavior was not truly fault tolerant in the sense CB1 perceived it should be in this debate above. Beyond all such riffraff, common ground may hold truth.

Disabling analog inputs -C0,-C1,-C2 does not stop random faulting MnFaut0-2, PWM0 generators modules (external) fault inputs directly wired C0O,C1O,C2O. The only way to stop ALGCOMPS tripping and fault reporting is by disabling MnFault 0-2 input source leading into PWM peripheral. If don't ring the fault alarm in ones logic flow there is no hope for any success!

Sadly such behavior among other oddities relative ADC1 sequencer trigger sources failing PWM0 GEN1, suggest an internal meltdown being ALGCOMPS registers are configured CCS debug. 

Again the opening post asked not yet answered, how to verify PC6 +VREF input is indeed being configured on GPIO-C LOCK REG19 (PC0-3), port is locked CCS Debug. There remains the remote possibility PC6 is not getting into ALGCOMPS Co+ (PINO) alternate input. Shared +VREF set 2.8v threshold is (not always) being matched by analog input threshold events, yet always trigger faults. Hence the reason to bring up the intern ASRCP ladder reference was tested at high setting and similar results occurred.

And from your older posting:

https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/422902/1511488#1511488

   MAP_GPIOPinConfigure(GPIO_PC6_C0+);

   MAP_GPIOPinTypeComparator(GPIO_PORTC_BASE, GPIO_PIN_6);

The (yellow) MUX decode was not listed in the (pin_map.h)

BP101 said:

The ALGCOMPS detection is constrained by other peripherals eating CPU MIPS during SW interrupt cycles. Amit even claimed in forum the COMPS clock domain could have an effect on input/output timing and conditions where SW goes nuts.

Can you post a link to the thread where Amit commented as such? I'd like to read through it... tried searching for it for a good 10 minutes and haven't figured out the right word combo to make E2E search pop up the right thread.

Still no help PC6 input, still can't find (GPIO_PC6_C0+) listed in any pin_map.h file. Amit CB1 and I were discussing another topic 2015 PWM GEN fault sources being triggered by MCU embedded analog comparators. Amit advised us both system clocking effects comps output relative to MnFaults being triggered in a different clock domain when PWM clock division. Of that I can believe the ADC/INT triggers on outputs are indeed clocked. Yet as explained when ADC0 is heavily tasked the time it takes comps to trigger PWM0 MnFaults appears to increase.

Why CB1 is not (GPIO_PC6_C0+) GPIO MUX decode listed in several Tivaware versions of (pin_map.h)? Also disabling GPIO ports part of analog COMPS configured inputs (-C0,-C1,-C2) has no effect to stop Mn0Faults from analog COMPS outputs C0O, C1O, C2O.

My opinion is GPIO configure was never required to begin with for COMPS inputs and deviates from the typical GPIO analog peripheral MUX configurations. And you question how ADC1 can be effected by COMPS, well the GPIO MUX decode for one when it has been compromised by unrelated SW configurations.

Follows a key writing (true copy from "Driver Lib User Guide") - which supports the,  "FREEDOM of the  MCU's ANALOG  COMPARATORS"  from (other)  Analog related peripherals & MCU clocking "entanglements."      (this may require several readings -  especially by those  "opinion only" enthusiasts,  most always,  "Resistant to  hard, vendor supplied, published  fact!")

Introduction
The comparator API provides a set of functions for programming and using the analog comparators.    A comparator can compare a test voltage against an individual external reference voltage, a shared single external reference voltage, or a shared internal reference voltage.    It can provide its output to a device pin,  acting as a replacement for an  ANALOG  COMPARATOR  on the board,  * (and no such (external - to be replaced) Analog Comparator has its "Switching Function" so IMPEDED) *    [this writing (added) by cb1.]

or  it can be used to signal the application via interrupts or triggers to the ADC to start capturing a sample sequence.    The interrupt generation logic is independent from the ADC triggering logic.  As a result, the comparator can generate an interrupt based on one event and an ADC trigger based on another event.    For example, an interrupt can be generated on a rising edge and the ADC triggered on a falling edge.

It is the PRESENCE of that  "or" - leading that 2nd clause - which CONFIRMS the ABILITY of these MCU-based Analog Comparators - to AVOID,  "any/all INTRUSIVE EFFECTS" - which (may) be introduced by other MCU System elements - even the System Clock - especially the System Clock!     For (likely now) the FIFTH TIME - the  "MCU's  ANALOG COMPARATORS'  SWITCHING OUTPUT FUNCTION" - operates very much - as "INDEPENDENT HARDWARE!"    It is the  ANALOG COMPARATORS' "Trigger and/or Interrupt" functions  ONLY - which may be impacted by (other) system elements!     Again - such is (convincingly signaled)  by the "or" - "PLACED SO SIGNIFICANTLY w/in the API's explanatory write-up."

Now I have "Little Doubt" in my group's,  "Having SOLVED" our (oft-challenged) poster's "latest crisis!"      Yet the unshackled "intransigence" has CONSEQUENCE -  (substantially) killing "Rescuer's" motivation...

BP101 said:

Why CB1 is not (GPIO_PC6_C0+) GPIO MUX decode listed in several Tivaware versions of (pin_map.h)? Also disabling GPIO ports part of analog COMPS configured inputs (-C0,-C1,-C2) has no effect to stop Mn0Faults from analog COMPS outputs C0O, C1O, C2O.

My opinion is GPIO configure was never required to begin with for COMPS inputs and deviates from the typical GPIO analog peripheral MUX configurations

The analog comps outputs are not directly coupled to MCU pins. Analog block Outputs must be configured as GPIO pins and the GPIO block is SYSCLK'd in order any signal ever reach MCU pins. Seems to be where confusion over Figure 22-1, datasheet showing outputs C0o, C1o, C2o going into space rather than leading into the GPIO pin MUX control block.

Oddly it seems Comps C1-, C2-, C3- inputs are being configured by REG8,9,10 for analog input pins hot out to MUC pins not requiring GPIO pin mux decodes. Input pins can trigger MoFault0-2 inputs when GPIO MUX for these MCU pins are not configured in the firmware update. That alone seems to suggest something in configuration is allowing the Analog Comps inputs to pass signals when technically they should not if the GPIO pin mux has not configured.

Alternatively it is possible the analog comps (digital) outputs are not being properly configured by Tivaware calls! Since C0o,C1o,C2o require GPIO pin mux function calls to route the outputs from a clocked GPIO control block to the outer MCU pins.

   // Enable PD0 pin 1  for COMP0 C0o Digital GPIO Output
   MAP_GPIOPinConfigure(GPIO_PD0_C0O);
   GPIOPinTypeComparatorOutput(GPIO_PORTD_AHB_BASE, GPIO_PIN_0);

   // Enable PD1 pin 2  for COMP1 C1o Digital GPIO Output
   MAP_GPIOPinConfigure(GPIO_PD1_C1O);
   GPIOPinTypeComparatorOutput(GPIO_PORTD_AHB_BASE, GPIO_PIN_1);

   // Enable PD2 pin 3 for COMP2 C2o Digital GPIO Output
   MAP_GPIOPinConfigure(GPIO_PD2_C2O);
   GPIOPinTypeComparatorOutput(GPIO_PORTD_AHB_BASE, GPIO_PIN_2);

Seems Tivaware makes analog comparator peripheral inputs as GPIO (Digital) inputs incorrectly!

void

GPIOPinTypeComparator(uint32_t ui32Port, uint8_t ui8Pins)

{

// Check the arguments.

ASSERT(_GPIOBaseValid(ui32Port));

// Make the pin(s) be inputs.

GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN);

// #define GPIO_DIR_MODE_HW 0x00000002 // Pin is a peripheral function

// Set the pad(s) for analog operation.

GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA,

GPIO_PIN_TYPE_ANALOG);

}

Did you read three lines further down?

GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA,

GPIO_PIN_TYPE_ANALOG);

Analog comparator external inputs such a (C0+PINO) must be configured Analog since Digital levels do not apply in this case.

It would also appear the Periph 0,1,2 etc. data bus MUX, Alternate Output/Output enable may be clocked at the peripheral level.

The analog comp outputs were previously configured by REG 8,9,10 for (C0o, C1o, C2o) therefore Tivaware call GPIOPinTypeComparatorOutput() seemingly must be set for a GPIO digital output not HW analog. Digital in order to present a binary 1/0 input level to M0Falult's based on the analog Cn- inputs threshold matching +VREF.

That point remains open for discussion as most all analog comparators output are not typically by design Digital output structures conforming to defined digital signal levels.

Perhaps could be wrong about PinTypeComparatorOutput() DIrModeSet not being HW for peripheral TTL output?

How could anyone confirm that GPIO MUX configuration is proper from the Analog COMPS Block diagram 22.1 or Fig 22-2?
 

Tivaware GPIOPinTypeADC() yet another incorrect setting GPIOAFSEL REG10 (0x420) bit control set GPIO_DIR_MODE_IN, was working but does not seem any peripheral pin should ever be under software control.

Don't know if I changed the call from HW to SW some time ago but technically the AFSEL bit should be set HW for an ADC channel from datasheet description. That SW statement refers to a GPIO pin read/write function not SW using a peripheral to RD/WR the GPIO pin.

GPIOPinTypeADC(uint32_t ui32Port, uint8_t ui8Pins){ 

// Check the arguments. 

ASSERT(_GPIOBaseValid(ui32Port)); 

// Make the pin(s) be a peripheral function. 

GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_HW);// was GPIO_DIR_MODE_IN 

// Set the pad(s) for analog operation. 

GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA,

GPIO_PIN_TYPE_ANALOG);

}

The GPIOAFSEL register is the mode control select register. If a bit is clear, the pin is used as a GPIO and is controlled by the GPIO registers. Setting a bit in this register configures thecorresponding GPIO line to be controlled by an associated peripheral. Several possible peripheral functions are multiplexed on each GPIO. The GPIO Port Control (GPIOPCTL) register is used to select one of the possible functions. Table 26-5 on page 1806 details which functions are muxed on each GPIO pin. The reset

Still have issues with Analog comps threshold being exceeded but the external PC6 +VREF seems to be functioning normal without calling GPIO pin type configure.

That seems to also include (Co1-,Co2-,Co3- ) are made PinMux peripheral inputs of MCU pins after calling ComparatorConfigure(COMP_ASRCP_PINO). Yet the COMPS outputs have to be configured in the GPIO PinMux so it seems.

Yet there remains the fact that Analog comparator (inputs) do not require GPIOPinType/Configure() calls as Tivaware help text does not make clear by claiming a call to GPIOPinCOnfigure is required for GPIOPinTypeComparator().

That sort of blows holes in Special/Analog being a pin type GPIO MODE_HW or DIR_MODE_IN.  Most seemingly believed the calls were required to properly configure the inputs. Oddly It remains required to call GPIOPinTypeComparatorOutput() /GPIOPinConfigure(), again blows holes in the typical GPIO pin MUX schema of peripherals on APB/AHB.

Yet the comparator inputs do not require a call to PinTypeComparator() to enable the peripheral MUX and are configured via ComparatorConfigure(). So can we assume the external C0+ (PINO) defaults to (PC6) as an (analog input) even though it is shown as an Alternate on the GPIO MUX tree out to the MCU package pins?

GPIO datasheet text claims the MUX pin direction (ALL PINS) default to input and mentions as un-configured high impedance state but does not state special function pins will default to Analog/channel inputs of MCU package pins. That seems some of the confusion around the Pin MUX table 10-2 every time I see it and read GPIO registers text leave out info about analog or special pins. The analog comparator text does not state it to be a special function yet only the (inputs) are listed as such in Table 10-2 hence the confusion of MUX calls.

Could it be a special function since the outputs are not analog ? do we assume they are digital OUT or HW analog peripheral? Logically the AFSEL bit MUST be set for any Analog peripheral pin function which are alternates of GPIOAMSEL defaults. So the GPIODEN bits are thus cleared POR defaults. GPIOAMSEL bits are cleared POR as Analog mode Disabled. Likewise GPIOAFSEL bits are cleared POR default for being MCU package pins as GPIO register controlled pins.

10.1

GPIO signals have alternate hardware functions. The following table lists the GPIO pins and their

analog and digital alternate functions. The digital alternate hardware functions are enabled by setting

the appropriate bit in the GPIO Alternate Function Select (GPIOAFSEL) and GPIODEN registers

and configuring the PMCx bit field in the GPIO Port Control (GPIOPCTL) register to the numeric

encoding shown in the table below.