2012-09-21 06:30 PM
I'm familiar with using alternate function inputs on the STM32F1 series; the associated GPIO pin is set as an input (CNFx[1:0], MODEx[1:0] bits), AFIO clock is enabled, and the AFIO->MAPR register is set appropriately.
I'm confused how to do the same on STM32F4. Reading the reference manual (RM0009), table 14 seems to indicate alternate function is always output, either OD or PP, with/without PU/PD. In the timer input capture example distributed with the STM32F4 peripheral library, the input pin is put into output PP mode.I find this a bit confusing -- can anybody clarify the use of alternate function inputs on the STM32F4xx series?2012-09-22 03:39 AM
> I find this a bit confusing -- can anybody clarify the use of alternate function inputs on the STM32F4xx series?
It's not confusing, it's straight wrong. The input/output toggle is driven by the connected peripheral. For example, pins configured to be timer ''channel'' (TIMx_CHy) can act as input or output, depending on whether the given channel is configured as capture or compare in the timer module. The STM32 documentation in general is notoriously poor and leaves a lot of unanswered questions, but that's something you've probably already found out... :( JW2012-09-22 03:59 PM
The input/output toggle is driven by the connected peripheral. For example, pins configured to be timer ''channel'' (TIMx_CHy) can act as input or output, depending on whether the given channel is configured as capture or compare in the timer module.
I understand how to configure the peripheral channels to be inputs or outputs, does this completely override what is set in the GPIO register? In other words will selecting AF OD, AF OD + PU, AF OD + PD, AF PP, AF PP + PU, AF PP + PD all have no effect? If they do indeed do have an effect, which mode should be selected when the pin needs to be an alternate function input (floating)? The timer examples in the STM32F4 standard peripheral library all select AF PP, I presume this is ''correct''?2012-09-22 04:46 PM
The AF muxing fabric (ie peripheral pin routing) has control of the output state, and output enable (ie H, L, Z), and can read the current state. It thus controls the input/output.
You can configure if one or two of the transistors drive the output state (ie OD or PP), and UP/DOWN/NONE state of the pull resistors. For interfaces like I2C you're going to want OD output, where as SPI and USART you're going to want PP output. For a pin you know is going to be an input, which you choose is immaterial, it'll just take less initialization code to assign 2-4 pins for an interface simultaneously, which is what the library does.2012-09-24 01:40 AM
> I understand how to configure the peripheral channels to be inputs or outputs,
> does this completely override what is set in the GPIO register?
Not *completely*. It only controls, whether the pin is input or output (more precisely, whether the output transistors are on or off). > In other words will selecting AF OD, AF OD + PU, AF OD + PD, AF PP, AF PP + PU, AF PP + PD all have no effect? Only if the connected peripheral uses the pin as input, the PP/OD setting is ignored, as the output driver is completely off. (As far as I understand, PU/PD settings are always ''obeyed''). This is the same as with setting pin in GPIO mode as input (so if the pin is input you can write what you want into the GPIOx_OTYPER register, and PP is its default state anyway). JW2012-09-24 05:21 AM
Slightly related, and IMO interesting:
Through a copy/paste ''process'' I just mis-configured PA1 for AF0 (SYS) instead of AF11 (ETH), where it would be an input. It is ''not defined'' for AF0, and while I would expect the pin be in benign input (Z) state in that case, it went into output, successfully fighting down the output of the oscillator connected to that pin... :( JW2012-09-24 07:01 AM
I2C initialization from STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\Utilities\STM32_EVAL\STM3240_41_G_EVAL\stm324xg_eval.c
/*!< GPIO configuration */
/* Connect PXx to I2C_SCL*/
GPIO_PinAFConfig(sEE_I2C_SCL_GPIO_PORT, sEE_I2C_SCL_SOURCE, sEE_I2C_SCL_AF);
/* Connect PXx to I2C_SDA*/
GPIO_PinAFConfig(sEE_I2C_SDA_GPIO_PORT, sEE_I2C_SDA_SOURCE, sEE_I2C_SDA_AF);
/*!< Configure sEE_I2C pins: SCL */
GPIO_InitStructure.GPIO_Pin = sEE_I2C_SCL_PIN;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_OType = GPIO_OType_OD;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(sEE_I2C_SCL_GPIO_PORT, &GPIO_InitStructure);
/*!< Configure sEE_I2C pins: SDA */
GPIO_InitStructure.GPIO_Pin = sEE_I2C_SDA_PIN;
GPIO_Init(sEE_I2C_SDA_GPIO_PORT, &GPIO_InitStructure);
2012-10-11 12:48 PM
I just finished testing the use of some timers with some optical encoders. I'm using some of the timers in Encoder mode for angle measurement, and some timers in input capture mode for speed measurement.
I originally had corresponding GPIOs configured with MODER[1:0]='00' (Input mode) and the appropriate AFX bits set in the corresponding AFRL/AFRH to connect the timer peripheral to the correct GPIO pins. This does not work. I had to select MODER[1:0]='10' for it to work.So, the moral of the story is that if you need to use an alternate function of a GPIO, you must set MODER[1:0]='10'. The connected peripheral will then select whether the input or output driver is used. If the connected peripheral selects the input driver, then the OTYPE bit and the OSPEED bits of the GPIO pin is effectively ignored. If the connected peripheral selects the output driver, then the OTYPE bit and the OSPEED bits are used. In both cases, the PUPDR[1:0] bits are still applied.Hopefully this helps others if they have similar confusions about Table 14.