Electronics > Microcontrollers

STM HAL GPIO atomicity...


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 {
        *obj->reg_clr = obj->mask << 16;
        *obj->reg_clr = obj->mask;

#if defined(DUAL_CORE) && (TARGET_STM32H7)
#endif /* DUAL_CORE */
--- End code ---

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

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.


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

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.

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-

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.


[0] Message Index

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod