Merge branch 'doc/update_esp32p4_pm_programming_guide_docs' into 'master'

docs(pm): update power management related docs for esp32p4

Closes IDF-7672

See merge request espressif/esp-idf!31328
This commit is contained in:
Wu Zheng Hui 2024-08-01 19:05:15 +08:00
commit f2cf9a961b
18 changed files with 140 additions and 101 deletions

View File

@ -169,7 +169,7 @@ I2S_DOCS = ['api-reference/peripherals/i2s.rst']
ISP_DOCS = ['api-reference/peripherals/isp.rst']
RTC_MEM_DOCS = ['api-guides/deep-sleep-stub.rst']
DSLP_STUB_DOCS = ['api-guides/deep-sleep-stub.rst']
ADC_DOCS = ['api-reference/peripherals/adc_oneshot.rst',
'api-reference/peripherals/adc_calibration.rst']
@ -280,7 +280,7 @@ conditional_include_dict = {'SOC_BT_SUPPORTED':BT_DOCS,
'SOC_GPSPI_SUPPORTED':SPI_DOCS,
'SOC_I2S_SUPPORTED':I2S_DOCS,
'SOC_ISP_SUPPORTED':ISP_DOCS,
'SOC_RTC_MEM_SUPPORTED': RTC_MEM_DOCS,
'ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB': DSLP_STUB_DOCS,
'SOC_ADC_SUPPORTED':ADC_DOCS,
'SOC_ADC_DMA_SUPPORTED':ADC_DMA_DOCS,
'SOC_ANA_CMPR_SUPPORTED': ANA_CMPR_DOCS,

View File

@ -1,13 +1,11 @@
api-guides/partition-tables.rst
api-guides/RF_calibration.rst
api-guides/deep-sleep-stub.rst
api-guides/coexist.rst
api-guides/flash_psram_config.rst
api-guides/wifi.rst
api-guides/usb-otg-console.rst
api-guides/esp-wifi-mesh.rst
api-guides/dfu.rst
api-guides/current-consumption-measurement-modules.rst
api-guides/wifi-security.rst
api-reference/peripherals/adc_continuous.rst
api-reference/peripherals/adc_oneshot.rst
@ -33,6 +31,3 @@ api-reference/network/esp_smartconfig.rst
api-reference/network/esp_nan.rst
api-reference/network/esp_wifi.rst
api-reference/network/index.rst
api-reference/system/sleep_modes.rst
api-reference/system/power_management.rst
api-reference/system/inc/power_management_esp32p4.rst

View File

@ -3,7 +3,7 @@ Current Consumption Measurement of Modules
:link_to_translation:`zh_CN:[中文]`
{IDF_TARGET_SOC_BOOT_PIN:default="Not updated", esp32="IO0", esp32s2="IO0", esp32s3="IO0", esp32c3="IO9", esp32c2="IO9", "esp32c6"="IO9", "esp32h2"="IO9"}
{IDF_TARGET_SOC_BOOT_PIN:default="Not updated", esp32="IO0", esp32s2="IO0", esp32s3="IO0", esp32c3="IO9", esp32c2="IO9", "esp32c6"="IO9", "esp32h2"="IO9", "esp32p4"="IO35"}
You may want to know the current consumption of a `module <https://www.espressif.com/en/products/modules>`__ in Deep-sleep mode, :doc:`other power-saving modes </api-reference/system/sleep_modes>`, and Active mode to develop some applications sensitive to power consumption. This section introduces how to measure the current consumption of a module running such an application.
@ -26,7 +26,7 @@ Can We Use a Development Board?
With such development boards, you can measure current consumption of modules in Deep-sleep mode by flashing chips with the :example:`deep_sleep <system/deep_sleep>` example. However, you can also measure current of bare modules equipped with {IDF_TARGET_NAME} chip using the following method.
.. only:: esp32 or esp32s2 or esp32s3 or esp32c2 or esp32c3
.. only:: esp32 or esp32s2 or esp32s3 or esp32c2 or esp32c3 or esp32p4
For {IDF_TARGET_NAME}, using a development board directly to measure current consumption of the corresponding module is not recommended, as some circuits still consume power on the board even when you flash the chip with the :example:`deep_sleep <system/deep_sleep>` example. Therefore, you need to cut off the power supply circuit to the module to measure the module's current. This method is inconvenient and increases measurement costs.

View File

@ -18,7 +18,7 @@ API Guides
code-quality/index
core_dump
current-consumption-measurement-modules
:SOC_RTC_MEM_SUPPORTED: deep-sleep-stub
:ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB: deep-sleep-stub
:SOC_USB_OTG_SUPPORTED and not esp32p4: dfu
error-handling
:SOC_WIFI_MESH_SUPPORT: esp-wifi-mesh

View File

@ -14,7 +14,7 @@ For example, it may be necessary to place:
* critical code in RAM for performance reasons.
* executable code in IRAM so that it can be ran while cache is disabled.
:SOC_RTC_MEM_SUPPORTED: * code in RTC memory for use in a wake stub.
:ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB: * code in RTC memory for use in a wake stub.
:SOC_ULP_SUPPORTED: * code in RTC memory for use by the ULP coprocessor.
With the linker script generation mechanism, it is possible to specify these placements at the component level within ESP-IDF. The component presents information on how it would like to place its symbols, objects or the entire archive. During build, the information presented by the components are collected, parsed and processed; and the placement rules generated is used to link the app.

View File

@ -150,7 +150,9 @@ The ``DRAM_ATTR`` attribute can be used to force constants from DROM into the :r
RTC Slow Memory
^^^^^^^^^^^^^^^
Global and static variables used by code which runs from RTC memory must be placed into RTC Slow memory. For example :doc:`deep sleep <deep-sleep-stub>` variables can be placed here instead of RTC FAST memory, or code and variables accessed by the :doc:`/api-reference/system/ulp`.
.. only:: ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB
Global and static variables used by code which runs from RTC memory must be placed into RTC Slow memory. For example :doc:`deep sleep <deep-sleep-stub>` variables can be placed here instead of RTC FAST memory, or code and variables accessed by the :doc:`/api-reference/system/ulp`.
The attribute macro named ``RTC_NOINIT_ATTR`` can be used to place data into this type of memory. The values placed into this section keep their value after waking from deep sleep.
@ -170,8 +172,9 @@ The ``DRAM_ATTR`` attribute can be used to force constants from DROM into the :r
On {IDF_TARGET_NAME} what was previously referred to as RTC memory has been renamed LP (low power) memory. You might see both terms being used interchangeably in IDF code, docs and the technical reference manual.
.. only:: ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB
The same region of RTC FAST memory can be accessed as both instruction and data memory. Code which has to run after wake-up from deep sleep mode has to be placed into RTC memory. Please check detailed description in :doc:`deep sleep <deep-sleep-stub>` documentation.
The same region of RTC FAST memory can be accessed as both instruction and data memory. Code which has to run after wake-up from deep sleep mode has to be placed into RTC memory. Please check detailed description in :doc:`deep sleep <deep-sleep-stub>` documentation.
.. only:: esp32

View File

@ -32,7 +32,7 @@ Startup code called from the reset vector determines the boot mode by checking `
.. list::
:SOC_RTC_MEM_SUPPORTED: #. Reset from deep sleep: if the value in ``RTC_CNTL_STORE6_REG`` is non-zero, and CRC value of RTC memory in ``RTC_CNTL_STORE7_REG`` is valid, use ``RTC_CNTL_STORE6_REG`` as an entry point address and jump immediately to it. If ``RTC_CNTL_STORE6_REG`` is zero, or ``RTC_CNTL_STORE7_REG`` contains invalid CRC, or once the code called via ``RTC_CNTL_STORE6_REG`` returns, proceed with boot as if it was a power-on reset. **Note**: to run customized code at this point, a deep sleep stub mechanism is provided. Please see :doc:`deep sleep <deep-sleep-stub>` documentation for this.
:ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB: #. Reset from deep sleep: if the value in ``RTC_CNTL_STORE6_REG`` is non-zero, and CRC value of RTC memory in ``RTC_CNTL_STORE7_REG`` is valid, use ``RTC_CNTL_STORE6_REG`` as an entry point address and jump immediately to it. If ``RTC_CNTL_STORE6_REG`` is zero, or ``RTC_CNTL_STORE7_REG`` contains invalid CRC, or once the code called via ``RTC_CNTL_STORE6_REG`` returns, proceed with boot as if it was a power-on reset. **Note**: to run customized code at this point, a deep sleep stub mechanism is provided. Please see :doc:`deep sleep <deep-sleep-stub>` documentation for this.
#. For power-on reset, software SoC reset, and watchdog SoC reset: check the ``GPIO_STRAP_REG`` register if a custom boot mode (such as UART Download Mode) is requested. If this is the case, this custom loader mode is executed from ROM. Otherwise, proceed with boot as if it was due to software CPU reset. Consult {IDF_TARGET_NAME} datasheet for a description of SoC boot modes and how to execute them.

View File

@ -1 +1,13 @@
TO BE UPDATED IDF-7672
+---------------+---------------------------------------+-------------------------------------+
| Max CPU | Lock Acquisition | CPU and APB Frequencies |
| Frequency Set | | |
+---------------+---------------------------------------+-------------------------------------+
| 360 | ``ESP_PM_CPU_FREQ_MAX`` acquired | | CPU: 360 MHz |
| | | | APB: 90 MHz |
+ +---------------------------------------+-------------------------------------+
| | ``ESP_PM_APB_FREQ_MAX`` acquired, | | CPU: 90 MHz |
| | ``ESP_PM_CPU_FREQ_MAX`` not acquired | | APB: 90 MHz |
+ +---------------------------------------+-------------------------------------+
| | None | Min values for both frequencies set |
| | | with :cpp:func:`esp_pm_configure` |
+---------------+---------------------------------------+-------------------------------------+

View File

@ -55,7 +55,7 @@ Dynamic frequency scaling (DFS) and automatic Light-sleep can be enabled in an a
Power Management Locks
----------------------
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, or 240 MHz", esp32s3="80 MHz, 160 MHz, or 240 MHz", esp32c2="80 MHz or 120 MHz", esp32c3="80 MHz or 160 MHz", esp32c6="80 MHz or 160 MHz"}
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, or 240 MHz", esp32s3="80 MHz, 160 MHz, or 240 MHz", esp32c2="80 MHz or 120 MHz", esp32c3="80 MHz or 160 MHz", esp32c6="80 MHz or 160 MHz", esp32p4="360 MHz"}
Applications have the ability to acquire/release locks in order to control the power management algorithm. When an application acquires a lock, the power management algorithm operation is restricted in a way described below. When the lock is released, such restrictions are removed.
@ -114,7 +114,7 @@ The following drivers hold the ``ESP_PM_APB_FREQ_MAX`` lock while the driver is
- **SPI slave**: between calls to :cpp:func:`spi_slave_initialize` and :cpp:func:`spi_slave_free`.
- **GPTimer**: between calls to :cpp:func:`gptimer_enable` and :cpp:func:`gptimer_disable`.
- **Ethernet**: between calls to :cpp:func:`esp_eth_driver_install` and :cpp:func:`esp_eth_driver_uninstall`.
- **WiFi**: between calls to :cpp:func:`esp_wifi_start` and :cpp:func:`esp_wifi_stop`. If modem sleep is enabled, the lock will be released for the periods of time when radio is disabled.
:SOC_WIFI_SUPPORTED: - **WiFi**: between calls to :cpp:func:`esp_wifi_start` and :cpp:func:`esp_wifi_stop`. If modem sleep is enabled, the lock will be released for the periods of time when radio is disabled.
:SOC_TWAI_SUPPORTED: - **TWAI**: between calls to :cpp:func:`twai_driver_install` and :cpp:func:`twai_driver_uninstall` (only when the clock source is set to :cpp:enumerator:`TWAI_CLK_SRC_APB`).
:SOC_BT_SUPPORTED and esp32: - **Bluetooth**: between calls to :cpp:func:`esp_bt_controller_enable` and :cpp:func:`esp_bt_controller_disable`. If Bluetooth Modem-sleep is enabled, the ``ESP_PM_APB_FREQ_MAX`` lock will be released for the periods of time when radio is disabled. However the ``ESP_PM_NO_LIGHT_SLEEP`` lock will still be held, unless :ref:`CONFIG_BTDM_CTRL_LOW_POWER_CLOCK` option is set to "External 32kHz crystal".
:SOC_BT_SUPPORTED and not esp32: - **Bluetooth**: between calls to :cpp:func:`esp_bt_controller_enable` and :cpp:func:`esp_bt_controller_disable`. If Bluetooth Modem-sleep is enabled, the ``ESP_PM_APB_FREQ_MAX`` lock will be released for the periods of time when radio is disabled. However the ``ESP_PM_NO_LIGHT_SLEEP`` lock will still be held.
@ -129,46 +129,53 @@ The following peripheral drivers are not aware of DFS yet. Applications need to
:SOC_MCPWM_SUPPORTED: - MCPWM
Light-sleep Peripheral Power Down
---------------------------------
.. only:: SOC_PM_SUPPORT_TOP_PD
.. only:: esp32c6 or esp32h2
Light-sleep Peripheral Power Down
---------------------------------
{IDF_TARGET_NAME} supports power-down peripherals during Light-sleep.
{IDF_TARGET_NAME} supports power-down peripherals during Light-sleep.
If :ref:`CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP` is enabled, when the driver initializes the peripheral, the driver will register the working register context of the peripheral to the sleep retention link. Before entering sleep, the ``REG_DMA`` peripheral reads the configuration in the sleep retention link, and back up the register context to memory according to the configuration. ``REG_DMA`` also restores context from memory to peripheral registers on wakeup.
If :ref:`CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP` is enabled, when the driver initializes the peripheral, the driver will register the working register context of the peripheral to the sleep retention link. Before entering sleep, the ``REG_DMA`` peripheral reads the configuration in the sleep retention link, and back up the register context to memory according to the configuration. ``REG_DMA`` also restores context from memory to peripheral registers on wakeup.
Currently ESP-IDF supports Light-sleep context retention for the following peripherals:
- INT_MTX
- TEE/APM
- IO_MUX / GPIO
- UART0/1
- GPTimer
- SPI0/1
- SYSTIMER
- RMT
Currently ESP-IDF supports Light-sleep context retention for the following peripherals:
The following peripherals are not yet supported:
- ETM
- ASSIST_DEBUG
- Trace
- Crypto: AES/ECC/HMAC/RSA/SHA/DS/XTA_AES/ECDSA
- SPI2
- I2S
- PCNT
- USB-Serial-JTAG
- TWAI
- LEDC
- MCPWM
- SARADC
- SDIO
- PARL_IO
.. list::
For peripherals that do not support Light-sleep context retention, if the Power management is enabled, the ``ESP_PM_NO_LIGHT_SLEEP`` lock should be held when the peripheral is working to avoid losing the working context of the peripheral when entering sleep.
- INT_MTX
- TEE/APM
- IO_MUX / GPIO
- Timer Group 0 & Timer Group 1
- SPI0/1
- SYSTIMER
:SOC_RMT_SUPPORT_SLEEP_RETENTION: - RMT
:SOC_I2C_SUPPORT_SLEEP_RETENTION: - I2C
:SOC_UART_SUPPORT_SLEEP_RETENTION: - All UARTs
.. note::
The following peripherals are not yet supported:
When the peripheral power domain is powered down during sleep, both the IO_MUX and GPIO modules are inactive, meaning the chip pins' state is not maintained by these modules. To preserve the state of an IO during sleep, it's essential to call :cpp:func:`gpio_hold_dis` and :cpp:func:`gpio_hold_en` before and after configuring the GPIO state. This action ensures that the IO configuration is latched and prevents the IO from becoming floating while in sleep mode.
.. list::
- ETM
- ASSIST_DEBUG
- Trace
- Crypto: AES/ECC/HMAC/RSA/SHA/DS/XTA_AES/ECDSA
- SPI2
- I2S
- PCNT
- USB-Serial-JTAG
- TWAI
- LEDC
- MCPWM
- SARADC
- SDIO
- PARL_IO
For peripherals that do not support Light-sleep context retention, if the Power management is enabled, the ``ESP_PM_NO_LIGHT_SLEEP`` lock should be held when the peripheral is working to avoid losing the working context of the peripheral when entering sleep.
.. note::
When the peripheral power domain is powered down during sleep, both the IO_MUX and GPIO modules are inactive, meaning the chip pins' state is not maintained by these modules. To preserve the state of an IO during sleep, it's essential to call :cpp:func:`gpio_hold_dis` and :cpp:func:`gpio_hold_en` before and after configuring the GPIO state. This action ensures that the IO configuration is latched and prevents the IO from becoming floating while in sleep mode.
API Reference

View File

@ -32,7 +32,7 @@ In Deep-sleep mode, the CPUs, most of the RAM, and all digital peripherals that
:SOC_RTC_FAST_MEM_SUPPORTED: - RTC FAST memory
:SOC_RTC_SLOW_MEM_SUPPORTED: - RTC SLOW memory
.. only:: SOC_BT_SUPPORTED
.. only:: SOC_WIFI_SUPPORTED and SOC_BT_SUPPORTED
Wi-Fi/Bluetooth and Sleep Modes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -41,7 +41,7 @@ In Deep-sleep mode, the CPUs, most of the RAM, and all digital peripherals that
If Wi-Fi/Bluetooth connections need to be maintained, enable Wi-Fi/Bluetooth Modem-sleep mode and automatic Light-sleep feature (see :doc:`Power Management APIs <power_management>`). This allows the system to wake up from sleep automatically when required by the Wi-Fi/Bluetooth driver, thereby maintaining the connection.
.. only:: not SOC_BT_SUPPORTED
.. only:: SOC_WIFI_SUPPORTED and not SOC_BT_SUPPORTED
Wi-Fi and Sleep Modes
^^^^^^^^^^^^^^^^^^^^^^^
@ -227,7 +227,7 @@ RTC peripherals or RTC memories do not need to be powered on during sleep in thi
- wake up if any of the selected pins is high (``ESP_EXT1_WAKEUP_ANY_HIGH``)
- wake up if all the selected pins are low (``ESP_EXT1_WAKEUP_ALL_LOW``)
.. only:: esp32s2 or esp32s3 or esp32c6 or esp32h2
.. only:: not esp32
- wake up if any of the selected pins is high (``ESP_EXT1_WAKEUP_ANY_HIGH``)
- wake up if any of the selected pins is low (``ESP_EXT1_WAKEUP_ANY_LOW``)
@ -344,7 +344,7 @@ When {IDF_TARGET_NAME} receives UART input from external devices, it is often ne
After waking-up from UART, you should send some extra data through the UART port in Active mode, so that the internal wakeup indication signal can be cleared. Otherwises, the next UART wake-up would trigger with two less rising edges than the configured threshold value.
.. only:: esp32c6 or esp32h2
.. only:: SOC_PM_SUPPORT_TOP_PD
.. note::
@ -472,7 +472,7 @@ Application Examples
.. list::
- :example:`protocols/sntp` demonstrates the implementation of basic functionality of Deep-sleep, where ESP module is periodically waken up to retrieve time from NTP server.
- :example:`wifi/power_save` demonstrates the usage of Wi-Fi Modem-sleep mode and automatic Light-sleep feature to maintain Wi-Fi connections.
:SOC_WIFI_SUPPORTED: - :example:`wifi/power_save` demonstrates the usage of Wi-Fi Modem-sleep mode and automatic Light-sleep feature to maintain Wi-Fi connections.
:SOC_BT_SUPPORTED: - :example:`bluetooth/nimble/power_save` demonstrates the usage of Bluetooth Modem-sleep mode and automatic Light-sleep feature to maintain Bluetooth connections.
:SOC_ULP_SUPPORTED: - :example:`system/deep_sleep` demonstrates the usage of various Deep-sleep wakeup triggers and ULP coprocessor programming.
:not SOC_ULP_SUPPORTED: - :example:`system/deep_sleep` demonstrates the usage of Deep-sleep wakeup triggered by various sources, such as the RTC timer, GPIOs, EXT0, EXT1, the touch sensor, supported by {IDF_TARGET_NAME}.

View File

@ -3,7 +3,7 @@
:link_to_translation:`en:[English]`
{IDF_TARGET_SOC_BOOT_PIN:default="Not updated", esp32="IO0", esp32s2="IO0", esp32s3="IO0", esp32c3="IO9", esp32c2="IO9", "esp32c6"="IO9", "esp32h2"="IO9"}
{IDF_TARGET_SOC_BOOT_PIN:default="Not updated", esp32="IO0", esp32s2="IO0", esp32s3="IO0", esp32c3="IO9", esp32c2="IO9", "esp32c6"="IO9", "esp32h2"="IO9", "esp32p4"="IO35"}
开发功耗敏感型应用时,需要了解 `模组 <https://www.espressif.com/en/products/modules>`__ 在 Deep-sleep 模式、:doc:`其他节能模式 </api-reference/system/sleep_modes>` 和 Active 模式下的功耗。本节介绍如何测量运行此类应用程序时模组的功耗。
@ -26,7 +26,7 @@
使用上述开发板,可以烧写 :example:`deep_sleep <system/deep_sleep>` 示例来测量模组在 Deep-sleep 模式下的功耗。也可以使用以下方法来测量配有 {IDF_TARGET_NAME} 芯片的裸模组的电流。
.. only:: esp32 or esp32s2 or esp32s3 or esp32c2 or esp32c3
.. only:: esp32 or esp32s2 or esp32s3 or esp32c2 or esp32c3 or esp32p4
对于 {IDF_TARGET_NAME},不建议直接使用开发板来测量相应模组的功耗,因为即使烧写 :example:`deep_sleep <system/deep_sleep>` 示例,板上的某些电路仍会产生功耗。因此,在测量模组的电流前需要先切断电源电路。这种方法非常不便,测量成本高。

View File

@ -18,7 +18,7 @@ API 指南
code-quality/index
core_dump
current-consumption-measurement-modules
:SOC_RTC_MEM_SUPPORTED: deep-sleep-stub
:ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB: deep-sleep-stub
:SOC_USB_OTG_SUPPORTED and not esp32p4: dfu
error-handling
:SOC_WIFI_MESH_SUPPORT: esp-wifi-mesh

View File

@ -14,7 +14,7 @@
* 将关键代码存放到 RAM 中以提高性能;
* 将可执行代码存放到 IRAM 中,以便在缓存被禁用时运行这些代码;
:SOC_RTC_MEM_SUPPORTED: * 将代码存放到 RTC 存储器中,以便在 wake stub 中使用;
:ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB: * 将代码存放到 RTC 存储器中,以便在 wake stub 中使用;
:SOC_ULP_SUPPORTED: * 将代码存放到 RTC 内存中,以便 ULP 协处理器使用。
链接器脚本生成机制可以让用户指定代码和数据在 ESP-IDF 组件中的存放区域。组件包含如何存放符号、目标或完整库的信息。在构建应用程序时,组件中的这些信息会被收集、解析并处理;生成的存放规则用于链接应用程序。

View File

@ -150,7 +150,9 @@ DROM数据存储在 flash 中)
RTC Slow memoryRTC 慢速存储器)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
从 RTC 存储器运行的代码中使用的全局和静态变量必须放入 RTC Slow memory 中。例如 :doc:`深度睡眠 <deep-sleep-stub>` 变量可以放在 RTC Slow memory 中,而不是 RTC FAST memory或者也可以放入由 :doc:`/api-reference/system/ulp` 访问的代码和变量。
.. only:: ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB
从 RTC 存储器运行的代码中使用的全局和静态变量必须放入 RTC Slow memory 中。例如 :doc:`深度睡眠 <deep-sleep-stub>` 变量可以放在 RTC Slow memory 中,而不是 RTC FAST memory或者也可以放入由 :doc:`/api-reference/system/ulp` 访问的代码和变量。
``RTC_NOINIT_ATTR`` 属性宏可以用来将数据放入 RTC Slow memory。放入此类型存储器的值从深度睡眠模式中醒来后会保持值不变。
@ -170,8 +172,9 @@ DROM数据存储在 flash 中)
对于 {IDF_TARGET_NAME}RTC 存储器已被重新重命名为 LP低功耗存储器。在与 {IDF_TARGET_NAME} 相关的 IDF 代码、文档以及技术参考手册中,可能会出现这两个术语混用的情况。
.. only:: ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB
RTC FAST memory 的同一区域既可以作为指令存储器也可以作为数据存储器进行访问。从深度睡眠模式唤醒后必须要运行的代码要放在 RTC 存储器中,更多信息请查阅文档 :doc:`深度睡眠 <deep-sleep-stub>`
RTC FAST memory 的同一区域既可以作为指令存储器也可以作为数据存储器进行访问。从深度睡眠模式唤醒后必须要运行的代码要放在 RTC 存储器中,更多信息请查阅文档 :doc:`深度睡眠 <deep-sleep-stub>`
.. only:: esp32

View File

@ -32,7 +32,7 @@
.. list::
:SOC_RTC_MEM_SUPPORTED: #. 从深度睡眠模式复位:如果 ``RTC_CNTL_STORE6_REG`` 寄存器的值非零,且 ``RTC_CNTL_STORE7_REG`` 寄存器中的 RTC 内存的 CRC 校验值有效,那么程序会使用 ``RTC_CNTL_STORE6_REG`` 寄存器的值作为入口地址,并立即跳转到该地址运行。如果 ``RTC_CNTL_STORE6_REG`` 的值为零,或 ``RTC_CNTL_STORE7_REG`` 中的 CRC 校验值无效,又或通过 ``RTC_CNTL_STORE6_REG`` 调用的代码返回,那么则像上电复位一样继续启动。 **注意**:如果想在这里运行自定义的代码,可以参考 :doc:`深度睡眠 <deep-sleep-stub>` 文档里面介绍的深度睡眠存根机制方法。
:ESP_ROM_SUPPORT_DEEP_SLEEP_WAKEUP_STUB: #. 从深度睡眠模式复位:如果 ``RTC_CNTL_STORE6_REG`` 寄存器的值非零,且 ``RTC_CNTL_STORE7_REG`` 寄存器中的 RTC 内存的 CRC 校验值有效,那么程序会使用 ``RTC_CNTL_STORE6_REG`` 寄存器的值作为入口地址,并立即跳转到该地址运行。如果 ``RTC_CNTL_STORE6_REG`` 的值为零,或 ``RTC_CNTL_STORE7_REG`` 中的 CRC 校验值无效,又或通过 ``RTC_CNTL_STORE6_REG`` 调用的代码返回,那么则像上电复位一样继续启动。 **注意**:如果想在这里运行自定义的代码,可以参考 :doc:`深度睡眠 <deep-sleep-stub>` 文档里面介绍的深度睡眠存根机制方法。
#. 上电复位、软件 SoC 复位、看门狗 SoC 复位:检查 ``GPIO_STRAP_REG`` 寄存器,判断是否请求自定义启动模式,如 UART 下载模式。如果是ROM 会执行此自定义加载模式,否则会像软件 CPU 复位一样继续启动。请参考 {IDF_TARGET_NAME} 技术规格书了解 SoC 启动模式以及具体执行过程。

View File

@ -1 +1,13 @@
TO BE UPDATED IDF-7672
+---------------+---------------------------------------+-------------------------------------+
| CPU 最高频率 | 电源管理锁获取情况 | APB 频率和 CPU 频率 |
| | | |
+---------------+---------------------------------------+-------------------------------------+
| 360 | 获取 ``ESP_PM_CPU_FREQ_MAX`` | | CPU: 360 MHz |
| | | | APB: 90 Mhz |
+ +---------------------------------------+-------------------------------------+
| | | 获取 ``ESP_PM_APB_FREQ_MAX``, | | CPU: 90 MHz |
| | | 未获得 ``ESP_PM_CPU_FREQ_MAX`` | | APB: 90 Mhz |
+ +---------------------------------------+-------------------------------------+
| | 无 | 使用 :cpp:func:`esp_pm_configure` |
| | | 为二者设置最小值 |
+---------------+---------------------------------------+-------------------------------------+

View File

@ -55,7 +55,7 @@ ESP-IDF 中集成的电源管理算法可以根据应用程序组件的需求,
电源管理锁
----------------------
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, 或 240 MHz", esp32s3="80 MHz, 160 MHz, 或 240 MHz", esp32c2="80 MHz 或 120 MHz", esp32c3="80 MHz 或 160 MHz", esp32c6="80 MHz 或 160 MHz"}
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, 或 240 MHz", esp32s3="80 MHz, 160 MHz, 或 240 MHz", esp32c2="80 MHz 或 120 MHz", esp32c3="80 MHz 或 160 MHz", esp32c6="80 MHz 或 160 MHz", esp32p4="360 MHz"}
应用程序可以通过获取或释放管理锁来控制电源管理算法。应用程序获取电源管理锁后,电源管理算法的操作将受到下面的限制。释放电源管理锁后,限制解除。
@ -114,7 +114,7 @@ ESP-IDF 中集成的电源管理算法可以根据应用程序组件的需求,
- **SPI slave**:从调用 :cpp:func:`spi_slave_initialize`:cpp:func:`spi_slave_free` 期间。
- **GPTimer**:从调用 :cpp:func:`gptimer_enable`:cpp:func:`gptimer_disable` 期间。
- **Ethernet**:从调用 :cpp:func:`esp_eth_driver_install`:cpp:func:`esp_eth_driver_uninstall` 期间。
- **WiFi**:从调用 :cpp:func:`esp_wifi_start`:cpp:func:`esp_wifi_stop` 期间。如果启用了调制解调器睡眠模式,广播关闭时将释放此管理锁。
:SOC_WIFI_SUPPORTED: - **WiFi**:从调用 :cpp:func:`esp_wifi_start` 至 :cpp:func:`esp_wifi_stop` 期间。如果启用了调制解调器睡眠模式,广播关闭时将释放此管理锁。
:SOC_TWAI_SUPPORTED: - **TWAI**:从调用 :cpp:func:`twai_driver_install` 至 :cpp:func:`twai_driver_uninstall` 期间 (只有在 TWAI 时钟源选择为 :cpp:enumerator:`TWAI_CLK_SRC_APB` 的时候生效)。
:SOC_BT_SUPPORTED and esp32: - **Bluetooth**:从调用 :cpp:func:`esp_bt_controller_enable` 至 :cpp:func:`esp_bt_controller_disable` 期间。如果启用了蓝牙调制解调器,广播关闭时将释放此管理锁。但依然占用 ``ESP_PM_NO_LIGHT_SLEEP`` 锁,除非将 :ref:`CONFIG_BTDM_CTRL_LOW_POWER_CLOCK` 选项设置为 “外部 32 kHz 晶振”。
:SOC_BT_SUPPORTED and not esp32: - **Bluetooth**:从调用 :cpp:func:`esp_bt_controller_enable` 至 :cpp:func:`esp_bt_controller_disable` 期间。如果启用了蓝牙调制解调器,广播关闭时将释放此管理锁。但依然占用 ``ESP_PM_NO_LIGHT_SLEEP`` 锁。
@ -129,46 +129,53 @@ ESP-IDF 中集成的电源管理算法可以根据应用程序组件的需求,
:SOC_MCPWM_SUPPORTED: - MCPWM
Light-sleep 外设下电
-------------------------
.. only:: SOC_PM_SUPPORT_TOP_PD
.. only:: esp32c6 or esp32h2
Light-sleep 外设下电
-------------------------
{IDF_TARGET_NAME} 支持在 Light-sleep 时掉电外设的电源域.
{IDF_TARGET_NAME} 支持在 Light-sleep 时掉电外设的电源域.
如果在 menuconfig 中启用了 :ref:`CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP`,在初始化外设时,驱动会将外设工作的寄存器上下文注册到休眠备份链表中,在进入休眠前,``REG_DMA`` 外设会读取休眠备份链表中的配置,根据链表中的配置将外设的寄存器上下文备份至内存,``REG_DMA`` 也会在唤醒时将上下文从内存恢复到外设寄存中。
如果在 menuconfig 中启用了 :ref:`CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP`,在初始化外设时,驱动会将外设工作的寄存器上下文注册到休眠备份链表中,在进入休眠前,``REG_DMA`` 外设会读取休眠备份链表中的配置,根据链表中的配置将外设的寄存器上下文备份至内存,``REG_DMA`` 也会在唤醒时将上下文从内存恢复到外设寄存中。
目前 IDF 支持以下外设的 Light-sleep 上下文备份:
- INT_MTX
- TEE/APM
- IO_MUX / GPIO
- UART0/1
- GPTimer
- SPI0/1
- SYSTIMER
- RMT
目前 IDF 支持以下外设的 Light-sleep 上下文备份:
以下外设尚未支持:
- ETM
- ASSIST_DEBUG
- Trace
- Crypto: AES/ECC/HMAC/RSA/SHA/DS/XTA_AES/ECDSA
- SPI2
- I2S
- PCNT
- USB-Serial-JTAG
- TWAI
- LEDC
- MCPWM
- SARADC
- SDIO
- PARL_IO
.. list::
对于未支持 Light-sleep 上下文备份的外设,若启用了电源管理功能,应在外设工作时持有 ``ESP_PM_NO_LIGHT_SLEEP`` 锁以避免进入休眠导致外设工作上下文丢失。
- INT_MTX
- TEE/APM
- IO_MUX / GPIO
- Timer Group 0 & Timer Group 1
- SPI0/1
- SYSTIMER
:SOC_RMT_SUPPORT_SLEEP_RETENTION: - RMT
:SOC_I2C_SUPPORT_SLEEP_RETENTION:- I2C
:SOC_UART_SUPPORT_SLEEP_RETENTION: - All UARTs
.. note::
以下外设尚未支持:
当外设电源域在睡眠期间断电时IO_MUX 和 GPIO 模块都处于下电状态,这意味着芯片引脚的状态不会受这些模块控制。要在休眠期间保持 IO 的状态,需要在配置 GPIO 状态前后调用 :cpp:func:`gpio_hold_dis`:cpp:func:`gpio_hold_en`。此操作可确保 IO 配置被锁存,防止 IO 在睡眠期间浮空。
.. list::
- ETM
- ASSIST_DEBUG
- Trace
- Crypto: AES/ECC/HMAC/RSA/SHA/DS/XTA_AES/ECDSA
- SPI2
- I2S
- PCNT
- USB-Serial-JTAG
- TWAI
- LEDC
- MCPWM
- SARADC
- SDIO
- PARL_IO
对于未支持 Light-sleep 上下文备份的外设,若启用了电源管理功能,应在外设工作时持有 ``ESP_PM_NO_LIGHT_SLEEP`` 锁以避免进入休眠导致外设工作上下文丢失。
.. note::
当外设电源域在睡眠期间断电时IO_MUX 和 GPIO 模块都处于下电状态,这意味着芯片引脚的状态不会受这些模块控制。要在休眠期间保持 IO 的状态,需要在配置 GPIO 状态前后调用 :cpp:func:`gpio_hold_dis`:cpp:func:`gpio_hold_en`。此操作可确保 IO 配置被锁存,防止 IO 在睡眠期间浮空。
API 参考

View File

@ -32,7 +32,7 @@
:SOC_RTC_FAST_MEM_SUPPORTED: - RTC 高速内存
:SOC_RTC_SLOW_MEM_SUPPORTED: - RTC 低速内存
.. only:: SOC_BT_SUPPORTED
.. only:: SOC_WIFI_SUPPORTED and SOC_BT_SUPPORTED
睡眠模式下的 Wi-Fi 和 Bluetooth 功能
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -41,7 +41,7 @@
如需保持 Wi-Fi 和 Bluetooth 连接,请启用 Wi-Fi 和 Bluetooth Modem-sleep 模式和自动 Light-sleep 模式(请参阅 :doc:`电源管理 API <power_management>`。在这两种模式下Wi-Fi 和 Bluetooth 驱动程序发出请求时,系统将自动从睡眠中被唤醒,从而保持连接。
.. only:: not SOC_BT_SUPPORTED
.. only:: SOC_WIFI_SUPPORTED and not SOC_BT_SUPPORTED
睡眠模式下的 Wi-Fi 功能
^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -227,7 +227,7 @@ RTC 控制器中内嵌定时器,可用于在预定义的时间到达后唤醒
- 当任意一个所选管脚为高电平时唤醒 (ESP_EXT1_WAKEUP_ANY_HIGH)
- 当所有所选管脚为低电平时唤醒 (ESP_EXT1_WAKEUP_ALL_LOW)
.. only:: esp32s2 or esp32s3 or esp32c6 or esp32h2
.. only:: not esp32
- 当任意一个所选管脚为高电平时唤醒 (ESP_EXT1_WAKEUP_ANY_HIGH)
- 当任意一个所选管脚为低电平时唤醒 (ESP_EXT1_WAKEUP_ANY_LOW)
@ -344,7 +344,7 @@ UART 唤醒(仅适用于 Light-sleep 模式)
使用 UART 唤醒之后,在芯片 Active 模式下需要让 UART 接受一些数据用来清零内部的唤醒指示信号。不然的话,下一次 UART 唤醒的触发将只需要比配置的阈值少两个上升沿的数量。
.. only:: esp32c6 or esp32h2
.. only:: SOC_PM_SUPPORT_TOP_PD
.. note::
@ -472,7 +472,7 @@ UART 输出处理
.. list::
- :example:`protocols/sntp` 演示如何实现 Deep-sleep 模式的基本功能,周期性唤醒 ESP 模块,以从 NTP 服务器获取时间。
- :example:`wifi/power_save` 演示如何通过 Wi-Fi Modem-sleep 模式和自动 Light-sleep 模式保持 Wi-Fi 连接。
:SOC_WIFI_SUPPORTED: - :example:`wifi/power_save` 演示如何通过 Wi-Fi Modem-sleep 模式和自动 Light-sleep 模式保持 Wi-Fi 连接。
:SOC_BT_SUPPORTED: - :example:`bluetooth/nimble/power_save` 演示如何通过 Bluetooth Modem-sleep 模式和自动 Light-sleep 模式保持 Bluetooth 连接。
:SOC_ULP_SUPPORTED: - :example:`system/deep_sleep` 演示如何使用 Deep-sleep 唤醒触发器和 ULP 协处理器编程。
:not SOC_ULP_SUPPORTED: - :example:`system/deep_sleep` 演示如何通过 {IDF_TARGET_NAME} 的唤醒源,如 RTC 定时器, GPIO, EXT0, EXT1, 触摸传感器等,触发 Deep-sleep 唤醒。