Why GPIOPinConfigure versus GPIODirModeSet to assign GPIO pin to named AFSEL peripheral.

Hi Amit / CB1

Data sheet GPIO Register 22 0x52c most bits in the GPIOAFSEL are GPIO ports by default after POR. That explains why we don't see GPIOPinConfigure() being used after setting the GPIODirModeSet() with IN or OUT.

That changes when an peripheral other than GPIO is desired. Then both are required to set the GPIO pin Mux to the specific peripheral Port pin. Most all the GPIOPinTypeXXXXXX() driver lib commands are not setting REG 22 peripheral because most are GPIO related pin assignments in the GPIOAFSEL. Never connected the dots in the past being it most always was a GPIO port pin selection those times and ADC/PWM configure are calling GPIOPinConfigure(). The problem occurs when there is no library command to set a alternate peripheral function to an external pin it has to be done manually in three steps.

Been trying for long time to select the PWM0 external fault pin 71 on the LM3S8971. Now setting AFSEL 0x420 HW direction followed by setting REG22  0x52c via GPIOPinConfigure(FAULT_PERIPH).

Why is this not working?

// Make GPIO PB3 Pin71 the PWM0 fault input (AFSEL).
   GPIODirModeSet(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_DIR_MODE_HW);
// Set PB3 with a weak pull down for the PWM0 fault input.
   GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPD);
// Configure the peripheral (REG22 0x52c) signal for pin 71 
   GPIOPinConfigure(FAULT_PERIPH);

BP101 said:

Hi Amit / CB1

You perchance - rang?

Was locked out from the forum for past 4 hours - just now was (allowed) to log in.

Here's the code which enabled our setting of the PWM Fault input - this for LX4F under Stellaris 9453.  (last ver. which supported LX4F)

     ROM_GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_2);
     ROM_GPIOPinConfigure(GPIO_PF2_M0FAULT0);      

Hi CB1 & Amit

Thanks, seems that one is completely different name for LM3S8971.

PWM0 fault pin is confirmed working. The problem was compare 2 integers <> a given sample value. The CPU was running over 121% when first started to debug that compare code to determine the ADC sample values.

New method code compare  (top) stops continuous true. The old method below that stopped working after moving the ADC_Trigger_Processor out of the called function. That may be why Trigger_PWM0 was also not working with ADC0 SS2. Unclear is PWM fault INT 25 was not firing or NVIC would not allow it to. SS2 and PWM0_Fault had the same priority level 0x40 and SS2 has a higher interrupt number seems to have violated the priority rule. In that case the lower interrupt should of had priority at least in the TM4C world priority group 4.

 if(g_ulAnalogVoltage < 9457 > 9739) //stops continuous true

 if((g_ulAnalogVoltage < 9457) || (g_ulAnalogVoltage > 9739)) //true all the time

Hi Amit,

Good to know the GPIO mux pin register (GPIOPinConfigure()) needs to be configured ever a pin changed direction HW that by default is GPIO SW mode. Seems redundant pad mux is not more intuitive in that 2 registers have to be programmed in that case. Possibly the DEN bit LM3S was not OR'd with the peripheral pin selection. So when the HW direct, AFSEL modes were set that did not automatically set the GPIO pin mux to reflect the change. We had to then call GPIOPinConfigure() to set REG22 0x52c GPIOPCTL.

Question: TM4C analog comparator digital output pins are not by default SW control GPIO mode? Tivaware GPIOPinTypeComparatorOutput() does not call GPIOPinConfigure() after setting the direction mode to HW. The output of the analog comparator is (digital) requires to set REG18 GPIODEN bit 1?

There is no TM4C GPIO default pin mode table in the datasheet as in LM3S data sheet. Without that table in the LM3S would never have put it together Pin71 was by default SW mode. TI/Tiva PinMux tools makes the very same assumptions. Perhaps a yellow high light GPIO pins that default to SW mode on POR might shed some light on what code is required beyond what is being automated.

Hi Amit,

>"GPIOPinTypeComparatorOutput does not call and does not need to call GPIOPinConfigure"

But why --- stated in TM4C1294 datasheet (yellow) most pins default to GPIO SW mode. You knew I was going to ask that question.

I know GPIOPinConfigure() is a separate call in Tivaware. How do we know when to call GPIOPinConfigure() -- by what (table) in the data sheet leads us to that deduction? Seems Tiva PinMux tools is only doing half what is required, for example programming the digital comparator output it negates GPIOPinConfiure() for what ever reason. It seems GPIOPinConfigure() is required by what the datasheet states below.

Table (10-4 GPIO pin examples) may be missing a GPIOPCTL column (reference 10.3.3) that would help to clarify if for example the digital comparator output, we also need to call GPIOPinCOnfigure() in the application.  GPIODirModeSet() sets AFSEL 0x420- and with HW mode DIR 0x400 but does not set GPIOPCTL REG22 0x52C set in GPIOPinConfigure() which must be set when ever AFSEL is selected.

Register 22: GPIO Port Control (GPIOPCTL), offset 0x52C
The GPIOPCTL register is used in conjunction with the GPIOAFSEL register and selects the specific
peripheral signal for each GPIO pin when using the alternate function mode. Most bits in the
GPIOAFSEL register are cleared on reset, therefore most GPIO pins are configured as GPIOs by
default. When a bit is set in the GPIOAFSEL register, the corresponding GPIO signal is controlled
by an associated peripheral. The GPIOPCTL register selects one out of a set of peripheral functions
for each GPIO, providing additional flexibility in signal definition.

Sorry Amit,

Tiva PinMux tool did add GPIOPinConfigure() for the analog comparator digital outputs. Seems it must call it after all.

But it didn't call GPIOPinConfigure() for the analog comparator inputs.

Hi Amit,

>" Analog pins do not need GPIOPinConfigure as it is not GPIOPCTL based"

So table 10-4 shows us the analog comparator input is default AFSEL 0, DEN 0 and Table 10-4 is not just an example rather the POR defaults table?

But then again the analog comparators have digital outputs and use a GPIO port pin for the SW mode of the peripheral. Table 10-4 shows that AFSEL 1, DEN 1 so we use GPIOPinConfigure() only for the digital output? Seems to me all analog inputs start out as GPIO default SW mode until the direction is changed to HW but how does the GPIO pad know that unless we issue GPIOPinConfigure()? Many Tivaware driverlib calls state it must be called after the GPIO pin assignment. 

That is why a table is needed to visually show GPIO pins default mode SW or HW as text states (most GPIO pins). Just what does the word most imply is debatable. Seems you take the word most to excluded all analog input pins that share a GPIO port pin. Where in the datasheet is it clearly stated that certain GPIO pins are not by default GPIO in SW mode after POR?   

Naming table 10-4 "GPIO Pad Configuration Examples" is not exactly confirming certain pins don't fall under the (most) GPIO pin SW mode category on POR. Seems to me Table 10-4 shows the required configurations for peripheral modes that share GPIO pins and that (may or may not) default to SW mode on POR. Who really knows, table 10-4 shows only the required configurations not the default POR configurations. 

Then we have this claim that seems to infer we always call GPIOPinCOnfigure after changing peripheral direction to HW.

GPIOPinConfigure:

//! Configures the alternate function of a GPIO pin.
//!
//! \param ulPinConfig is the pin configuration value, specified as only one of
//! the \b GPIO_P??_??? values.
//!
//! This function configures the pin mux that selects the peripheral function
//! associated with a particular GPIO pin.  Only one peripheral function at a
//! time can be associated with a GPIO pin, and each peripheral function should
//! only be associated with a single GPIO pin at a time (despite the fact that
//! many of them can be associated with more than one GPIO pin). To fully
//! configure a pin, a GPIOPinType*() function should also be called. 

Hi Amit,

The GPIOPCTL register selects one out of a set of peripheral functions for each GPIO, providing additional flexibility in signal definition.

What is considered (the set of functions) of a peripheral that require GPIOPinConfigure or what BITS confirm when to call it.

Does the GPIO assigned analog comparator inputs fall under that same category of peripheral functions. Perhaps when DEN=0, AFSEL=0 exclude all  peripheral owned functions shown in Table 10-4? Simply saying that the comparator input/output pin is analog makes no sense when using the datasheet table 10-4 or simply reading the Tivaware Doxygen text. Seems plausible to call (GPIOPinConfigure) in all cases when the datasheet is not handy to confirm its proper use.

More simply:

AFSEL=1, DEN=1, GPIOPCTL=1 :GPIOPinConfigure is required?

AFSEL=0, DEN=0, GPIOPCTL=X :GPIOPinConfigure is Not required?

Hi Amit,

Understand reasoning for not listing each and every PCTL mux value in the column. That don't mean we can't associate a (true/false/x=don't care)  column in table 10-4 to indicate register 22 presence. At the very least add more clarity to the text so people don't believe the peripheral owns the GPIO pin after the AFSEL association is changed to HW mode. That becomes especially relevant in the wording that (most) bits in the AFSEL default to GPIO SW mode. Again that misleads to modify association only have to change AFSEL/DEN bits. Seems someone at TI purposefully went out of their way to make changing GPIO pin ownership overly complicated where simplicity was the intended goal.

You have shed light on what was interpreted as completely different peripheral behavior.

Many thanks! :)