Concurrent GPIO access from threads and ISR

[st239955_stm1_stmicro_com]

Posted on November 20, 2015 at 02:25

In my Stm32F4 applicarion, I am using (a.o.) sw4stm32, cubemx and Freertos.

Some of the GPIO I need to access from different threads and even from from ISR. Access means, changing port state, reading port state, reading analog input level (ADC); no reconfiguration of GPIO after very first initialization. Is stm32f4 and cube hal completely aware about this kind of concurrent access or did I have to take care of specific design considerations? BTW: I heard about bit banding but never used it untio know. Joe.

[Amel NASRI]

Posted on November 24, 2015 at 11:25

Hi Joe,

If there are conflicts to use some GPIOs, this should be highlighted in CubeMX interface.For sure, a pin should have only one configuration at a given time. So, based in this configuration, we shouldn't expect concurrent access for the same pin. Are you facing any issue with that matter?-Mayla-

[st239955_stm1_stmicro_com]

Posted on November 24, 2015 at 11:58

Hi Mayla,

thanks for your reply. My question is out of scope from CubeMX. For the subject of my question, it doesn't matter if the configuration (initialization code) will be made using CubeMX or with hand written cube hal calls. E.g. after all initialization is done, I need to toggle different GPIO output pins. For example:

• PA0 pin state change in thread A
• PA1 pin state change in thread B
• PA2 pin state change in ISR C
• PA3 pin state change in ISR D

As I read in stm32f4xx_hal_gpio.c the comment at HAL_GPIO_WritePin():This function uses GPIOx_BSRR register to allow atomic read/modify accesses. In this way, there is no risk of an IRQ occurring between the read and the modify access. So for this, I think it's totally safe to perform concurrent access to the GPIO bits without using bit banding, correct? Joe