TM4C129x GPIO init sequence.

In general - as I suspect you know - (most all makers') MCUs awaken w/GPIO's defaulting to Input Mode. This presents (usually) a high impedance to external devices connected to the GPIOs.   Your external device attachments must "accept" this "float" condition while the MCU is "blind & initializing."

In firm's/my experience - the method you present will produce "blip/glitch-free" results upon the GPIO. Such can easily (and quickly) be confirmed via a scope attachment to the GPIO - set to trigger upon (any) port activity.

It is possible to add pull-up/down resistors to those (external) device pins deemed, "sensitive."   (certainly any power device pins should be so treated!   Most Power FET gate driver ICs include these - and we've (never) noted an issue!)

It is (even) possible to employ those pull-up/down devices from a, "Controlled, Active Source" so that the effect of those resistors is limited to the (brief) time that the MCU has not completed its GPIO initialization...  (completion of MCU init. then "floats" those pull-up/down resistors)

The TM4C129x GPIO pins default to tristate on power up. To be glitch free the consideration starts before the device leaves reset. While in reset the pin voltages will be be determined by external pull up/downs as the internal pull up/downs are disabled and the pin pads are too.
So look at the electrical characteristics in the back of the datasheet and also whatever the external device is connected to (for input leakages and desired voltage levels) and this will tell you the rough maximum value of resistor you can use for a pull up/down and have guaranteed voltage levels. Below a certain power rail voltage the reset device should be holding things in check anyway.
After the MCU leaves reset set the required GPIO module/s up first. As per Amit's recommendation that goes like this:

1. Disable the clock to peripheral (it could be a warm reset and not from cold power up)
2. Reset the peripheral
3. Enable the clock to peripheral
4. Wait for the peripheral to be ready
5. Enable the peripheral configuration and the peripheral.

The sort out your pin configurations next. And finally, set your IO pins to be in the correct idle state before you un-tristate them.

Hi Pete,

"Like" your crisp detail - especially the "import" of Amit's recommended GPIO init. sequencing. (pity that's not - FAR MORE NOTED/AVAILABLE w/in the otherwise WASTED Red Stripe - atop the forum.)

Might you further detail your, "Below a certain power rail voltage the reset device should be holding things in check anyway." Of which device are you speaking - and how do we know (for sure) that it's been reset? (or has such facility?) All else quite clear - that sentence (may) require some "tuning."

It sounds like the 4 lines of code I listed in the original question would be correct to initialize the output pins correctly without any glitches.  I know the CPU starts up withthe pins in "high Z" and what I did was enable the port with SysCtlPeripheralEnable(); then configure the output type / drive with GPIOPadConfigSet() and then I write the initial values to the port with GPIOPinWrite() but this shouldn't happen since the pins are still high Z and then finally the function GPIOPinTypeGPIOOutput() should assert the pins to the initial value.  

I know there are a few different API calls to configure the I/O pins as outputs but I wanted to see if what I did is the recommended method.

Doug

Might the (temporary) use of an external, high-value pull-up/down resistor, tied to subject GPIO pin AND scope monitored - (convincingly) put your concerns to rest?

From the point of view of operation from the MCU's perspective my above post is what I've found to date of how best to initialise the ports. This has been refined with Amit's help and by reading the datasheet from one end to the other (I'm assuming that TM4C1294 is similar enough to TM4C129x here) . Notice that I wrote the sequence in plain English without reference to anything else. The reason for this is that if you read the datasheet, consult Amit and combine all that you read, it's what you arrive at. However, if you step through some (most?) of the Tivaware examples and watch what happens at low level they're often different and (from what I've seen of the USB examples) to some degree ignore what's in the datasheet, especially when it comes to writing reserved bits in registers. Not waiting for a peripheral to be ready is also very common and in some cases exclusively the case. So, as people have used Tivaware enough to hopefully note a problem, does not waiting for a peripheral to become ready really matter?If it doesn't why include a register that tells you if it is or not?

All the required routines are in there, just they never seem to use them all. This does make me wonder how forward compatibile TI's code base will be ( if what's in the datasheet about preserving the state of reserved bits is correct, ......and why shouldn't it be) when for the sake of doing it right in the first place you'd end up with something not open to discussion and more robust.

From an external point of view it depends on at what voltage level the MCU can actually becomes 'sane' (see datasheet) as below a certain voltage level the port pins may not have actually become tristate yet, I've not tested it that far yet, and really because in important applications I design the hardware so that an external reset device controls the whole show and locks out any harware that might not like signals being thrown about before the big fat chip has gathered its marbles. This also means that the reset device can be individually tested and then applied to further designs.