Tristating GPIO as an output

[dibs]

Posted on February 05, 2014 at 19:19

Using an STM32F407, can you have a pin set up as an output and tristated?

The reason that I ask is b/c my circuit is acting like it is doing just that. With my pin configuration as follows:

GPIO_InitStructure.GPIO_Mode   = GPIO_Mode_AF;

GPIO_Speed       = GPIO_Speed_100MHz;

GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

GPIO_InitStructure.GPIO_PuPd    = GPIO_PuPd_NOPULL;

GPIO_InitStructure.GPIO_Pin = PIN1_GPIO_PINx | PIN2_GPIO_PINx;

GPIO_Init(SCSS_GPIOX, &GPIO_InitStructure);$      

The output was acting like it was high impedance at times. I know this because it was getting signals from nearby traces coupled in, but that all went away if I enabled the internal pulldown

#poor-quality-of-documentation #gpio #stm32

[waclawek.jan]

Posted on February 05, 2014 at 19:26

> GPIO_InitStructure.GPIO_Mode   = GPIO_Mode_AF;

In 'F2/'F4, if you set the pin as AF, then the connected peripheral determines, whether it is input or output.

JW

[dibs]

Posted on February 05, 2014 at 19:38

I have my pins set up as timer outputs. Does the AF release them to be tristated after the update event?

// Compute the prescaler value

uhPrescalerValue = (uint16_t) ((SystemCoreClock / 2) / CLKFREQ) - 1;

// base configuration

TIM_TimeBaseStructure.TIM_ClockDivision

= 0

;

TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up;

TIM_TimeBaseStructure.TIM_RepetitionCounter  = 0;

TIM_TimeBaseStructure.TIM_Period = PERIOD;

TIM_TimeBaseStructure.TIM_Prescaler = uhPrescalerValue;

TIM_TimeBaseInit(TIMx, &TIM_TimeBaseStructure);

// Initialize Output compare channels

TIM_OCInitStructure.TIM_OCMode      = TIM_OCMode_PWM2;

TIM_OCInitStructure.TIM_OCPolarity  = TIM_OCPolarity_High;

TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Disable;

TIM_OCInitStructure.TIM_Pulse          = DELAY;

TIM_OC1Init(TIMx, &TIM_OCInitStructure);

TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable;

TIM_OCInitStructure.TIM_Pulse           = 1;

TIM_OC2Init(TIMx, &TIM_OCInitStructure);

// One Pulse Mode selection

TIM_SelectOnePulseMode(TIMx, TIM_OPMode_Single);

// Select Input trigger

scss_selIn(TRGx);

// Slave Mode selection: Trigger Mode

TIM_SelectSlaveMode(TIMx, TIM_SlaveMode_Trigger);

//Enable Slave Main output

if ((TIMx == TIM1) || (TIMx == TIM8)) {

TIM_CtrlPWMOutputs(TIMx, ENABLE);

}

[Tesla DeLorean]

Posted on February 05, 2014 at 20:44

Does the AF release them to be tristated after the update event?

No. You'd have to reconfigure the pin from AF mode to an input mode, or configure the channel(s) to Input Capture mode

[dibs]

Posted on February 05, 2014 at 21:22

To confirm, you are saying that if I configure timer pins such as I listed previously, they will always be driven either high or low. They will never tristate, unless I change the pin configuration.

[Tesla DeLorean]

Posted on February 05, 2014 at 21:45

In AF mode the Peripheral controls the pin, the SPI peripheral may control L/H/Z and change direction of MISO,MOSI depending on Master/Slave settings.

If you configure a timer output, it's going to be High or Low in Push-Pull mode, in Open-Drain mode it could be Floating or Low.

I don't expect timer pins to spontaneously change from output to input, you'd have to change some settings for that to happen. For instance by putting the channel in a Input Capture or PWM Input mode.

[waclawek.jan]

Posted on February 05, 2014 at 21:56

> To confirm, you are saying that if I configure timer pins such as I listed previously, they will

> always be driven either high or low. They will never tristate, unless I change the pin configuration.

No, Clive did not say that. He said, you either reconfigure pin (in GPIO module) to input, or you leave it as AF assigned to timer, and change the associated channel to capture (input).

I repeat, once you assign a pin to a peripheral, it's the peripheral which controls whether it's output or input. More precisely, it controls whether its output circuitry is enabled (input is always active). As far as timers' capture/compare-associated pins are concerned, in most of the timers it's as simple as that - if the channel is configured as capture, the pin is input (i.e. output disabled), if it is configured as compare and enabled the pin is output (output enabled). In case of inactive comapare (TIMx_CCER.CCxE = 0), honestly, I don't know - I assume output is disabled then (and that might be the source of your grief). Note that the ''advanced'' timers as TIM1 and TIM8 are, have much more states in this regard. Have a look at for example at RM0090 (for 'F4xx) rev.5, Tab.94 on p.566.

JW

[dibs]

Posted on February 06, 2014 at 14:43

In the course of my program, I need to enable and disable one of the CC channels. I do this by:

if (1 == var) {

        TIMx->CCER |= PIN2_EN_MASK; // enable

}

else {        TIMx->CCER &= ~PIN2_EN_MASK; // disable

}

Looking at Rev5 of the 407 reference manual:

*Figure 161. Output stage of capture/compare channel (channel 1)

**In regards to the block that says ''Output Enable Circuit,'' is this referring to the circuit in Figure 25, or is it referring to the signal going to the ''Alternate Function Output?''

[waclawek.jan]

Posted on February 06, 2014 at 15:40

> Looking at Rev5 of the 407 reference manual:

>

> *Figure 161. Output stage of capture/compare channel (channel 1)

> **In regards to the block that says ''Output Enable Circuit,'' is this referring to the circuit in

> Figure 25, or is it referring to the signal going to the ''Alternate Function Output?''

I believe that none of these figures is adequate. Both are trying to hide the existence of enable signal in parallel to the output signal, and its routing (via the AF demultiplexer) to the pin output block. Then the details are unclear of course.

I am not an ST insider, so I know no more than I can read in the published manuals, and infer from experiments (with the possibility misiterpreting the findings of course). Please demand better documentation through whatever channels toward ST you have.

JW

[dibs]

Posted on February 06, 2014 at 21:45

I will email ST and post their response here.

My experiments seem to indicate that by clearing the CCxE bit, you are disconnecting the GPIO output circuitry and defaulting the pin to a floating input.