This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294KCPDT: Experiment outputs to analog

Guru 56308 points

Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: INA240, TIDA-00778, UCC27714

Hi Bob,

Bob Crosby said:
While the switches are good at isolation, they are not perfect. To avoid analog input pins which are not being used by the ADC from creating noise on the analog multiplexer, the additional isolation circuit was added.

Disabling the comparator XOR output barrier Co1,2,3 configuring for Analog/HW peripheral direction allowed guessing  90v++ surge entered the I/O pad. Needless to say blew fuses but was part of troubleshooting a much larger issue of PWM gate drivers failures. Such failure lead to high voltage being created in motor phases and POR'd the MCU each and every time the peak rose just above 90v. It was assumed the surge was entering GPIO I/O pad via comparator (Cn-/+) inputs.

Can you elaborate on why the XOR gates in the comparator are not configured by GPIOPinTypeComparatorOutput() for HW peripheral, e.g. DEN bit are being cleared versus setting AFSEL bits REG-10 (0x420)? Also how could configuring Analog / HW for the output somehow circumvent the (Cn-/+) input isolation barrier you earlier described and allow 90v surge to enter and destroy the comparator outputs? 

All our Tivaware driver libraries (gpio.c) have GPIOPinTypeComparatorOutput() configured (Output) direction clearing DEN bits REG- 2 (0x400), not setting AFSEL bits. Perhaps the change was made here some time ago yet it is opposite to what section 22.2 datasheet states the AFSEL bit should be set. 

Perhaps it is not a peripheral as datasheet section 22.2 claims and is actually Special Analog? Ralf may have answered part of this question earlier via consult with (Amit) but that too seems a vague answer in the resolved context you provided.

  • BP101,
    The analog isolation circuit for the ADC input pins is to minimize the impact of digital signals on ADC converter input pins from AC coupling across the analog multiplexer and disturbing the voltage on the ADC sample capacitor. Never is it stated or implied that there is high voltage isolation on any TM4C pin. The absolute maximum rating for all TM4C1294KCPDT IO pins except PB1, whether used as an analog input or GPIO, is 4V. PB1 is 5.5V.
  • Hi Bob,

    Again we are quite aware of that datasheet misnomer implied as a maximum electrical specification for ADC inputs. I was referring to the DC bus voltage (24v) had spiked over 90v, not the analog comparator inputs. It is possible when the barrier was disabled made (Analog) it simply allowed excessive low voltage into the outputs, the inputs seem functional in debug.  Yet that was not specifically the question being asked in this post.

    Specification table 27-58 implies the measurable VINP, VINN, CMM voltage range is limited as are ANIx inputs tolerated above 3v3 rail. BTW analog comparator inputs worked ok EKXL launch pad prototype DC inverter. ADC0 often measured spikes on the DC bus (not the analog input) in excess of 60vdc Regarding note (C); the Cn- inputs are held (1v223) and one Cn+ input is external VREF (2v6). There are PWM spikes riding on along analog ground also enter the +VREF C0+ input forcing higher setting.

    If you read the ADC section it states voltages in excess of 3v3 rail will be ignored by ANIx pins, LM3S89x datasheet stated the very same text. Why would there different limitation on the analog comparator inputs to that of ANIx inputs? They both are perceived as being part of the GPIO analog I/O pad by anyone reading this datasheet. Hence why it is very important the data sheet clearly identify where or how the comparator inputs differ from the ANIx analog architecture by including it in figure 10-2. 

    No answer relative the peripheral question GPIOPinConfigureOutput() not being configured HW and not setting the GPIOAFSEL bits per section 22.2 of datasheet? According to datasheet the HW direction selects AFSEL bits not Output direction. Not pointing fingers but Co1,Co2,Co2 ain't rightly configured as Out direction?

    22.2

    The column in the table below titled "Pin Mux/Pin Assignment" lists the possible GPIO pin placements for the Analog Comparator signals. The AFSEL bit in the GPIO Alternate Function Select (GPIOAFSEL) register (page 768) should be set to choose the Analog Comparator function. The number in parentheses is the encoding that must be programmed into the PMCn field in the GPIO Port Control (GPIOPCTL) register (page 785) to assign the Analog Comparator signal to the specified GPIO port pin.

  • BTW: INA 240 outputs drive analog comparator Cn- inputs via series 1RK and enter parallel MCU inputs, isolated ANIx inputs via 100R/220pf decoupling to ground. So there is some protection but have noticed peaks above 3v3 far from MCU pins at INA240 outputs. Had tested 100R series to Cn- and Schottky diodes +3v3 rail at the Cn- inputs and that caused missed trip events.

    Wonder if there is TI PDF showing best practice circuit designs for the MCU analog comparator Cn-/Cn+ inputs?

  • BP101 said:
    No answer relative the peripheral question GPIOPinConfigureOutput() not being configured HW and not setting the GPIOAFSEL bits per section 22.2 of datasheet?

    Sorry, I missed this question in your thread.

    The configuration of the alternate function register is done by the TivaWare routine GPIOPinConfigure(). They probably separated that function from the GPIOPinTypeComparatorxxx functions because the alternate pin functions are dependent on the part you are using. They are defined in the header file pin_map.h. Configuration of pin PD2 as comparator 2 output then requires calling two TivaWare functions.

        // Configure the GPIO port for the comparator 2 output
        GPIOPinTypeComparatorOutput(GPIO_PORTD_BASE, GPIO_PIN_2); // PD2 is C2o
        GPIOPinConfigure(GPIO_PD2_C2O);
    

  • Hi Bob,

    I think you missed my point again. Point is GPIOPinTypeComparatorOutput() is not setting HW direction in the Tivaware library 2.1.1.71 and earlier. Was that corrected in later driver lib versions from Output to HW direction? GPIOPinConfigure sets the GPIOPPCTL register bits (x) in the MUX and typically gets called for peripherals that set the AFSEL bits for GPIO pins. The HW or OUT/IN direction class determines which register gets configured in GPIO, either AFSEL or DEN.

    My point: Perhaps there is a difference between the TM4C123x and TM4C129x analog comparator structures. One being a peripheral and the other not being a peripheral. That might explain why GPIOPinTypeComparatorOutput() is not setting the AFSEL bits in earlier Tivaware driver library calls.

    What is going on here with this call setting the direction to OUT versus HW for a peripheral?
  • I compared the source code lines of the function GPIOPinTypeComparatorOutput() between version 2.1.1.71 and the current version 2.1.4.178 using Beyond Compare. There are no differences. Here are the lines:

    //*****************************************************************************
    //
    //! Configures pin(s) for use as an analog comparator output.
    //!
    //! \param ui32Port is the base address of the GPIO port.
    //! \param ui8Pins is the bit-packed representation of the pin(s).
    //!
    //! The analog comparator output pins must be properly configured for the analog
    //! comparator to function correctly.  This function provides the proper
    //! configuration for those pin(s).
    //!
    //! The pin(s) are specified using a bit-packed byte, where each bit that is
    //! set identifies the pin to be accessed, and where bit 0 of the byte
    //! represents GPIO port pin 0, bit 1 represents GPIO port pin 1, and so on.
    //!
    //! \return None.
    //
    //*****************************************************************************
    void GPIOPinTypeComparatorOutput(uint32_t ui32Port, uint8_t ui8Pins)
    {
        //
        // Check the arguments.
        //
        ASSERT(_GPIOBaseValid(ui32Port));
    
        //
        // Make the pin(s) be inputs.
        //
        GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_HW);
    
        //
        // Set the pad(s) for standard push-pull operation.
        //
        GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);
    }
    

  • Hi Bob,

    Most our versions were set (OUT) direction accept (2.1.2.111) which we have yet to use but will also check the RTOS library 2.1.1.71b (gpio.c) to be sure. It (gpio.c) may have been copied from 2.1.0.12573 order to fix GPIO_AHB pin port calls above K that added in by us in 2015 also thought to be missing in 2.1.1.71.

    Thanks for confirming ACOMP peripheral should be set HW direction!
  • Greetings Bob,

    May it be noted that I too - presented that exact function code - to this poster - several weeks ago.

    I also noted the fact that the comment, 'Make the pin(s) be inputs'  was in error (outputs was intended) and surely resulted as a 'Cut & Paste' Error - stemming from the (very) similar, 'GPIOPinTypeComparator()' function - in which case those pins serve as Analog Comparator Inputs.

  • So you then agree the analog comparator is indeed a peripheral as datasheet suggests.

    That was the other point of question as to why the input pins C0,C1,C2(+/-) were exempt from AFSEL bits setting HW contrary to it being a peripheral and not directly a descendant with ANIx status in the GPIO analog I/O pad and not setting AMSEL bits in the GPIO MUX.

    Still don't know if PC6 PINO VREF works since all hell broke loose after UCC27714 gate drivers HO outputs were later discovered had mysteriously partially failed during low voltage testing and causing high voltage. After replacing 3 failed UCC gate drivers decided to replace all 12 drive resistors, thus doubling gate resistance values, double the QG shown in TIDA-00778 circuit analysis. That crazy HO does not make any sense if NFET total QG is QG the world around.

  • BTW:

    Bob Crosby said:
    The configuration of the alternate function register is done by the TivaWare routine GPIOPinConfigure().

    Bob Crosby said:
    // Configure the GPIO port for the comparator 2 output GPIOPinTypeComparatorOutput(GPIO_PORTD_BASE, GPIO_PIN_2); // PD2 is C2o GPIOPinConfigure(GPIO_PD2_C2O);

    Wonder if by calling GPIOPinConfigure() prior to making the GPIO pin type comparator output was causing some isolation barrier mayhem? 

    That reversal too was posted several weeks as the present configuration.

  • cb1_mobile said:
    May it be noted that I too - presented that exact function code - to this poster - several weeks ago.

    Yet in the context of the issue the analog comparator Cn outputs were changed from HW to OUT. Perhaps by us past discovering it stopped false VREF triggering, long forgotten why. Point of postings was to get TI to provide a better view of how GPIO I/O analog isolation barrier was disabled or had any relation at all to the GPIO MUX. Accepting without any data sheet disclosure peripheral behavior would be foolish, especially if it was perceived to be reacting oddly at times.

    Figure 10-2 does not specially make point clear as to how analog comparator (peripheral MUX block) was being isolated from the GPIO digital PAD. Nor did any text specially state how signal isolation was being achieved. 

    So it was not just a simple plug this in here and all will be fine kind of issue to begin with.