Max. frequency for reading a GPIO input data register (IDR)

> is there a required wait in terms of clock cycles before an IDR can be read again?

There is no restriction on how quickly IDR can be read.

Why do you think it's unreliable?

They are connected to schmitt triggers, and will reflect the high/low state of the pin at that instant.

I'd estimate you could probably read them at 21 MHz, or more, on the F4. And do so continuously. There is perhaps a resynchronizer at the AHB or APB clock for the GPIO, which might have nyquist sampling properties at high frequencies, ie artifacts and negative frequency.

If they are from buttons, you might need to debounce them properly.

The setup and firmware is tested with a slow (10 Hz) pulse sequence generated by a function generator and applied to DI pins PA1, PA2, PA3. For testing the DI states are written directly to DO pins PB4, PB5, PB6. Only 1 of 3 DO pins matches the corresponding DI state. PA5 and PB6 seem to latch one value, either 0 or 1. My observations suggest that the input states are incorrect. Thank you for your comments.

Simplify things: use only one input and PB4 as output, and do nothing else in the program but perform the copy. Show us that program.

Also, what are the input signal levels? Measure using oscilloscope directly on the input pin.

JW

Update re. reading Input Data Registers on the STM32411RE: I tested the DI input pins PC0/PC1 instead of PA2/PA3. The GPIOC->IDR can be polled without any problems. The datasheet does not specify any special setup for PA2/PA3, so I do not know a reason for the different behavior. Do you know of any special config requirements for PA2/PA3? In MX I selected GPIO_Input for all input pins. Thank you for your feedback!

From a practical standpoint, these are incredibly mature and popular products. If there was a critical flaw such as IDR latching it would have been caught (and likely fixed) many years ago by many different people. The IDR functionality is used by almost all programs.

Nothing special about PA2/PA3.

Update and closure: Thank you for your answers! Your feedback re. GPIO IDRs pointed me in the right direction. It was an issue with the carrier board, not the MCU.