2025-06-26 6:03 AM - last edited on 2025-06-26 6:28 AM by Andrew Neil
Hello,
I’m currently working with the STM32F103VET6 and experimenting with different peripherals to better understand how RCC, GPIOs, and timers interact — both from the block diagrams and the HAL layer.
I've observed some unexpected behavior in the following two cases:
I enabled TIM1_CH1 in input capture mode.
I did not enable the clock for GPIOA, and PA8 was not configured as Alternate Function input in the GPIO registers.
Despite this, input capture worked correctly — I could detect edges on PA8 as expected.
I configured the MCO to output the system clock on PA8.
Again, GPIOA was not clocked, and PA8 was not configured as AF output, but the clock signal appeared correctly on PA8.
I tried to reason this using the GPIO block diagram from the reference manual:
I can see that each GPIO pin has a multiplexer between GPIO and peripheral alternate functions.
At reset, all GPIO pins are set to input floating, which explains how input capture might work without configuring GPIOA.
However, for the MCO case, PA8 is acting as an output, so I would expect GPIOA clock and pin configuration to be necessary — yet it still works.
Additionally:
I confirmed that GPIOA was not clocked by reading the RCC_APB2ENR register.
I also couldn't find any explicit way to control which peripheral uses a pin when multiple options are mapped to the same pin (no visible mux config). It seems like once a peripheral is enabled, it "takes over" the pin automatically, even without setting GPIO AF mode.
How is it possible that PA8 can function as an input or output for a peripheral without GPIOA being clocked or configured?
Is there any internal mechanism that allows the peripheral to "own" the pin directly, bypassing the GPIO configuration and clock?
For MCO output, shouldn’t PA8 require alternate function push-pull configuration and GPIOA clock to be enabled?
Is there a priority system or implicit mapping where the first enabled peripheral claims the pin?
Is this behavior documented anywhere or just an implementation detail of the STM32F1 series?
2025-06-26 6:27 AM
Welcome to the forum,
For best results, see How to write your question to maximize your chances to find a solution.
You haven't said what board you're using (STM32F103VET6 is just a chip part number; it doesn't identify a board).
You need to show the full code that you used in each of your cases - see: How to insert source code.