Do we need to synchronize memory access between interrupt handlers and treads on STM32H7?

[IIvan.22]

If we want to pass some information from application running in a thread mode to an interrupt handler using normal SRAM memory (at 0x20000000 address) variables, do we need to do any special synchronization steps (such as calling Data Memory Barrier (DMB) instruction), or we do not?

 

For example, in the application running in a thread mode, we write '0x1' value to a global 32-bit integer variable 'X'. Then an exception happens and processor starts executing the interrupt handler. Is it guaranteed that it will see 'X' as having '0x1'?

 

So, in the application thread:

LDR R1, =X // write address of X into R1 register

MOV R0, #1 // write 1 into R0 register

STR R0, [R1] // write 1 into variable 'X'

// STR instruction completes. But 1 is not yet written to the physical memory.

// Next, an exception here happens ...

 

In the exception handler:

LDR R1, =X // write address of X into R1 register

LDR R0, [R1] // read content of 'X' into R0 register

// is it guaranteed that R0 contains 1?

 

On other hardware platforms (GPU parallel computing for example), it is not the case: we have to exit all threads and re-start them again to see memory changes made from another thread. 

 

Do we need to do any special synchronization in the case of STM32H7? Any official statement about it in the documentation? Lets say D-cache is disabled.

 

Thanks.

 

[Sarra.S]

Hello @IIvan.22, 

In the context of the STM32H7 series, when the D-cache is disabled, the CPU writes directly to the SRAM, and the data is immediately visible to all bus masters, including the interrupt handlers. Therefore, if the D-cache is disabled, there is no need for special synchronization steps such as calling DMB instruction.

In your specific case with the D-cache disabled, if the STR instruction has been completed before the exception occurs, the interrupt handler should see the updated value of 'X' as '0x1'

as you may know, the ARM Cortex-M7 processor has a write-through cache policy as one of the options for memory attributes. When a memory region is configured as write-through, writes are immediately visible to all bus masters, but reads may fetch data from the cache. This can be configured using the MPU.

>>Any official statement about it in the documentation?

I would recommend The ARM Cortex-M7 Devices Generic User Guide 

[IIvan.22]

Hi Sarra,

To summarize your answer:

(1) If D-cache is disabled or configured as write-through, no need for extra steps to synchronize.

(2) If D-cache is enabled, but not in the write-through mode (read cache), then synchronization may be needed?

If synchronization between thread and interrupt not required, then I don't understand why DMB instruction exists? (there are separate instructions to clear and invalidate the cache).

Lets say it is a single-core MCU. We configure some areas as no-cache for use with DMA, and some areas as read cache, to exchange information between threads and interrupts. Do we need DMB for cached areas then? There is no answer on this question in device documentation, but we need it for ISO design quality certification.

Thank you.

[Pavel A.]

In single-core STM32H7, there's no other CPU, so the ISR running on the same CPU sees the same cache as the thread code. So, the ISR will immediately see memory writes by the thread code - with or without any cache or buffering, no MPU tricks needed.

But the compiler can delay the write or move it around, so DMB would be appropriate. The shared variables can be declared volatile, though precise meaning of volatile became complicated these days.

For dual core H7, if one CPU writes and another reads, I don't know. A DSB won't harm. 

 

[IIvan.22]

Hello Pavel,

Lets say we use assembler language, so volatile is out of question. Processor can re-arrange memory writes, but it is not clear then when the DMB instruction should be used at all? No DMA involved for the clarity. Won't harm will be quite a scary answer.

[Tesla DeLorean]

Writes are queued/buffered, but completion of read/write should always occur in program order.

I don't think you need any fencing instruction for your top-post example to work

[Pavel A.]

@IIvan.22 If you write in assembly then indeed everything C related (volatile, CMSIS) is not useful. I apologize about the DMB as well, it is overkill in your case of single core. /* In C, a compiler barrier will suffice, and the DMB intrinsic has side effect of compiler barrier */

The DSB is even more overkill for single core. As assembly programmer, you know of course the difference between dmb and dsb.

> Won't harm will be quite a scary answer.

Not more scary than developing for a multicore STM32 )) Fortunately you don't ))

Regards,

P.