1

I am trying to rewrite a code section that currently works with disabling/enabling interrupts with LDREX/STREX on a STM32F7(single core, microcontroller).

May sound like a straightforward question, but after a couple of days researching, did not seem to find a definitive answer neither in ARM documentation, nor in community replies:

Would a regular memory access between LDREX/STREX invalidate the exclusive monitor state (and hence always fail STREX)?

Common sense is that it should be invalidated, but still ARM documentation does not state regular memory accesses as one of the cases which invalidate the exclusive monitor.

It is a fact that in most situations the work between LDREX and STREX can be done only in registers, so the question will not be relevant, but in my case this does not suffice and I need to access memory. I am basically trying to do a detector "did an interrupt occur between these lines?"

The ST manual states that the EGR is the whole memory, but still it does not answer the question.

Code section:

failed:
LDR     R2, =g_Exclusive_Var
LDREX   R0, [R2]
...
LDR     ...  ---> is this OK
STR     ...  ---> is this OK
...
STREX   R3, R0, [R2] 
CMP     R3, #0
BNE     failed
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Dan
  • 11
  • 1
  • Instead it treats any access as matching the address of the previous LDREX instruction. – old_timer Sep 24 '17 at 16:08
  • Between the Exclusive Read and the Exclusive Write there can be other Non-exclusive transfers. – old_timer Sep 24 '17 at 16:11
  • As well as just looking at the arm docs (have to match the right version one one to the core in question which I may or may not have done) you could simply try it. did you try your above code and what did it produce? the m7 being uniprocessor kind of messes with some of this documentation (why did you list M4?) – old_timer Sep 24 '17 at 16:17
  • and then of course there is the arm logic and the chip vendor logic which both come into play...so arm docs are not where you stop and interpretation by the chip vendor then implementation might vary so you then have to ask them or do enough experiments to satisfy your requirements. – old_timer Sep 24 '17 at 16:20
  • As I recall the M series treat all memory as a reserve granule. A regular access should not fail `strex`, a `clrex` or another `ldrex` will. With a reserve granule the size of 32bits, it mean this is just a global semaphore with retries. It is probably worse than `swp` and it likely just for code compatibility and otherwise useless on the cortex-m (if reserve granule is all of memory). – artless noise Sep 25 '17 at 15:19
  • @artlessnoise: if you need to have guarantees on interrupt latencies, `ldrex`/`strex` are the way to go. The only problem you would have if you had dozens of `ldrex`/`strex` pairs *and* also do a bunch of calculation between them, increasing your chances of having to retry. – Lou Jul 03 '18 at 22:13
  • @Lou that is a fair point, but most people are concerned with the performance of the `ldrex`/`strex` body and not interrupts. It does certainly give a use case though, but probably not like Cortex-A tuned lock free libraries might expect. – artless noise Jul 20 '18 at 17:55
  • Maybe related: [When is CLREX actually needed on ARM Cortex M7?](https://stackoverflow.com/q/51162344) – Peter Cordes Jan 09 '21 at 01:48

0 Answers0