1 /****************************************************************************** 2 * Filename: group_aon_doc.h 3 * 4 * Copyright (c) 2015 - 2022, Texas Instruments Incorporated 5 * All rights reserved. 6 * 7 * Redistribution and use in source and binary forms, with or without 8 * modification, are permitted provided that the following conditions are met: 9 * 10 * 1) Redistributions of source code must retain the above copyright notice, 11 * this list of conditions and the following disclaimer. 12 * 13 * 2) Redistributions in binary form must reproduce the above copyright notice, 14 * this list of conditions and the following disclaimer in the documentation 15 * and/or other materials provided with the distribution. 16 * 17 * 3) Neither the name of the ORGANIZATION nor the names of its contributors may 18 * be used to endorse or promote products derived from this software without 19 * specific prior written permission. 20 * 21 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 22 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 23 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 24 * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 25 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 26 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 27 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 28 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 29 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 30 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 31 * POSSIBILITY OF SUCH DAMAGE. 32 * 33 ******************************************************************************/ 34 //! \addtogroup aon_group 35 //! @{ 36 //! \section sec_aon Introduction 37 //! 38 //! The Always-ON (AON) voltage domain contains the AUX power domain, AON power domain, and JTAG power domain. 39 //! The AON API includes functions to access the AON power domain. For functions accessing the AUX power domain 40 //! see the [AUX API](@ref aux_group). 41 //! 42 //! The AON power domain contains circuitry that is always enabled, except for the shutdown mode 43 //! (digital supply is off), and the AON power domain is clocked at 32-kHz. 44 //! 45 //! The AON API accesses the AON registers through a common module called AON Interface (AON IF) which handles the 46 //! actual transactions towards the much slower AON registers. Because accessing AON can cause a significant 47 //! delay in terms of system CPU clock cycles it is important to understand the basics about how the AON IF 48 //! operates. The following list describes a few of the most relevant properties of the AON IF seen from the system CPU: 49 //! - \ti_bold{Shadow registers}: The system CPU actually accesses a set of "shadow registers" which are being synchronized to the AON registers 50 //! by the AON IF every AON clock cycle. 51 //! - Writing an AON register via AON IF can take up to one AON clock cycle before taking effect in the AON domain. However, the system CPU can 52 //! continue executing without waiting for this. 53 //! - The AON IF supports multiple writes within the same AON clock cycle thus several registers/bit fields can be synchronized simultaneously. 54 //! - Reading from AON IF returns the value from last time the shadow registers were synchronized (if no writes to AON IF have occurred since) 55 //! thus the value can be up to one AON clock cycle old. 56 //! - Reading from AON IF after a write (but before synchronization has happened) will return the value from the shadow register 57 //! and not the last value from the AON register. Thus doing multiple read-modify-writes within one AON clock cycle is supported. 58 //! - \ti_bold{Read delay}: Due to an asynchronous interface to the AON IF, reading AON registers will generate a few wait cycles thus stalling 59 //! the system CPU until the read completes. There is no delay on writes to AON IF if using posted/buffered writes. 60 //! - \ti_bold{Synchronizing}: If it is required that a write to AON takes effect before continuing code execution it is possible to do a conditional "wait for 61 //! synchronization" by calling \ref SysCtrlAonSync(). This will wait for any pending writes to synchronize. 62 //! - \ti_bold{Updating}: It is also possible to do an unconditional "wait for synchronization", in case a new read 63 //! value is required, by calling \ref SysCtrlAonUpdate(). This is typically used after wake-up to make sure the AON IF has been 64 //! synchronized at least once before reading the values. 65 //! 66 //! Below are a few guidelines to write efficient code for AON access based on the properties of the interface to the AON registers. 67 //! - Avoid synchronizing unless required by the application. If synchronization is needed then try to group/arrange AON writes to 68 //! minimize the number of required synchronizations. 69 //! - If modifying several bit fields within a single AON register it is slightly faster to do a single read, modify the bit fields, 70 //! and then write it back rather than doing multiple independent read-modify-writes (due to the read delay). 71 //! - Using posted/buffered writes to AON (default) lets the system CPU continue execution immediately. Using non-posted/non-buffered 72 //! writes will generate a delay similar to a read access. 73 //! 74 //! @} 75
