SLAU893B October 2023 – July 2024 MSPM0C1103 , MSPM0C1103-Q1 , MSPM0C1104 , MSPM0C1104-Q1
Peripherals are configured to asynchronously assert a hardware request to the SYSCTL for a fast clock source, even if the device is operating in STOP or STANDBY mode. This mechanism for applications where the MCLK/ULPCLK tree is normally sourced from either LFCLK (at 32kHz) or SYSOSC, but a faster clock is temporarily needed to quickly handle a peripheral event (for example, a timer IRQ or GPIO IRQ) or peripheral activity (such as serial communication or an ADC conversion).
Asynchronous fast clock requests are also useful for scenarios where the device is running in STANDBY1 mode. In STANDBY1 (when STOPCLKSTBY is set), the ULPCLK and LFCLK are disabled to all peripherals except for a few TIMGx, leaving TIMGx as the only clocked peripherals. To wake up the device from this state where the bus clock (ULPCLK) is disabled, a TIMGx interrupt request forces an asynchronous fast clock request to wake the device to RUN mode. Other peripherals can also wake the device from this state if they support detecting an asynchronous event (for example GPIO, comparator, and serial interfaces).
Asynchronous fast clock requests temporarily provide peripherals with bus clock ( MCLK/ULPCLK), sourced from the SYSOSC, for the duration of the request. MFCLK, if enabled for use, is also enabled during the asynchronous request.
When configured, SYSCTL will respond to a peripheral fast clock request in the following way:
After the configuration above is applied, it will be held for the duration of time that the asynchronous request remains asserted plus an additional 41 SYSOSC cycles (approximately 1µs). 41 SYSOSC cycles after the request is removed, the system will return to the configuration which existed before the fast clock request, provided the CPU did not change the configuration during the request.
Asynchronous fast clock requests are ignored and will have no effect on the device configuration if any of the following are true:
The , TIMG8, GPIO, SPI, I2C, UART, and ADC peripherals all provide support for generating an asynchronous fast clock request. The purpose, request source, and configuration requirements for these peripherals are given in Table 2-7.
Peripheral | Purpose | Request Source | Configuration |
---|---|---|---|
TIMG8 | Fast CPU wake from TIMG8 event | TIMG8 IRQ to CPU | An IRQ event from TIMG8 generates an asynchronous fast clock request when the device is in STANDBY1 mode and the corresponding IMASK interrupt is set in the TIMG registers. This is needed to wake the device as the ULPCLK is disabled to reduce power consumption. |
GPIO | Fast CPU wake from GPIO event | GPIO activity | The GPIO generates an asynchronous fast clock request through the GPIO configuration registers. This is for applications where GPIO wake from STANDBY mode is desired, as the fast clock request will cause the GPIO digital glitch filters to run at the rate. In addition to configuring the GPIO registers to request the fast clock, the BLOCKASYNCALL bit must be cleared in the SYSOSCCFG register to allow the request to propagate. |
SPI | Temporarily use fast clock for bit clock generation | SPI activity | SPI activity generates an asynchronous fast clock request when the BLOCKASYNC bit is cleared in the CLKCFG register of the respective SPI peripheral. |
I2C | Temporarily use fast clock for bit clock generation | I2C activity | I2C activity generates an asynchronous fast clock request when the BLOCKASYNC bit is cleared in the CLKCFG register of the respective I2C peripheral. |
UART | Temporarily use a fast clock for baud rate generation | UART activity | UART activity generates an asynchronous fast clock request when the BLOCKASYNC bit is cleared in the CLKCFG register of the respective UART peripheral. |
ADC | Temporarily run the SYSOSC to support timer-triggered ADC operation from a low-power mode | ADC | If an ADC conversion is triggered when SYSOSC is disabled, an asynchronous fast clock request is generated to enable the SYSOSC (SYSOSC is required for correct ADC operation). |
In addition to the peripheral event and activity fast clock request triggers, the SYSCTL can be configured to generate an asynchronous fast clock request upon any IRQ request to the CPU. This provides the lowest latency interrupt handling when the system is running at the LFCLK rate (32kHz), as the IRQ request will propagate through the wake-up logic at the SYSOSC rate () vs. the LFCLK rate (32kHz). When the FASTCPUEVENT bit is set in the SYSOSCCFG register in SYSCTL, any interrupt request to the CPU will also generate a fast clock request.
The logic for asserting a fast clock request is given in the following figure.