STM32H745 hw registers access synchronisation between cores

[AP_it]

There is gpio interrupts enabled on both cores, but for different pins.

Both cores run mbed os 6.15

Programs on th both cores are almost the same:

void gpioInterruptHandler ()
{
 gpio_irq_disable ();
 someFlag = true;
 disableCounter++;
}
 
void pollProcedure () // called every 1ms
{
 if (someFlag)
 {
 /* do some processing */
 someFlag = false;
 gpio_irq_enable ();
 enableCounter++;
 }
}

Actually, programs use InterruptIn from the mbed, but I omited it to make code more simple.

gpio_irq_enable function is from the mbed targets/TARGET_STM/gpio_irq_api.c

At the beginning of the gpio_irq_disable function it disables trigger in the FTSR1 register. And at the end of the gpio_irq_enable function it enables trigger in the FTSR1 register.

Problem: If both gpio inputs generate alot of interrupts, sometimes after the exit from the gpio_irq_enable function there is no trigger enabled in FTSR1, although it enables it at the end of the function.

disableCounter and enableCounter are introduced for debug and they are always equal to each other. So it's not about someFlag state.

My theory is that both cores tries to set or clear their bits in FTSR1 simultaneously and one of the bits is not set.

There is no code about multicore safety for hw registers in mbed or STM HAL code. It's written like there is no problem with that. Also I can't find any info about it in the documentation.

Am I right thinking that simultaneous access from both cores to the same hw register can make problems? How to protect it? Using HSEM? Why there is no such measures implemented in STM HAL?

[Tesla DeLorean]

Some of the RCC is doubled up.

I think there's some expectation that your code is sufficiently partitioned that you are conflicting at the peripheral level, ie both fighting over servicing UART1 for example.

I can see that perhaps for EXTI, as the GPIO is parked way over in the D3 Domain with APB4/AHB4

Can you not manage this at the NVIC level, and not the EXTI? Or do it all on the M4 core, and signal the M7?

Probably not supported in HAL due to the fact you'd grind the system to the lowest common denominator every time you owned and blocked on a resource..

[AP_it]

Ok, got it.

Yes, I have couple of solutions. Signalling everything from the single core is one of them. But all of them look like workaround and I was looking for more "correct" way to solve the problem.