docs: update docs with S3 specific information.

docs/en/api-guides/build-system.rst

@@ -31,7 +31,7 @@ Concepts
 
 - "components" are modular pieces of standalone code which are compiled into static libraries (.a files) and linked into an app. Some are provided by ESP-IDF itself, others may be sourced from other places.
 
-- "Target" is the hardware for which an application is built. At the moment, ESP-IDF supports ``esp32``, ``esp32s2`` and ``esp32c3`` targets.
+- "Target" is the hardware for which an application is built. A full list of supported targets in your version if ESP-IDF can be seen by running `idf.py --list-targets`.
 
 Some things are not part of the project:
 
@@ -47,15 +47,15 @@ Using the Build System
 idf.py
 ------
 
-The ``idf.py`` command line tool provides a front-end for easily managing your project builds. It manages the following tools:
+The ``idf.py`` command-line tool provides a front-end for easily managing your project builds. It manages the following tools:
 
 - CMake_, which configures the project to be built
-- A command line build tool (either Ninja_ build or `GNU Make`)
+- A command-line build tool (either Ninja_ build or `GNU Make`)
 - `esptool.py`_ for flashing the target.
 
 The :ref:`getting started guide <get-started-configure>` contains a brief introduction to how to set up ``idf.py`` to configure, build, and flash projects.
 
-``idf.py`` should be run in an ESP-IDF "project" directory, ie one containing a ``CMakeLists.txt`` file. Older style projects with a Makefile will not work with ``idf.py``.
+``idf.py`` should be run in an ESP-IDF "project" directory, i.e. one containing a ``CMakeLists.txt`` file. Older style projects with a Makefile will not work with ``idf.py``.
 
 Type ``idf.py --help`` for a list of commands. Here are a summary of the most useful ones:
 
@@ -1060,11 +1060,7 @@ The subproject is inserted as an external project from the top-level project, by
 Selecting the Target
 ====================
 
-ESP-IDF supports multiple targets (chips). The identifiers used for each chip are as follows:
-
-* ``esp32`` — for ESP32-D0WD, ESP32-D2WD, ESP32-S0WD (ESP-SOLO), ESP32-U4WDH, ESP32-PICO-D4
-* ``esp32s2``— for ESP32-S2
-* ``esp32c3``— for ESP32-C3
+ESP-IDF supports multiple targets (chips). A full list of supported targets in your version if ESP-IDF can be seen by running `idf.py --list-targets`.
 
 To select the target before building the project, use ``idf.py set-target <target>`` command, for example::
 

docs/en/api-guides/core_dump.rst

@@ -1,7 +1,7 @@
 Core Dump
 =========
 
-{IDF_TARGET_ROM_ELF:default="https://dl.espressif.com/dl/esp32_rom.elf", esp32="https://dl.espressif.com/dl/esp32_rom.elf", esp32s2="https://dl.espressif.com/dl/esp32s2_rom.elf", esp32c3="https://dl.espressif.com/dl/esp32c3_rev3_rom.elf"}
+{IDF_TARGET_ROM_ELF:default="https://dl.espressif.com/dl/esp32_rom.elf", esp32="https://dl.espressif.com/dl/esp32_rom.elf", esp32s2="https://dl.espressif.com/dl/esp32s2_rom.elf", esp32s3="https://dl.espressif.com/dl/esp32s3_rom.elf", esp32c3="https://dl.espressif.com/dl/esp32c3_rev3_rom.elf"}
 
 Overview
 --------
@@ -172,7 +172,7 @@ Generic command syntax: ``espcoredump.py [options] command [args]``
 
 :Script Options:
 
-   --chip {auto,esp32,esp32s2,esp32c3}
+   --chip {auto,esp32,esp32s2,esp32s3,esp32c3}
                      Target chip type. Default value is "auto"
 
    --port PORT, -p PORT  Serial port device. Either "chip" or "port" need to be specified to determine the port when you have multi-target connected at the same time.

docs/en/api-guides/deep-sleep-stub.rst

@@ -104,11 +104,11 @@ To reduce wake-up time use the `CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP` K
 CRC Check For Wake Stubs
 ------------------------
 
-.. only:: SOC_PM_SUPPORT_DEEPSLEEP_VERIFY_STUB_ONLY
+.. only:: SOC_PM_SUPPORT_DEEPSLEEP_CHECK_STUB_ONLY
 
     During deep sleep, only the wake stubs area of RTC Fast memory is validated with CRC. When {IDF_TARGET_NAME} wakes up from deep sleep, the wake stubs area is validated again. If the validation passes, the wake stubs code will be executed. Otherwise, the normal initialization, bootloader, and esp-idf codes will be executed.
 
-.. only:: not SOC_PM_SUPPORT_DEEPSLEEP_VERIFY_STUB_ONLY
+.. only:: not SOC_PM_SUPPORT_DEEPSLEEP_CHECK_STUB_ONLY
 
     During deep sleep, all RTC Fast memory areas will be validated with CRC. When {IDF_TARGET_NAME} wakes up from deep sleep, the RTC fast memory will be validated with CRC again. If the validation passes, the wake stubs code will be executed. Otherwise, the normal initialization, bootloader and esp-idf codes will be executed.
 

docs/en/api-guides/dfu.rst

@@ -2,11 +2,6 @@
 Device Firmware Upgrade through USB
 ***********************************************
 
-.. only:: esp32
-
-    .. note::
-        Device Firmware Upgrade through USB is not supported with ESP32 chips.
-
 Device Firmware Upgrade (DFU) is a mechanism for upgrading the firmware of devices through Universal Serial Bus (USB).
 DFU is supported by {IDF_TARGET_NAME} chips. The necessary connections for the USB peripheral are shown in the following table.
 

docs/en/api-guides/external-ram.rst

@@ -8,8 +8,9 @@ Support for External RAM
 
 Introduction
 ============
+{IDF_TARGET_PSRAM_SIZE:default="Value not updated", esp32="4 MB", esp32s2="10.5 MB", esp32s3="16 MB"}
 
-{IDF_TARGET_NAME} has a few hundred kilobytes of internal RAM, residing on the same die as the rest of the chip components. It can be insufficient for some purposes, so {IDF_TARGET_NAME} has the ability to also use up to 4 MB of external SPI RAM memory. The external memory is incorporated in the memory map and, with certain restrictions, is usable in the same way as internal data RAM.
+{IDF_TARGET_NAME} has a few hundred kilobytes of internal RAM, residing on the same die as the rest of the chip components. It can be insufficient for some purposes, so {IDF_TARGET_NAME} has the ability to also use up to {IDF_TARGET_PSRAM_SIZE} of external SPI RAM memory. The external memory is incorporated in the memory map and, with certain restrictions, is usable in the same way as internal data RAM.
 
 
 Hardware
@@ -36,19 +37,20 @@ ESP-IDF fully supports the use of external RAM in applications. Once the externa
     * :ref:`external_ram_config_memory_map`
     * :ref:`external_ram_config_capability_allocator`
     * :ref:`external_ram_config_malloc` (default)
-    :esp32: * :ref:`external_ram_config_bss`
+    :esp32 or esp32s2: * :ref:`external_ram_config_bss`
     :esp32: * :ref:`external_ram_config_noinit`
 
 .. _external_ram_config_memory_map:
 
 Integrate RAM into the {IDF_TARGET_NAME} Memory Map
 ---------------------------------------------------
+{IDF_TARGET_PSRAM_ADDR_START:default="Value not updated", esp32="0x3F800000", esp32s2="0x3F500000", esp32s3="0x3D000000"}
 
 Select this option by choosing "Integrate RAM into memory map" from :ref:`CONFIG_SPIRAM_USE`.
 
 This is the most basic option for external SPI RAM integration. Most likely, you will need another, more advanced option.
 
-During the ESP-IDF startup, external RAM is mapped into the data address space, starting at address 0x3F800000 (byte-accessible). The length of this region is the same as the SPI RAM size (up to the limit of 4 MB).
+During the ESP-IDF startup, external RAM is mapped into the data address space, starting at address {IDF_TARGET_PSRAM_ADDR_START} (byte-accessible). The length of this region is the same as the SPI RAM size (up to the limit of {IDF_TARGET_PSRAM_SIZE}).
 
 Applications can manually place data in external memory by creating pointers to this region. So if an application uses external memory, it is responsible for all management of the external SPI RAM: coordinating buffer usage, preventing corruption, etc.
 
@@ -60,7 +62,7 @@ Add External RAM to the Capability Allocator
 
 Select this option by choosing "Make RAM allocatable using heap_caps_malloc(..., MALLOC_CAP_SPIRAM)" from :ref:`CONFIG_SPIRAM_USE`.
 
-When enabled, memory is mapped to address 0x3F800000 and also added to the :doc:`capabilities-based heap memory allocator </api-reference/system/mem_alloc>` using ``MALLOC_CAP_SPIRAM``.
+When enabled, memory is mapped to address {IDF_TARGET_PSRAM_ADDR_START} and also added to the :doc:`capabilities-based heap memory allocator </api-reference/system/mem_alloc>` using ``MALLOC_CAP_SPIRAM``.
 
 To allocate memory from external RAM, a program should call ``heap_caps_malloc(size, MALLOC_CAP_SPIRAM)``. After use, this memory can be freed by calling the normal ``free()`` function.
 
@@ -85,7 +87,7 @@ If a suitable block of preferred internal/external memory is not available, the
 
 Because some buffers can only be allocated in internal memory, a second configuration item :ref:`CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL` defines a pool of internal memory which is reserved for *only* explicitly internal allocations (such as memory for DMA use). Regular ``malloc()`` will not allocate from this pool. The :ref:`MALLOC_CAP_DMA <dma-capable-memory>` and ``MALLOC_CAP_INTERNAL`` flags can be used to allocate memory from this pool.
 
-.. only:: esp32
+.. only:: esp32 or esp32s2
 
     .. _external_ram_config_bss:
 
@@ -94,7 +96,7 @@ Because some buffers can only be allocated in internal memory, a second configur
 
     Enable this option by checking :ref:`CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY`. This configuration setting is independent of the other three.
 
-    If enabled, a region of the address space starting from 0x3F800000 will be used to store zero-initialized data (BSS segment) from the lwIP, net80211, libpp, and bluedroid ESP-IDF libraries.
+    If enabled, a region of the address space starting from {IDF_TARGET_PSRAM_ADDR_START} will be used to store zero-initialized data (BSS segment) from the lwIP, net80211, libpp, and bluedroid ESP-IDF libraries.
 
     Additional data can be moved from the internal BSS segment to external RAM by applying the macro ``EXT_RAM_ATTR`` to any static declaration (which is not initialized to a non-zero value).
 
@@ -104,6 +106,9 @@ Because some buffers can only be allocated in internal memory, a second configur
 
     Remaining external RAM can also be added to the capability heap allocator using the method shown above.
 
+
+.. only:: esp32
+
     .. _external_ram_config_noinit:
 
     Allow .noinit Segment to be Placed in External Memory
@@ -135,7 +140,7 @@ Failure to initialize
 
  By default, failure to initialize external RAM will cause the ESP-IDF startup to abort. This can be disabled by enabling the config item :ref:`CONFIG_SPIRAM_IGNORE_NOTFOUND`.
 
- .. only:: esp32
+ .. only:: esp32 or esp32s2
 
     If :ref:`CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY` is enabled, the option to ignore failure is not available as the linker will have assigned symbols to external memory addresses at link time.
 

docs/en/api-guides/memory-types.rst

@@ -14,10 +14,12 @@ DRAM (Data RAM)
 
 Non-constant static data (.data) and zero-initialized data (.bss) is placed by the linker into Internal SRAM as data memory. Remaining space in this region is used for the runtime heap.
 
-.. only:: esp32
+.. only:: esp32 or esp32s2
 
    By applying the ``EXT_RAM_ATTR`` macro, zero-initialized data can also be placed into external RAM. To use this macro, the :ref:`CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY` needs to be enabled. See :ref:`external_ram_config_bss`.
 
+.. only:: esp32
+
    The available size of the internal DRAM region is reduced by 64kB (by shifting start address to ``0x3FFC0000``) if Bluetooth stack is used. Length of this region is also reduced by 16 kB or 32kB if trace memory is used. Due to some memory fragmentation issues caused by ROM, it is also not possible to use all available DRAM for static allocations - however the remaining DRAM is still available as heap at runtime.
 
 .. only:: not esp32
@@ -200,7 +202,7 @@ Placing DMA buffers in the stack is possible but discouraged. If doing so, pay a
 
 .. list::
 
-    :SOC_SPIRAM_SUPPORTED: - Placing DRAM buffers on the stack is not recommended if if the stack may be in PSRAM. If the stack of a task is placed in the PSRAM, several steps have to be taken as described in :doc:`external-ram`.
+    :SOC_SPIRAM_SUPPORTED: - Placing DRAM buffers on the stack is not recommended if the stack may be in PSRAM. If the stack of a task is placed in the PSRAM, several steps have to be taken as described in :doc:`external-ram`.
     - Use macro ``WORD_ALIGNED_ATTR`` in functions before variables to place them in proper positions like::
 
         void app_main()

docs/en/api-guides/ulp-risc-v.rst

@@ -2,11 +2,18 @@ ULP-RISC-V Coprocessor programming
 ==================================
 :link_to_translation:`zh_CN:[中文]`
 
+.. only:: esp32s3
+
+    .. warning::
+
+        This feature is not supported in v4.4
+
+
 .. toctree::
    :maxdepth: 1
 
 
-The ULP-RISC-V coprocessor is a variant of the ULP, present in ESP32-S2. Similar to ULP, ULP RISC-V coprocessor can perform tasks such as sensor readings while the main CPU stays in low power modes. The main difference from the FSM ULP is this variant can be programmed in C using standard GNU tools. The ULP-RISC-V coprocessor can access the RTC_SLOW_MEM memory region, and registers in RTC_CNTL, RTC_IO, and SARADC peripherals. The RISC-V processor is a 32-bit, fixed point machine. Its instruction set is based on RV32IMC which includes hardware multiplication and division, and compressed code.  
+The ULP-RISC-V coprocessor is a variant of the ULP, present in ESP32-S2. Similar to ULP, ULP RISC-V coprocessor can perform tasks such as sensor readings while the main CPU stays in low power modes. The main difference from the FSM ULP is this variant can be programmed in C using standard GNU tools. The ULP-RISC-V coprocessor can access the RTC_SLOW_MEM memory region, and registers in RTC_CNTL, RTC_IO, and SARADC peripherals. The RISC-V processor is a 32-bit, fixed point machine. Its instruction set is based on RV32IMC which includes hardware multiplication and division, and compressed code.
 
 Installing the ULP-RISC-V Toolchain
 -----------------------------------
@@ -70,7 +77,7 @@ For example, the ULP-RISC-V program may define a variable ``measurement_count``
 
 .. code-block:: c
 
-    volatile int measurement_count; 
+    volatile int measurement_count;
 
     int some_function()
     {

docs/en/api-guides/ulp.rst

@@ -3,6 +3,12 @@ ULP Coprocessor programming
 
 :link_to_translation:`zh_CN:[中文]`
 
+.. only:: esp32s3
+
+    .. warning::
+
+        This feature is not supported in v4.4
+
 .. toctree::
    :maxdepth: 1
 

docs/en/api-reference/peripherals/sd_pullup_requirements.rst

@@ -7,6 +7,12 @@ SD Pull-up Requirements
 
         This document is not updated for ESP32-C3 yet.
 
+.. only:: esp32s3
+
+    .. warning::
+
+        This document is not updated for ESP32-S3 yet.
+
 Espressif hardware products are designed for multiple use cases which may require different pull states on pins. For this reason, the pull state of particular pins on certain products will need to be adjusted to provide the pull-ups required in the SD bus.
 
 SD pull-up requirements apply to cases where {IDF_TARGET_NAME} uses the SPI controller to communicate with SD cards. When an SD card is operating in SPI mode or 1-bit SD mode, the CMD and DATA (DAT0 - DAT3) lines of the SD bus must be pulled up by 10 kOhm resistors. Slaves should also have pull-ups on all above-mentioned lines (regardless of whether these lines are connected to the host) in order to prevent SD cards from entering a wrong state.

docs/en/api-reference/peripherals/sdio_slave.rst

@@ -7,6 +7,12 @@ SDIO Card Slave Driver
 
         This document is not updated for ESP32-C3 yet.
 
+.. only:: esp32s3
+
+    .. warning::
+
+        This document is not updated for ESP32-S3 yet.
+
 Overview
 --------
 
@@ -189,9 +195,9 @@ To allow the host sending data to the slave, the application has to load buffers
 1. Register the buffer by calling ``sdio_slave_recv_register_buf``, and get the handle of the registered buffer. The driver
    will allocate memory for the linked-list descriptor needed to link the buffer onto the hardware. The size of these buffers should equal to the Receiving buffer size.
 2. Load buffers onto the driver by passing the buffer handle to ``sdio_slave_recv_load_buf``.
-3. Get the received data by calling ``sdio_slave_recv`` or ``sdio_slave_recv_packet``. If non-blocking call is needed, set ``wait=0``. 
+3. Get the received data by calling ``sdio_slave_recv`` or ``sdio_slave_recv_packet``. If non-blocking call is needed, set ``wait=0``.
 
-   The difference between two APIs is that, ``sdio_slave_recv_packet`` gives more information about packet, which can consist of several buffers. When ``ESP_ERR_NOT_FINISHED`` is returned by this API, you should call this API iteratively until the return value is ``ESP_OK``. All the continuous buffers returned with ``ESP_ERR_NOT_FINISHED``, together with the last buffer returned with ``ESP_OK``, belong to one packet from the host. Call ``sdio_slave_recv_get_buf`` to get the address of the received data, and the actual length received in each buffer. The packet length is the sum of received length of all the buffers in the packet. 
+   The difference between two APIs is that, ``sdio_slave_recv_packet`` gives more information about packet, which can consist of several buffers. When ``ESP_ERR_NOT_FINISHED`` is returned by this API, you should call this API iteratively until the return value is ``ESP_OK``. All the continuous buffers returned with ``ESP_ERR_NOT_FINISHED``, together with the last buffer returned with ``ESP_OK``, belong to one packet from the host. Call ``sdio_slave_recv_get_buf`` to get the address of the received data, and the actual length received in each buffer. The packet length is the sum of received length of all the buffers in the packet.
 
    If the host never send data longer than the Receiving buffer size, or you don't care about the packet boundary (e.g. the data is only a byte stream), you can call the simpler version ``sdio_slave_recv`` instead.
 

docs/en/api-reference/peripherals/sdmmc_host.rst

@@ -7,6 +7,13 @@ SDMMC Host Driver
 
         This document is not updated for ESP32-C3 yet.
 
+
+.. only:: esp32s3
+
+    .. warning::
+
+        This document is not updated for ESP32-S3 yet.
+
 Overview
 --------
 

docs/en/api-reference/peripherals/temp_sensor.rst

@@ -1,6 +1,12 @@
 Temperature Sensor
 ===================
 
+.. only:: esp32s3
+
+    .. warning::
+
+        This feature is not supported in v4.4
+
 Overview
 --------
 

docs/en/api-reference/system/perfmon.rst

@@ -1,6 +1,13 @@
 Performance Monitor
 ===================
 
+.. only:: esp32s3
+
+    .. warning::
+
+        This feature is not supported in v4.4
+
+
 The Performance Monitor component provides APIs to use {IDF_TARGET_NAME} internal performance counters to profile functions and
 applications.
 

docs/en/index.rst

@@ -18,12 +18,6 @@ This is the documentation for Espressif IoT Development Framework (`esp-idf <htt
 
     This document describes using ESP-IDF with the {IDF_TARGET_NAME} SoC.
 
-.. only:: esp32s3
-
-    .. warning::
-
-        Not all documents are updated for ESP32-S3 yet.
-
 ==================  ==================  ==================
 |Get Started|_      |API Reference|_    |H/W Reference|_
 ------------------  ------------------  ------------------

docs/zh_CN/index.rst

@@ -18,11 +18,6 @@ ESP-IDF 编程指南
 
     本文档仅包含针对 {IDF_TARGET_NAME} 芯片的 ESP-IDF 使用。
 
-.. only:: esp32s3
-
-    .. warning::
-
-        ESP32-S3 的相关文档尚未全部更新完毕。
 
 ==================  ==================  ==================
 |快速入门|_          |API 参考|_         |H/W 参考|_