2026-03-31 2:07 AM - last edited on 2026-03-31 2:08 AM by Andrew Neil
Hi,
I am testing PD11 on an STM32H563ZI with a NUCLEO-H563ZI board.
The pin is configured as plain GPIO input using STM32 HAL:
GPIO_InitStruct.Pin = GPIO_PIN_11;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_PULLUP; // or GPIO_PULLDOWN / GPIO_NOPULL
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);I rebuild and reflash the firmware for each case, then read the pin with HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_11).
What I observe is:
I also checked the pin with a multimeter, and the measured pin level matches what the MCU reads.
I have rebuilt and reflashed multiple times and I keep getting the same pattern.
My expectation was that a floating input with internal pull-up should read HIGH, and with internal pull-down should read LOW.
Is there anything special about PD11 on NUCLEO-H563ZI / STM32H563ZI, or any known STM32H5 GPIO behavior that could explain this?
Thanks.
Solved! Go to Solution.
2026-03-31 7:16 AM - edited 2026-03-31 7:39 AM
Ok.
I did the same test on the same board (NUCLEO-H563ZI) and the behavior is as expected when the pin is floating:
GPIO_PULLUP -> HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_11) reads GPIO as SET
GPIO_PULLDOWN -> HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_11) reads GPIO as RESET
With an oscilloscope:
- The pin is high when GPIO_PULLUP
- The pin is low when GPIO_PULLDOWN
So to me the behavior you are seeing is a hardware issue. Either there is something connected to that pin externally (nothing connected by default in this board) or the IO is broken!
To confirm, please share your test project so I can run it on the board I have.
2026-03-31 6:15 AM
Hello @freshlife and welcome to the ST community,
Your assumption is correct. You need to read high level when the GPIO pin is configured in pull-up and low level when the GPIO pin is configured in pull-down when the pin is floating.
But this is something strange:
@freshlife wrote:I also checked the pin with a multimeter, and the measured pin level matches what the MCU reads.
Are you sure there is nothing connected to that pin apart the multimeter probe of the wire to set the level of the pin?
2026-03-31 7:08 AM
Thank you for the warm welcome!
To clarify our use case: we are designing a PCBA that needs to detect hardware revisions (e.g., version A vs. version B) by reading whether a GPIO pin is left floating or tied to ground.
Before implementing this on our custom board, I wanted to validate the behavior first using the NUCLEO-H563ZI evaluation board.
I reviewed the official NUCLEO-H563ZI schematic and confirmed that PD11 has no external components connected to it. During testing, I was only probing the test point on the EVB with a multimeter — nothing else was connected to the pin.
So to answer your question: no, there is nothing else connected to that pin other than the multimeter probe.
2026-03-31 7:16 AM - edited 2026-03-31 7:39 AM
Ok.
I did the same test on the same board (NUCLEO-H563ZI) and the behavior is as expected when the pin is floating:
GPIO_PULLUP -> HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_11) reads GPIO as SET
GPIO_PULLDOWN -> HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_11) reads GPIO as RESET
With an oscilloscope:
- The pin is high when GPIO_PULLUP
- The pin is low when GPIO_PULLDOWN
So to me the behavior you are seeing is a hardware issue. Either there is something connected to that pin externally (nothing connected by default in this board) or the IO is broken!
To confirm, please share your test project so I can run it on the board I have.
2026-03-31 8:53 PM
Hi,
I did a series of debug tests and, after reverting the code back to the original version, the behavior is now matching expectations again.
When configured as pull-down, the pin reads low.
When configured as pull-up, the pin reads high.
When the pin is left floating, I can see a small voltage fluctuation on the oscilloscope, which seems reasonable.
So at this point, the GPIO behavior looks normal on my side. It is possible that something in my PC, test setup, or temporary debug changes was affecting the result yesterday.
Sorry for the confusion, and thank you for helping check this.