STM HAL GPIO atomicity... - Page 1
Forum section: electronics / general

author: westfw
author_rank: Super Contributor
timestamp: March 29, 2023, 12:00:14 am
content: So... I don't pretend to be fully aware of atomicity issues in multicore processors, but...Inhttps://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/gpio_object.hCode:/* mbed Microcontroller Library******************************************************************************** Copyright (c) 2016, STMicroelectronics* All rights reserved.*/:static inline void gpio_write(gpio_t *obj, int value){#if defined(DUAL_CORE) && (TARGET_STM32H7)while (LL_HSEM_1StepLock(HSEM, CFG_HW_GPIO_SEMID)) {}#endif /* DUAL_CORE */if (value) {*obj->reg_set = obj->mask;} else {#ifdef GPIO_IP_WITHOUT_BRR*obj->reg_clr = obj->mask << 16;#else*obj->reg_clr = obj->mask;#endif}#if defined(DUAL_CORE) && (TARGET_STM32H7)LL_HSEM_ReleaseLock(HSEM, CFG_HW_GPIO_SEMID, HSEM_CR_COREID_CURRENT);#endif /* DUAL_CORE */}Aren't the clr and set registers of ST GPIO units fundamentally atomic, and therefore the Locking unnecessary?

author: ataradov
author_rank: Super Contributor
timestamp: March 29, 2023, 12:25:02 am
content: Yes, but your code may be interrupting some other non-atomic access. This semaphore is taken in a lot of other places. No idea if it actually makes any difference in practice for realistic scenarios.

author: westfw
author_rank: Super Contributor
timestamp: March 29, 2023, 12:50:15 am
content: QuoteI suppose. If it was an actual interrupt, rather than a task thing, won't that end up un-recoverable? (ISRs being the ultimate high-priority task, and thus subject to creating the ultimate in priority inversions issues?)

author: ataradov
author_rank: Super Contributor
timestamp: March 29, 2023, 12:55:43 am
content: Well, in this case the code is for dual-core systems, so it might just be the code on the other core. I can't come up with realistic scenarios where it would matter, I guess they just did it as a matter of common style and precaution.

author: cv007
author_rank: Frequent Contributor
timestamp: March 29, 2023, 05:28:40 am
content: Not related to the specific question, but related to the subject of gpio atomicity- I would imagine mbed is not protecting the modification of all the other gpio registers (no one does). No reason code to setup/change a pin cannot exist in more than 1 run level, so modifying a gpio port register other than the bsrr/brr write would need to be protected since the pins share these registers. Probably a common thing to miss, and only the odds of it happening being very low prevent anyone from noticing.I have a blinky example in compiler explorer for an stm32g031, where both the rcc enable and modification to the non-bsrr/brr registers are protected-https://godbolt.org/z/e6qehfvxMOf course the probabilities are low, but once seen I don't think its something you would want to ignore. In general, I think hardware registers are easily overlooked when it comes to atomic writes. Another good example would be the stm32 rcc registers which have quite a mix in them so is another peripheral that may see frequent use among different functions at various times and various run levels.