SLAU846B June 2023 – November 2024 MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G1519 , MSPM0G3105 , MSPM0G3105-Q1 , MSPM0G3106 , MSPM0G3106-Q1 , MSPM0G3107 , MSPM0G3107-Q1 , MSPM0G3505 , MSPM0G3505-Q1 , MSPM0G3506 , MSPM0G3506-Q1 , MSPM0G3507 , MSPM0G3507-Q1 , MSPM0G3519
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 and the RTC as the only clocked peripherals. To wake up the device from this state where the bus clock (ULPCLK) is disabled, a TIMGx or RTC 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 ~1µs 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 RTC, , TIMGx, GPIO, comparator (if present), 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-14.
Peripheral | Purpose | Request Source | Configuration |
---|---|---|---|
RTC (if present) | Fast CPU wake from RTC event | RTC IRQ to CPU | An RTC IRQ event always generates an asynchronous fast clock request when the device is in STANDBY1 mode; this is needed to wake the device as the main ULPCLK is disabled to reduce power consumption. The RTC can also be configured to generate an asynchronous fast clock request in any operating mode by clearing the BLOCKASYNC bit in the RTC CLKCFG register; this provides the lowest latency RTC event response. |
TIMGx | Fast CPU wake from TIMGx event | TIMGx, IRQ to CPU | An IRQ event from TIMGx 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 SYSOSC base frequency. 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. |
Comparator (if present) | Fast wake from a comparator event | Comparator event | A comparator event generates an asynchronous fast clock request to provide the lowest latency comparator event response. The BLOCKASYNC bit in the CLKCFG register of the respective comparator must be disabled. |
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.