Digital inputs on STM32G031 not behaving as expected

[moschendrohtzaun]

I'm working with a STM32G031 discovery kit, featuting the 8-pin STM32G031J6M6. Having issues with the most mundane thing: digital inputs via GPIO. Output work just fine, I can set the board LED. But on inputs I tried connecting to pin 1 (PB7/PB8/PB9/PC14). Firstly, I'm only used to much larger size ICs and have not encountered one that maps multiple ports to one physical pin. I'm guessing they're simply all connected in parallel? Could not find information to the contrary and no functions that would distinguish which physical mapping is performed.

In either case, I've tried PB7 and PC14 and cannot see any change in the IDR register of PORTB or PORTC, respectively. GPIO clocks are obviously enabled. When I use PA13 (pin 7), it works perfectly, but this messes up programming since this is SWIO.

Here's my init code:

__HAL_RCC_GPIOB_CLK_ENABLE();

GPIO_InitTypeDef gpio_init_struct = {

.Pin = GPIO_PIN_7,

.Mode = GPIO_MODE_INPUT,

.Speed = GPIO_SPEED_FREQ_HIGH,

.Pull = GPIO_PULLUP,

};

HAL_GPIO_Init(GPIOB, &gpio_init_struct);

and then

if ((GPIOB->IDR >> 7) & 1) { ... }

What am I missing that might cause what I'm seing here? How do I simply use a port pin like pin 1 as digital input on this device? Any help greatly appreciated.

[Danish1]

Something I don't see in your question is what you actually see when you read the IDR?

Is it always high? Or always low?

And what about if you put a multimeter onto the pin? What voltage do you see?

Also you don't say how you (externally) change things on that pin. What voltage do you then see?

This way we can distinguish between the IDR faithfully reflecting what voltage is on the pin and you not changing that voltage, and you successfully changing the voltage on the pin but IDR not reflecting that.

With several stm32 IO all wired to the same pin, you might have one programmed as output-low so overriding the pull-up on PB7 and the pin is always low.

[Andrei Chichak]

Do yourself a favour and start with CubeIDE to set up the chip and generate the startup code and use the HAL_GPIO_ReadPin until you get consistent results, then get clever.

You could be missing starting the clocks for the port. That was a recurring problem back before Cube.

Once you get a cube based program running, take a look at the code it generates and you'll see what you missed. The learning experience will be, well, pretty underwhelming. The idea is not to learn the trivia of the STM32 device registers. If you want to learn EVERYTHING!!!, go for it.

[S.Ma]

Best way to learn is build a simple project, go debug mode, run then stop the code witg a breakpoint, view and manually play with HW registers live. No rebuild needed, instant reward in feeling the chip....