Can 3.3v tolerant GPIO use a WPD and single series R to limit binary H below 3.3v.

Are "binary" and "high" required - back to back - as you've so strongly adopted? Few other posts here/elsewhere evidence that unique word treatment.

Cost/size/assembly savings pale when employing a, "resistor pack" - which enables you to meet your divider voltage levels - even when the MCU is unpowered or is within Reset.

Months back I listed an 8 channel device - from this vendor - which enables excellent voltage translation. If you ask - I'll post that part ID again.

You speak of +5V gate driver - and note that it, "rides at or just below +3V3." Was that what you meant to write? The "gate drivers" I know you and I to employ usually - but not always - receive their input signals from an MCU - and output at (translated) voltages (far higher) to turn-on power FETs.    Staff/I know of no gate driver, "Riding at or just below +3V3!"

Might you have intended - instead - logic ICs operating from older, 5V supplies? I doubt they too - "ride at or just below +3V3..."

Hi Amit,

Interesting fact is the GPIO pins are tri-stated and the GPIO tri-state event will be asserted until when exactly?

1. After the GPIO peripheral is enabled? 

2. Regarding GPIO port M and L; Port L QEI has been enabled with a pull down and M for Hall type inputs. Modified GPIOPinConfigure() to allow PinType to be passed in the function call. Perhaps an Tivaware upgrade from always defaulting to ~~_STD_WPU and allow us to input the exact pin type during (tri-state) in stead of assuming to always be WPU?

Register 16: GPIO Pull-Down Select (GPIOPDR), offset 0x514
The GPIOPDR register is the pull-down control register. When a bit is set, a weak pull-down resistor
on the corresponding GPIO signal is enabled. Setting a bit in GPIOPDR automatically clears the
corresponding bit in the GPIO Pull-Up Select (GPIOPUR) register (see page 776).
Important: The table below shows special consideration GPIO pins. Most GPIO pins are configured
as GPIOs and tri-stated by default (GPIOAFSEL=0, GPIODEN=0, GPIOPDR=0,
GPIOPUR=0, and GPIOPCTL=0). Special consideration pins may be programed to a
non-GPIO function or may have special commit controls out of reset. In addition, a
Power-On-Reset (POR) returns these GPIO to their original special consideration state.

    // Enable pin PL1 for QEI0 PHA0 input WPD 3.3v maximum high level
    // Velocity reporting & quadrature phase;
    ROM_GPIOPinConfigure(GPIO_PL1_PHA0);
    ROM_GPIOPinTypeQEI(PIN_ENCA_PORT, PIN_ENCA_PIN, GPIO_PIN_TYPE_STD_WPD);
    //
    // Enable pin PL2 for QEI0 PHB0 input WPD 3.3v maximum high level
    // Quadrature phase detection;
    ROM_GPIOPinConfigure(GPIO_PL2_PHB0);
    ROM_GPIOPinTypeQEI(PIN_ENCB_PORT, PIN_ENCB_PIN, GPIO_PIN_TYPE_STD_WPD);
    //
    // Enable pin PL3 for QEI0 IDX0 input WPD 3.3v maximum high level
    ROM_GPIOPinConfigure(GPIO_PL3_IDX0);
    ROM_GPIOPinTypeQEI(PIN_INDEX_PORT, PIN_INDEX_PIN, GPIO_PIN_TYPE_STD_WPD);

BP101 said:

One would think TI has LAB tested series R/WPD to know is a safe or not recommended so keeping parts count minimal

My friend - you should know that such (weak) programmable, pull-up/down resistors are of similar values - across the 4 other ARM MCU - vendors we employ.   Thus your "lab testing direction" should be "broad-based" (wide) - rather than "beamed" (narrowed) - should it not?

Might it be also that such "weak/programmable" internal resistors are intended to prevent an MCU input from "floating" - and are not intended as, "beasts of burden" - as is your, desire du jour.   And - these "weak" chip resistors are intended to "give way" to proper, external input signals - introduced at the MCU's GPIOs.   (this explains their "weak" designation.)

As I recall - these resistors are drawn from IC library cells - and are (rarely) intended to carry much current.   (you must think from the vendor's "million-chip perspective - cram the maximum number of parts on a wafer" - not from your, "Someday (maybe) I'll get to production!"    Again - Lone Ranger thinking often proves too limiting - and "blocks" reality!)  

Your voltage translation issues are classically best managed via:

• choosing devices which power from - and output at - compatible voltage levels
• employing multi-channel voltage translators - as produced by this vendor/others - when you choose not to comply w/the above!   Semi firms are "big time" - they're too smart to invest in, then engineer a device that has little, "raison d'etre."  

This horse was solidly beaten a month or so past (right here) - wounds barely healed - he's again saddled - and he (still) ain't likely to run fast - or far...

Here's a little goody I use a lot:

Not so much disagree with any part yet offer food for thought of why external R may or may not be enough to protect the +5v unprotected GPIO pins. Others fowling similar madness have jumped off the very same bridge for what reasons remain a mystery. That reason should be disclosed in the TM4C datasheet. Other words educate us as to why removing +5v GPIO pin protection benefits external architectures built around the TM4C1294NCPDT. How that removal of +5 GPIO pin protection adds value plus cost savings in production runs there surly must be some explanation other than we just didn't think of that. 

1. Vendor removed +5v GPIO protection makes it appear that +5v GPIO restriction is easily corrected by internal HW and SW.

2. Vendors removal of +5v GPIO pin protections apparently did not consider migration a factor for (reasons) not fully (explained) in the datasheet.

3. The signal currents GPIO internal WPU/WPD are mostly in the micro or nano amp range seemingly pose no danger to CMOS input gates.

4.  Datasheet explains GPIO pins are Tristate (until otherwise configured); Hardly enough detail or explanation of when (exactly), what register (0x000) programming does the Tristate mode become removed? 

5. Tivaware GPIO pin assignment register programming comes before adding WPU or WPD assignments otherwise the GPIO has neither on POR. The SW is not structured to apply any WPD or WPU as a first step measure so the detail of GPIO pin (Tristate) is paramount. Will first setting WPU or WPD have any effect on (Tristate) GPIO pin? All good questions with no explanations revolve around vendor removing 5v GPIO pin protections.

6. Adding SW has always been the reasoning to win the war for removing costly HW when it is not (specifically) needed.  

My "level translating obsessed" friend - does your protest not suggest that you'd benefit from expanding your search to "more accommodating" MCUs?  (they do exist)

As a public service (and in satisfaction of my "work-release") - I relist vendor's, "SN74LVC4245A" Octal Bus Transceiver which exhibits superb voltage translation capabilities.   Device is prominent w/in:

• ECG
• CT scans
• X-Ray: Medical/Dental/Baggage Scanners
• Software Defined Radios
• High Speed Data Acquisition

Device succeeds in "both directions" (3V3 -> 5V & 5V - > 3V3) & allows independent "tweaking" of each side's supply voltage...

Robert,

We gutted an "enemy machine" to better gauge, "What, why, how" and the part I listed revealed.

Do feel free to, "Make the case" for the device you've listed...   (my suggestion was not "end-all - be-all")

Robert,

Device you listed is vendor's "wide-body" and is 16 bit.   I proposed 8 bits - moving Brett's ball more slowly/cautiously to the goalposts...

Cb1, Aha! The SN74LVC4245A shows up, the previous one mentioned did not (check the spelling, a few letters got transposed)

The SN74ALVC164245 is listed as an 8 bit device on Digikey, I didn't notice the fact it was listed as 2 channels of 8 bits. The perils of skimming


Robert

@Robert,

If the "big guys" ain't "going discrete" - and we seek to "please investors by out-performing the market" - then our "sourcing/procurement" dept. "hitches to "big-guys's wagon..."    This - (almost) justifies our avoidance of, "Reinventing the search/source/test/verify" requirement - proving worthwhile & great time/cost/effort saver!

Discrete solution (may) be acceptable for 1 or 2 channels - beyond that - proper IC proves "no brainer."

@Both fellows,

Nice IC yet the real question is will it fit it's fat axe in the space of the 3 R's.

Possibly one alternative to adding more WH HW is to fix the SW so it don't enable the GPIO pin until after the WPD is installed. The question remains tabled does the WPD assert remove Tristate one clock cycle after asserting the ui32PinType? A clock diagram of the GPIO might explain when the Tristate is removed.

/* Configure the GPIO pin type for digital inputs with WPD 3.3v max high level. */
 ROM_GPIOPinTypeGPIOInput(GPIO_PORTM_AHB_BASE, GPIO_PIN_0, GPIO_PIN_TYPE_STD_WPD);
 ROM_GPIOPinTypeGPIOInput(GPIO_PORTM_AHB_BASE, GPIO_PIN_1, GPIO_PIN_TYPE_STD_WPD);
 ROM_GPIOPinTypeGPIOInput(GPIO_PORTM_AHB_BASE, GPIO_PIN_2, GPIO_PIN_TYPE_STD_WPD); 

void
GPIOPinTypeGPIOInput(uint32_t ui32Port, uint8_t ui8Pins, uint32_t ui32PinType)
{
    //
    // Check the arguments.
    //
    ASSERT(_GPIOBaseValid(ui32Port));

    //
    // Set the pad(s) for standard push-pull operation first setting pin type.
    //
    GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA,  ui32PinType);

    //
    // Make the pin(s) be inputs.
    //
    GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN);
}

void
GPIOPadConfigSet(uint32_t ui32Port, uint8_t ui8Pins,
                 uint32_t ui32Strength, uint32_t ui32PinType)
{
    uint8_t ui8Bit;

    //
    // Check the arguments.
    //
    ASSERT(_GPIOBaseValid(ui32Port));
    ASSERT((ui32Strength == GPIO_STRENGTH_2MA) ||
           (ui32Strength == GPIO_STRENGTH_4MA) ||
           (ui32Strength == GPIO_STRENGTH_6MA) ||
           (ui32Strength == GPIO_STRENGTH_8MA) ||
           (ui32Strength == GPIO_STRENGTH_8MA_SC) ||
           (ui32Strength == GPIO_STRENGTH_10MA) ||
           (ui32Strength == GPIO_STRENGTH_12MA));
    ASSERT((ui32PinType == GPIO_PIN_TYPE_STD) ||
           (ui32PinType == GPIO_PIN_TYPE_STD_WPU) ||
           (ui32PinType == GPIO_PIN_TYPE_STD_WPD) ||
           (ui32PinType == GPIO_PIN_TYPE_OD) ||
           (ui32PinType == GPIO_PIN_TYPE_WAKE_LOW) ||
           (ui32PinType == GPIO_PIN_TYPE_WAKE_HIGH) ||
           (ui32PinType == GPIO_PIN_TYPE_ANALOG));

If you can level match 8 channels with 3 resistors I'm impressed. The single channel version ( SN74LVC1T45DBVR ) is a SOT-23 case.

Robert

Forest must remain (somewhat) visible thru the trees.

Those suggesting normal/customary "voltage translator" - to professionally solve your issue - are rejected due to board's (arbitrary) dimensioning - done prior to your full understanding of the issues & requirements of such translation.   That cannot be (our) fault - can it?

Realize too that it takes time for the MCU to, "come out of power-up, and/or other resets" - and on each/every one of these occasions - you are potentially damaging those over-stressed GPIO pins.   (i.e. the software ordering those pins to switch in "weak pull-downs" has not yet executed!)   From my experience at another giant semi firm - those stresses may not cause "instant death" but are likely to cause cumulative damage - which in time - will (likely) lead to that pin's "out of spec" performance.   (often failure)

If the case has not been solidly made in favor of "pro" (vendor designed, multi-channel, voltage translators) I surrender.   Those here bear no responsibility for a board designed "too small" and w/out benefit of an exhaustive search of normal/customary design methods - used by those w/long/focused experience...

BP101 said:

+5v external power to the devices that sometimes might supply TTL signals into the GPIO inputs

And you'll - AT ALL TIMES - be able to control this switching action!   Really?  

You cannot count upon the MCU to do this - especially when it "Resets."   

Let the "bandaid parade" march on - surely you can hire a brigade (at least a platoon) of skilled programmers to log, revise & perfectly recall each/every "nook/cranny" so that the "premature board design" may, "live long!"   (yet w/out a healthy MCU - likely victimized by "space saving!")

That 4v ABSM is shown in the electrical characteristics page 1820 fig 27.3.2 for High level GPIO input voltage. By definition tristate infers the I/O pin will not allow logic level voltage into the silicon rail. That is what high impedance state means or has until some one defeated the definition by adding diodes on the pin into the rail when there should be an MOV. In that way current can not flow into or from VDD unless it is High voltage say over 1Kv or so. The pin on the bus is in high impedance state not just the GPIO pad.

Beat this dead horse (few more) times. We doubt it will move. You've got a solution at hand - must Amit (personally) leave his position here - and design your new (proper) board?   Might that - at last - satisfy.   Really - what's your point?    Uncle...

>Every manufacturer calls the state with output drivers disabled tristate.

Every manufacture then needs to clearly disclose such facts in the section topic of GPIO pins (call it disabled tristate). Perhaps one day they will consider B2B diode or discover new processes how to incorporate MOV on said defeated pins. It is quite clear in tech writers mind the TQFP pin is not directly related to the GPIO tristated pad. Evidence the many hindering diodes of death disclosed far back in a later chapter.

Hi Amit,

That would not seem the same truth in a standalone IC at least in circuit designer mind. When IO (pins) are in high impedance state they don't interact with the external bus. OE renders the outer bus pins completely transparent to the external surrounding bus in all aspects. So even if +4.95v was present on the external bus pins, in the circuit designer mind the internal rail did not interact to the external high impedance bus pins. Better yet how could any applied external pin voltage ever interact with internal rail if the external pin was in high impedance state of several hundred megohms. 

The GPIO pin ESD protection diodes twist the accepted understanding of high impedance bus pins. Perhaps the datasheet GPIO section could mention the external TQFP128 package pins are not completely in high impedance state from the external bus even when the GPIO pads are in high impedance state. Accident avoidance in the absence of bidirectional TVS/MOV pin protections.

Thank you for bringing ESD diodes into the conversation and other very important points. 

BP101 said:

. OE renders the outer bus pins completely transparent to the external surrounding bus in all aspects.

Simply not true. I have never seen any IC for which this could be claimed.

Robert

>Simply not true

We were discussing the aspects of bus voltage and not current, so not every aspect is being claimed in that bold statement.

What do you think allows multiple IC outputs to share a common bus. The high impedance state of the pin disconnects it from the shared bus.

A few TI stand alone multiplexers have an OE also at the input side. The point being made is external (voltage) can not flow into the pin when it is in the high impedance state even when it is an bidirectional bus driver. Pin injection current yet another story separate from supply voltage powering the MCU.

Must admit Stellaris LM3S even with +5v GPIO pins an applied input voltage could magically power the internal LDO, ever the 3.3v VDD was disabled 

Why is the internal LDO not fully isolated from the GPIO peripheral MUX pad, pins and PD's seems more the question.

BP101 said:

not every aspect is being claimed in that bold statement.

all aspects is pretty inclusive, it doesn't leave much room for interpretation.

BP101 said:

The high impedance state of the pin disconnects it from the shared bus.

No. It does not do that on any implementation, it simply disables the output driver.

All implementations limit the voltage on the bus that the bus will remain isolated to some (small) value above the common Vcc. The closest to an exception are 5V tolerant inputs and some I/O devices (some CANbus drivers come to mind) that are designed to which allow slightly higher voltages.

There is always a maximum voltage beyond which they will not work and for devices on a digital bus, it's quite low. Communication busses tend support higher voltages.

Robert

>No. It does not do that on any implementation, it simply disables the output driver?

We must agree to disagree on terms, a lay term effectively disconnecting pin from bus being the pin impedance is several hundred megohms. That does not directly infer (mechanical) disconnection from the bus.

So the external GPIO pins are not tristated as they should be. Therefore the internal protection diode VDD rail are effected. That seems a lax and improper pin mux design on TI part. Other visual figures through out TM4C datasheet supported that (earlier) assumption. 

Example: The Tiva PinMux tool all GPIO ports/pins are depicted in the very first column. That misleads or gives the perception each pin is directly connected to the outside world with no mention of diodes on the VDD rail. Datasheet, states the GPIO port is tristated again infers high impedance mode. Fig 19-1 TQFP128 pin labels list the GPIO port pin names with a decimal pin number makes it appear as if the tristate GPIO connects to the pin. Both these seriously lax representations to present the facts as they actually are in reality defy accepted and typical industry standard bus behavior! Why would anyone ever go to this extent this forum to inform TI how devious it appears to hide the true facts to the designer.

Once again back tracking finding facts out 3 years later. LM3S8971 datasheet completely leaves out any mention of PWM Generator Legacy Fault mode in the discussion PWM external fault pin 71. That mode it seems must be configured to each generator regardless if the PWM Fault INT25 is enabled or not. According only to text found in the driver library the external fault pin 71 and Legacy Generator Fault mode are independent of each other. Once again the visual diagram shows the fault pin leading directly into each dam generator. Yet no mention in datasheet legacy fault mode must fist be SW enabled order to cut off each generators PWM drive into the control block. That is a very important fact left out of the PWM section of datasheet. That find this week seriously has upset me when a program change to ADC of many others locked the Ethernet GUI from connecting to the RDK. Has taken several days to uncover what and why. To make matters worse LMI originally used the PWM fault pin 71 for an external push button port previously removed by me for PWM fault cut off. RDK is a dang BLDC motor controller, what were LMI guys thinking. They even used a required and only analog comparator for GPIO Halls inputs. Not everyone is on the same page it seems!

The word assume is left to mayhem.