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