Microcontroller Sleep Race Condition

Question

Given a microcontroller that is running the following code:

volatile bool has_flag = false;

void interrupt(void) //called when an interrupt is received
{
    clear_interrupt_flag(); //clear interrupt flag
    has_flag = true; //signal that we have an interrupt to process
}

int main()
{
    while(1)
    {
        if(has_flag) //if we had an interrupt
        {
            has_flag = false; //clear the interrupt flag
            process(); //process the interrupt
        }
        else
            sleep(); //place the micro to sleep
    }
}

Suppose the if(has_flag) condition evaluates to false and we are about to execute the sleep instruction. Right before we execute the sleep instruction, we receive an interrupt. After we leave the interrupt, we execute the sleep instruction.

This execution sequence is not desirable because:

• The microcontroller went to sleep instead of waking up and calling process().
• The microcontroller may never wake up if no interrupt are thereafter received.
• The call to process() is postponed until the next interrupt.

How can the code be written to prevent this race condition from occurring?

Edit

Some microcontrollers, such at the ATMega, have a Sleep enable bit which prevents this condition from occurring (thank you Kvegaoro for pointing this out). JRoberts offers an example implementation that exemplifies this behavior.

Other micros, such at PIC18s, do not have this bit, and the problem still occurs. However, these micros are designed such that interrupts can still wake up the core irrespective of whether the global interrupt enable bit is set (thank you supercat for pointing this out). For such architectures, the solution is to disable global interrupts right before going to sleep. If an interrupt fires right before executing the sleep instruction, the interrupt handler will not be executed, the core will wake up, and once global interrupts are re-enabled, the interrupt handler will be executed. In pseudo-code, the implementation would look like this:

int main()
{
    while(1)
    {
        //clear global interrupt enable bit.
        //if the flag tested below is not set, then we enter
        //sleep with the global interrupt bit cleared, which is
        //the intended behavior.
        disable_global_interrupts();
        
        if(has_flag) //if we had an interrupt
        {
            has_flag = false; //clear the interrupt flag
            enable_global_interrupts();  //set global interrupt enable bit.
            
            process(); //process the interrupt
        }
        else
            sleep(); //place the micro to sleep
    }
}

Edit 2

Different MCUs handle this condition in different ways. Dvd848 pointed to this PDF that goes through how this situation is resolved for a variety of MCU architectures.

Answer 1

There is usually some kind of hardware support for this case. E.g., the AVRs' sei instruction to enable interrupts defers enabling until the following instruction is complete. With it one can do:

forever,
   interrupts off;
   if has_flag,
      interrupts on;
      process interrupt;
   else,
      interrupts-on-and-sleep;    # won't be interrupted
   end
end

The interrupt that would have been missed in the example would in this case be held off until the processor completes its sleep sequence.

Answer 2

On many microcontrollers, in addition to being able to enable or disable particular interrupt causes (typically within an interrupt controller module), there is a master flag within the CPU core that determines whether interrupt requests will be accepted. Many microcontrollers will exit sleep mode if an interrupt request reaches the core, whether or not the core is willing to actually accept it.

On such a design, a simple approach to achieving reliable sleep behavior is to have the main loop check clear a flag and then check whether it knows any reason the processor should be awake. Any interrupt that occurs during that time which might affect any of those reasons should set the flag. If the main loop didn't find any cause to stay awake, and if the flag isn't set, the main loop should disable interrupts and check the flag again [perhaps after a couple NOP instructions if it's possible that an interrupt which becomes pending during a disable-interrupt instruction might be processed after the operand fetch associated with the following instruction has already been performed]. If the flag still isn't set, then go to sleep.

Under this scenario, an interrupt which occurs before the main loop disables interrupts will set the flag before the final test. An interrupt which becomes pending too late to be serviced before the sleep instruction will prevent the processor from going to sleep. Both situations are just fine.

Sleep-on-exit is sometimes a good model to use, but not all applications really "fit" it. For example, a device with an energy-efficient LCD might be most readily programmed with code that looks like:

void select_view_user(int default_user)
{
  int current_user;
  int ch;
  current_user = default_user;
  do
  {
    lcd_printf(0, "User %d");
    lcd_printf(1, ...whatever... );
    get_key();
    if (key_hit(KEY_UP)) {current_user = (current_user + 1) % MAX_USERS};
    if (key_hit(KEY_DOWN)) {current_user = (current_user + MAX_USERS-1) % MAX_USERS};
    if (key_hit(KEY_ENTER)) view_user(current_user);
  } while(!key_hit(KEY_EXIT | KEY_TIMEOUT));
}

If no buttons are pushed, and nothing else is going on, there's no reason the system shouldn't go do sleep during the execution of the get_key method. While it may be possible to have keys trigger an interrupt, and manage all user-interface interaction via state machine, code like the above is often the most logical way to handle highly-modal user-interface flows typical of small microcontrollers.

Answer 3

Program the micro to wake on interrupt.

The specific details will vary depending on the micro you are using.

Then modify the main() routine:

int main()
{
    while(1)
    {
        sleep();
        process(); //process the interrupt
    }
}