Clock System Operation
389
SLAU356I – March 2015 – Revised June 2019
Copyright © 2015–2019, Texas Instruments Incorporated
Clock System (CS)
A peripheral module may request any system clock (for example, ACLK, HSMCLK, or SMCLK). A request
is based on the clock selection and enable of the respective module. For example, if a timer selects ACLK
as its clock source and the timer is enabled, the timer generates an ACLK request signal to the clock
system. The clock system, in turn, enables ACLK to the module.
The system clocks are each distributed to the peripheral modules as individual clock lines as shown in
. This reduces dynamic power to modules that do not require a particular system clock. Only
peripheral clocks that request the respective system clock receive it.
There are two types of clock requests: conditional and unconditional. Conditional requests can be
disabled. Unconditional requests cannot be disabled. Each module has an individual clock request enable
bit for each clock it can request; for example, ACLKREQ_EN and HSMCLKREQ_EN. These bits are used
to enable or disable conditional clock requests. Setting these bits enables the conditional clock requests
for the module. Clearing these bits causes any conditional clock request to that module to be disabled.
Unconditional requests are used by modules that must receive the clock when requested and cannot be
disabled; for example, a watchdog timer.
In general, the global clock enable bits (for example, ACLK_EN) can be used to enable or disable all
conditional system clock requests globally. By default these bits are set. Clearing these bits disables the
respective system clock even if conditional requests for it are active. If an unconditional request is active,
the respective system clock remains active. These bits are useful to disable clocks globally before
entering a particular power mode. Note that the respective system clock remains disabled when
transitioning back to active mode, and the application must re-enable it if that system clock is desired.
Due to the clock request feature, care must be taken in the application when entering low-power modes to
save power. Although the device is programmed to enter the selected low-power mode, a clock request
may cause the system to not enter the low-power mode. The software can choose to overlook the active
clocks in the system and force a low-power mode entry based on PCM settings. Refer to the PCM
specification for details on the forced low-power mode entries.
NOTE:
Care should be taken when enabling or disabling the clock requests to individual modules or
globally. Enabling a clock request on an active module immediately causes the requested
clock to be presented to the peripheral module. Disabling a clock request on an active
module immediately causes any active clock request to be terminated. In both cases, this
may cause the status of a module to be affected.
6.2.10 Clock System Fail-Safe Operation
The oscillator-fault fail-safe feature detects the low-frequency and high-frequency crystal oscillator faults
and DCO external resistor faults (see
). The available fault conditions are:
•
Low-frequency oscillator fault (LFXTIFG) for LFXT
•
High-frequency oscillator fault (HFXTIFG) for HFXT
•
DCO external resistor open circuit fault (DCOR_OPNIFG)
•
DCO external resistor short circuit fault (DCOR_SHTIFG)
•
External clock signal faults for all bypass modes
The crystal oscillator fault flags (LFXTIFG, HFXTIFG) are set if the corresponding crystal oscillator is
turned on but is not operating properly. After a fault flag is set, it remains set until reset by software, even
if the fault condition no longer exists. If the application clears the corresponding fault flag(s), and the fault
condition(s) still exists, the fault flag(s) are automatically set again, otherwise they remain cleared.
The oscillator-fault interrupt flags are set and latched at POR or when any oscillator fault is detected.
When any of the fault flags are set and the corresponding interrupt enables are set, an NMI interrupt
request is initiated by the CS to the SYSCTL module. The fault flags must be cleared by software. The
source of the fault can be identified by checking the individual fault flags.
