1.3 Configurations for SleepWalking

While in Standby mode, the peripheral clocks are stopped. A SleepWalking supported peripheral that needs a clock will request it from the clock system (for example, the Generic Clock Controller (GCLK) in Cortex-M0+ MCUs), causing the required clock source and GCLK generator to temporarily wake up and then automatically shut down again once the peripheral's task is complete.

The Event System supports the following path types for event propagation:

  • Asynchronous (no clock required)
  • Synchronous (requires the same GCLK generator as the event source)
  • Resynchronized (handles cross-clock-domain events automatically)

For SleepWalking in Standby mode, the resynchronized path with on-demand clocking enabled (ONDEMAND = 1, RUNSTDBY = 1) is generally used, as it requests the event channel's clock only when an incoming event needs to be serviced. The asynchronous path, while it allows events to propagate without requiring any clock to be active, cannot wake the device from Standby and does not support interrupt generation.

In Cortex-M0+ based MCUs, SleepWalking leverages the on-demand clocking capabilities of the Generic Clock Controller (GCLK) and the clock sources. The following steps describe the configuration and sequence for enabling SleepWalking operation:

  1. Configure the clock sources for on-demand operation – Enable the on-demand feature on the oscillator that will feed the peripheral's clock chain (through the ONDEMAND bit in the respective Oscillator Control register). With on-demand enabled, the clock source remains in a low-power disabled state until a peripheral explicitly requests it, and automatically returns to that state when the request is released during Standby mode.
  2. Configure the GCLK generator – Select the appropriate clock source for the GCLK generator that feeds the target peripheral. The generator does not require its Run in Standby (RUNSTDBY) bit to be set for SleepWalking. When a peripheral issues a clock request, the generator activates automatically regardless of the RUNSTDBY setting. Setting RUNSTDBY on the generator is only necessary if the clock must run continuously during Standby (e.g., SERCOM communication), which is a different use case from On-Demand SleepWalking.
  3. Configure the peripherals for Standby operation – Enable the Run in Standby (RUNSTDBY) bit on the target peripheral (in the peripheral's control register). This allows the peripheral to remain operational and issue clock requests while the device is in Standby sleep mode.
  4. When using the Event System for autonomous peripheral-to-peripheral communication, the event channel can be configured to use the resynchronized path with On-Demand clocking and Run in Standby enabled (ONDEMAND = 1, RUNSTDBY = 1 on the event channel). This configuration ensures the event channel's clock is requested only when an incoming event needs to be serviced, and that it operates in both Idle and Standby modes. Configure the event generators and users through their respective Event Control registers to trigger peripheral operations autonomously.

The SleepWalking sequence proceeds as follows: When the device enters Standby, clocks are stopped. When a configured peripheral needs to perform a task and is triggered by an external event, timer, or other condition, it requests its clock from the Generic Clock Controller. The GCLK controller determines which generator and clock source are needed, wakes the clock source, enables the generator and peripheral channel stages successively, and delivers the clock. The peripheral performs its task and upon completion, the clock request is released, and the clock source and generator return to their stopped state, all without CPU intervention.

Remember: The Event System and SleepWalking architecture described here is a Microchip-designed peripheral framework, not a feature of the Arm core itself. It is present across Microchip Cortex-M processor-based MCU families including those built on Cortex-M0+, Cortex-M23, and Cortex-M4F cores. While the fundamental on-demand clocking mechanism is consistent, specifics such as the number of event channels, supported path types per user, and power domain configurations vary by device family and may evolve as newer core profiles and integrated peripherals are introduced. For device-specific details, refer to the Event System, Power Manager, Main Clock, and Generic Clock Controller chapters in the relevant product datasheet.
Tip: For additional information, refer to the Event System Tech Brief, which is available for download at ww1.microchip.com/downloads/en/devicedoc/90003170a.pdf.