Semantics of the Event Register on Cortex M3

[tobermory]

Apologies if this is off-topic and not strictly CMSIS software related. I asked this same question over on the Keil forum, with no replies. Hoping for more luck here. Someone at ARM perhaps?

In learning how to make use of low power modes on my Silicon Labs Giant Gecko MCU, which is Cortex M3 based, I learned the interactions between WFE(), SEV() and the Event Register, a 1-bit hardware component. Any firing ISR provides same 'set the ER to 1' that a call to SEV() does.

Now, I had assumed that the event register followed the same semantics as Dijkstra's binary semaphore:

the semaphore == the event register

P() == WFE()

V() == SEV()

Taking the semaphore, i.e. P(), decrements it from 1 to 0 or waits to do so if it sees the semaphore already at 0. Releasing the semaphore, i.e. V(), increments the semaphore unless a waiter is there, in which case the waiter is unblocked and the value becomes 0.

I have recently discovered that the ER does not align with this. Though I cannot find any Arm doc that categorically states that if the sequence is

WFE()

SEV() / isr

then the final ER value is 1, and NOT 0 as would be in the semaphore case, via experimentation (using a trusty LED on a Silabs starter kit), if I follow the above with

WFE()

then that second WFE does NOT wait. It sees the ER at value 1, decrements it, and continues. It does NOT sleep.

Anyone care to comment on why this is the case?

[JonatanAntoni]

Hi @tobermory,

Low power operation is a recurring source of irritation.

You already worked out how WFE actually behaves, i.e. it waits for the event register to become 1. If the event register is already set, WFE simply becomes a NOP but clearing the event register to 0.

The challenge for low power operation is to implement it free of race conditions.

There are some hints in the documentation of CMSIS-RTX at https://arm-software.github.io/CMSIS-RTX/latest/theory_of_operation.html#lowPower.

[tobermory]

Yes, the WFE call waits for the ER to become 1, and the SEV call sets it to 1. What surprised me is that the ER is not then reset as the WFE-calling thread is unblocked. A second WFE proceeds also. Maybe I am viewing this (incorrectly) as a thread rendezvous feature and not one dealing solely with low power.

[JonatanAntoni]

Sorry for the late reply.
I do not understand what you mean by "thread rendezvous feature".

Given ER is not set, WFE will stop the processor core until ER is set. WFE does not block just a single RTOS thread allowing another thread to run on the same core. While the core is halted by WFE there is no way for any other piece of code to execute a SEV instruction on the very same core.

The only way to have WFE and SEV to work like some "thread sync" would be on a multi-core device. Running two processes (in opposite to just RTOS threads) independently, one on each processor cores, one hitting the WFE causing its core to be halted while the other one continues running and hitting the SEV which wakes up the halted first core.

Instead, given you are running an RTOS (like RTX5 or FreeRTOS) on a single core device, WFE is only meant to be used in the idle thread to stop the CPU until another thread becomes ready to run. To achieve full low power operation, the SysTick interrupt must be disabled. Otherwise, the next SysTick interrupt will implicitly set ER causing the idle thread to continue (unless another thread became ready and got scheduled).

Or do you actually look for synch'ing a multi-core device? The Giant Gecko doesn't seem to be multi-core, though.

[tobermory]

Sorry, I was not being clear. I am aware that WFE and ISR/SEV is not a thread scheduling scheme, but a system-to-low-power one. The point I am trying to make relates to the sequencing of WFE with respect to ISRs. Let's leave SEV out of the picture, maybe my use of it is the cause of confusion. Yes, I do work on a single core CPU.

In the binary semaphore model, we have operation P for taking the semaphore, which waits if semaphore (our analogy here is ER) is unavailable. A later V call releases the semaphore, so releasing the P. The semaphore state is then 0. If V were to happen first, and P second, the net result is the same. Both 'threads' continue, neither is blocked and the semaphore (ER) is 0. If a second P is done, that requires a second V to free it.

It is the symmetry of this model, where we can have P,V or V,P sequencing that results in same system state, that I am comparing to the WFE/ISR model. It appears to me that the WFE/ISR model does not follow this 'symmetric model'. If we have WFE,ISR,WFE, the first WFE blocks, and system goes to low power, but the second does not. So the semantics of the two wfe calls are different. That was really my only point, as to WHY the two wfe calls in the sequence WFE/ISR/WFE have different results.

Is that any clearer?

[JonatanAntoni]

In general:

• Given ER is cleared to 0
• WFE blocks
• ISR (or any other wakeup event) sets ER to 1
• WFE continues and clears ER to 0

A subsequent WFE is expected to block right away.
But, there might be other events causing ER to become 1 after WFE cleared it. Then, the next WFE will behave like a NOP just clearing ER to 0.

Because software has no direct visibility to ER one can never know a priori if a WFE would actually block or not. The following sequence can be used to force ER to be cleared at a specific point in time:

  __SEV(); // force ER to 1 to prevent next WFE to block
  __WFE(); // clear ER to 0
  __WFE(); // block

Additionally, behaviour of your system depends on the specific implementation of your device. Low power operation must be implemented according to the device vendor's guide. Please consider reaching out to SiLabs as well.

https://developer.arm.com/documentation/ka001269/latest/