3430 Pad programming and GPIO

DavidVescovi said:

If I am using a pin as GPIO (mux mode 4) does it really matter if the pad programming is set as input or output.?

Yes, it does matter to some extent.  The selection of the MUXMODE will allow a particular module, like the GPIO, to propagate its data output signal and output enable signal to the I/O as somewhat illustrated in Figure 7-8 of the OMAP35xx Technical Reference Manual (SPRUF98).  However, you will still need to explicitly enable the input path via the INPUTENABLE of the Pad Configuration Register illustrated in Figure 7-7, if the GPIO will also be used as an input.

This is detailed in Section 7.4 of the OMAP35xx Technical Reference Manual (SPRUF98).

DavidVescovi said:

Doesn't the GPIO direction programming take priority over thr pad setting?

I.E should I always set pad to input mode 4. Then set GPIO direction register to OUTPUT (or input)?

The GPIO direction programming in the GPIO module would control the output enable signal.  However, there are more controls at the Pad level specifically the INPUTENABLE to allow that input buffer to be enabled.  Notice in the Pad Configuration Register, there is no OUTPUTENABLE, as this is controlled by the module selected by MUXMODE.

burchmere said:

1.  Is there a preferred way to set the INPUTENABLE bit of the padconf reg when a pin will be used as a GPIO output?  It seems like you're saying it could be set either as an input or output at the padconf reg (while it would have to be enabled as an output via the OE reg).

I realize this is somewhat confusing, so I hope I can clear things up.  The PADCONF register really are meant to do a handful of things.  First, configure which mux mode to use, ie. which peripheral signal can propagate to the actual pin, both input and output paths, if applicable.  Secondly, it configures things at the I/O pin like pull-up/pull-down configuration, whether those pull-up/pull-downs are enabled and the state of the pin when this device goes into an OFF state for low power operation.  In addition, the PADCONF can enable the input buffer itself.  This is independent of direction control from the GPIO module.  The INPUTENABLE does not control if the output buffer is on or off, it simply acts as a "AND gate" of the input side of the I/O pad.  If INPUTENABLE=1, it will allow the signal on the pad (ie. pin of the device) to propagate through the input buffer.

This becomes important for some peripherals as you may have seen in other posts regarding McSPI, or others, that actually use this return path for signals like the clock to serial shift not only the Transmit side, but the Receive side as well.

Regardless, this is again independent of the direction control which may be dictated by the peripheral module currently selected by the MUXMODE.  In your case, the direction control would be from the GPIO module.  This enables or disables the output buffer.  If the output buffer is disabled, then whatever on the outside world will be able drive this pin and provided that INPUTENABLE=1, this signal will propagate through the input buffer into the GPIO data input register.

burchmere said:

2.  For pins that are configured with muxmode other than GPIO, for example MMC1_CLK - does the direction have to be explicitly configured in the padconf reg or by virtue of programming it for muxmode=0 force MMC1_CLK to be an output?

As mentioned above, the direction of the I/O is dictated by the peripheral which is selected by the MUXMODE.  I know the INPUTENABLE is confusing, but it truly is only enabling or disabling the input buffer itself.  Not driving the direction of the pin at any given time.