Possible to use any I/O PIN for GPIO? (re: STM32, etc)

[JKlim.1]

I'm new to micro controllers (but I have a software engineering background) and I decided to purchase a NUCLEO-F429ZI (STM32F429ZI).

There are a LOT of pins on this board (168 I/O pins according to the datasheet!). However, if I just want simple HIGH/LOW GPIO, can I use any of the pins? (except the 3V3, 5V, etc pins of course)

It's a bit confusing because each pin seems to have many different functions/configurations.

For example, PB0 has the following 'alternate' functions:

TIM1_CH2N, TIM3_CH3, TIM8_CH2N, LCD_R3, OTG_HS_ULPI_D1, ETH_MII_RXD2, EVENTOUT

...and the following 'additional' function:

ADC12_ IN8

It also labeled as 'FT' (5V tolerant) which is fantastic.

[S.Ma]

Most of GPIO are user accessible. Check the board schematics for which pin is available.

The alternate functions are for pins which can become more than simple GPIO.

Some pins have analog function (ADC/DAC) and these pins are 3.3V limited (non FT)

Take the pins going to the Arduino connector, and you can freely decide for each pin to be digital input, analog input or digital output.

Arduino connector has 1 SPI and 1 UART.

Through the onboard STLink, you can debug and also have a free UART to USB converter which you can use with say Teraterm utility on the laptop side for opening a serial virtual com port channel to communicate with the STM32 as user level.

[Tesla DeLorean]

The pins can be used as GPIO, but can also be controlled by a peripheral, there are up to 16 alternate functions selectable for a pin.

Even when controlled by a peripheral the input value (state of pin) can be read via GPIO->IDR

Some pins are committed to specific board level functions, pull the User Manual and read through it, and review the schematic.

Pins like PC13, PC14, PC15 are in a low power domain, so have limited current drive.

The Data Sheet should have a pin list, and also tables for the alternate functions.

[berendi]

You might want to group signals with related functions to the same GPIO port, so that you can set a couple of pins at once by writing the BSRR register, or read the state of 16 pins at once.

There are also 16 interrupt sources which can be assigned to any input pin with some restrictions, i.e. one one of PA0, PB0, PC0, etc can be mapped to EXTI0, one of PA1/PB1/PC1... to EXTI1 and so on.

Digital inputs are 5V tolerant, to output a 5V signal you should connect an external pullup resistor and set the pin in open-drain output mode.

As a general note to beginners, don't forget to enable peripheral clocks in RCC first, and insert a delay afterwards (see MCU errata)

[Piranha]

The RCC_AHBxENR and RCC_APBxENRy clock enable thing is not in errata, but in reference manual, because it's by design and is not a bug.

[berendi]

I could not find anything about it in RM0090. But:

ES0206 Rev 14 STM32F42xx and STM32F43xx Errata sheet, page 15

2.2.6 Delay after an RCC peripheral clock enabling

Description

A delay between an RCC peripheral clock enable and the effective peripheral enabling should be taken into account in order to manage the peripheral read/write to registers. This delay depends on the peripheral mapping:

• If the peripheral is mapped on AHB: the delay should be equal to 2 AHB cycles.

• If the peripheral is mapped on APB: the delay should be equal to 1 + (AHB/APB prescaler) cycles.

Workaround 1. Use the DSB instruction to stall the Cortex®-M4 CPU pipeline until the instruction is completed.

2. Insert “n�? NOPs between the RCC enable bit write and the peripheral register writes (n = 2 for AHB peripherals, n = 1 + AHB/APB prescaler in case of APB peripherals).

3. Or simply insert a dummy read operation from the corresponding register just after enabling the peripheral clock.

[waclawek.jan]

For extra fun, https://community.st.com/s/feed/0D50X00009XkW4aSAF (can you guys please double-check whether my assertion there is correct?)

JW

[Piranha]

I based my assumption on RM0410 section 5.2.12 and ES0334 errata, which doesn't have this mentioned. But at least it's simpler and more clear on a "what to wait" side:

Just after enabling the clock for a peripheral, software must wait for a 2 peripheral clock cycles delay before accessing the peripheral registers.

NOPs can't be trusted on Cortex-M7 and not "accessing" kind of rules out peripheral register reads also. Indeed it's a "fun"! Should we ignore the not "accessing" and do two dummy peripheral register reads?

[berendi]

So the bug of F4 becomes a "feature" of F7. Great.