Cortex-Mx WFI Wake-Up Behavior and Configuration

Cortex-Mx WFI Wake-Up Conditions and Implementation-Defined Behavior

The Wait For Interrupt (WFI) instruction is a fundamental feature in ARM Cortex-M processors, designed to place the processor in a low-power state until a specific event occurs. The ARMv7-M architecture manual (DDI0403) outlines the conditions under which the processor will wake up from WFI. These include:

• A reset.
• An asynchronous exception at a priority that, if PRIMASK was set, would cause the processor to take the exception.
• A debug event if debug is enabled.
• An implementation-defined WFI wake-up event.

The key point of confusion in the discussion revolves around the "implementation-defined" wake-up events and whether the behavior of WFI can be altered by the specific implementation of the Cortex-M processor. The ARM architecture provides a baseline specification, but silicon vendors can extend or modify certain behaviors, particularly in areas marked as "implementation-defined." This means that while the core behavior of WFI is consistent across all Cortex-M processors, the specific conditions under which it wakes up can vary depending on the chip manufacturer’s design choices.

For example, the TI CC3220, a Cortex-M4 based SoC, may have additional wake-up sources or conditions that are not explicitly covered in the ARM architecture manual. These would typically be documented in the chip’s technical reference manual (TRM) or datasheet. However, in the case of the CC3220, the documentation does not explicitly mention any implementation-defined WFI wake-up events, leading to uncertainty about whether such events exist and how they might be configured.

NVIC Configuration and Peripheral Interrupts as Wake-Up Sources

The Nested Vectored Interrupt Controller (NVIC) plays a crucial role in determining which interrupts can wake the processor from WFI. According to the ARM architecture, any interrupt that is enabled in the NVIC and reaches the core will cause the processor to wake up from WFI. This includes both internal Cortex-M exceptions (such as SysTick, SVC, and PendSV) and external interrupts from peripherals.

In the case of the TI CC3220, the external peripheral interrupts must be correctly configured and enabled in both the NVIC and the peripheral itself. If an interrupt is not reaching the core, it could be due to several reasons:

• The interrupt is not enabled in the NVIC.
• The peripheral generating the interrupt is not correctly configured or enabled.
• The interrupt priority is set too low, and another higher-priority interrupt is masking it.

The discussion highlights a specific observation where the main thread does not wake up from WFI when an external peripheral interrupt occurs, but it does wake up on SysTick interrupts. This behavior suggests that the external interrupt may not be reaching the core, or it is being handled in a way that does not cause the main thread to resume execution. This could be due to the interrupt being handled entirely within the ISR, or the main thread being blocked by other conditions.

Debugging and Resolving WFI Wake-Up Issues

To troubleshoot and resolve issues related to WFI wake-up behavior, the following steps should be taken:

1. Verify NVIC Configuration: Ensure that all relevant interrupts are enabled in the NVIC. This includes both internal exceptions (like SysTick) and external peripheral interrupts. The NVIC’s ISER (Interrupt Set Enable Register) should be checked to confirm that the necessary interrupts are enabled.

2. Check Peripheral Configuration: Verify that the peripheral generating the interrupt is correctly configured and enabled. This includes checking the peripheral’s control registers to ensure that interrupts are enabled and that the interrupt signal is being generated.

3. Inspect Interrupt Priorities: Review the interrupt priorities to ensure that no higher-priority interrupts are masking the wake-up interrupt. The NVIC’s IPR (Interrupt Priority Register) should be checked to confirm that the wake-up interrupt has a sufficient priority.

4. Review Implementation-Defined Behavior: Consult the chip’s technical reference manual or datasheet for any implementation-defined WFI wake-up events. If such events exist, ensure that they are correctly configured and enabled.

5. Use Debugging Tools: Utilize debugging tools to monitor the processor’s state and interrupt activity. This can help identify whether the interrupt is reaching the core and whether the processor is waking up as expected.

6. Test with Minimal Configuration: Create a minimal test case that isolates the WFI behavior. This can help determine whether the issue is related to the specific configuration or if it is a more general problem with the WFI implementation.

7. Consult Vendor Examples: Review any examples provided by the chip vendor that demonstrate waking the device from sleep. These examples can provide valuable insights into the correct configuration and usage of WFI.

By following these steps, you can systematically identify and resolve issues related to WFI wake-up behavior. It is important to remember that while the ARM architecture provides a consistent foundation, the specific implementation of WFI can vary between different Cortex-M processors and chip vendors. Therefore, a thorough understanding of both the architecture and the specific chip’s behavior is essential for effective debugging and optimization.

Conclusion

The WFI instruction is a powerful tool for managing power consumption in Cortex-M processors, but its behavior can be influenced by both the ARM architecture and the specific implementation of the processor. Understanding the conditions under which WFI will wake up the processor, and how to configure and debug these conditions, is essential for developing efficient and reliable embedded systems. By carefully reviewing the NVIC configuration, peripheral setup, and implementation-defined behavior, and by utilizing debugging tools and vendor examples, you can ensure that your application wakes up from WFI as expected and operates correctly.