cancel
Showing results for 
Search instead for 
Did you mean: 

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

Kmax18
Senior

I'm writing code for the STM32F411 and STM32F103 MCUs using the ST HAL library. The firmware reads an IDR directly using the HAL function HAL_GPIO_Read_Pin. The function is called 2 to 3 times in main(), that is, the IDR register is 'polled' more than once in quick sequence, without an interrupt routine.

Problem: not all digital input pins (1s or 0s) are read correctly. The first read access in main() is successful, but 1 to 2 subsequent reads are unreliable.

Question: is there a required wait in terms of clock cycles before an IDR can be read again? Or perhaps some reset is needed? Thank you for your responses.

1 ACCEPTED SOLUTION

Accepted Solutions

Not clear what board you're talking, about, or what's connected to those pins in that context. For a NUCLEO, PA2/PA3 could be a USART2 connection to the VCP or Arduino headers.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

8 REPLIES 8
TDK
Guru

> 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?

If you feel a post has answered your question, please click "Accept as Solution".

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Kmax18
Senior

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

Kmax18
Senior

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!

TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".

Not clear what board you're talking, about, or what's connected to those pins in that context. For a NUCLEO, PA2/PA3 could be a USART2 connection to the VCP or Arduino headers.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Kmax18
Senior

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.