Electronics > Microcontrollers

STM HAL GPIO atomicity...

(1/1)

westfw:
So...  I don't pretend to be fully aware of atomicity issues in multicore processors, but...
In https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/gpio_object.h


--- Code: ---
/* 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 */
}
--- End code ---


Aren't the clr and set registers of ST GPIO units fundamentally atomic, and therefore the Locking unnecessary?

ataradov:
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.

westfw:

--- Quote --- your code may be interrupting some other non-atomic access.
--- End quote ---
I 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?)

ataradov:
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.

cv007:
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/e6qehfvxM

Of 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.

Navigation

[0] Message Index