feat: Update esptool to v5

docs/en/api-guides/bootloader.rst

@@ -202,7 +202,7 @@ If the bootloader grows too large then it can collide with the partition table,
 
     The recovery bootloader feature enables safe OTA updates of the bootloader itself. When the eFuse field ``ESP_EFUSE_RECOVERY_BOOTLOADER_FLASH_SECTOR`` is set, it specifies the flash address (in sectors) of the recovery bootloader. If the primary bootloader at {IDF_TARGET_CONFIG_BOOTLOADER_OFFSET_IN_FLASH} fails to load, the ROM bootloader attempts to load the recovery bootloader from this address.
 
-    - The eFuse can be set using ``espefuse.py`` or by calling :cpp:func:`esp_efuse_set_recovery_bootloader_offset()` in the user application.
+    - The eFuse can be set using ``espefuse`` or by calling :cpp:func:`esp_efuse_set_recovery_bootloader_offset()` in the user application.
     - The address can be set using ``CONFIG_BOOTLOADER_RECOVERY_OFFSET``. This value must be a multiple of the flash sector size (0x1000 bytes). The Kconfig option helps ensure that the recovery bootloader does not overlap with existing partitions.
     - Note that the eFuse field stores the offset in sectors. Setting it to the maximum value ``0xFFF`` disables the feature.
     - The recovery bootloader image at the ``CONFIG_BOOTLOADER_RECOVERY_OFFSET`` is not flashed by default. It can be written as part of the OTA update process.

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

@@ -54,7 +54,7 @@ The ``idf.py`` command-line tool provides a front-end for easily managing your p
 
 - CMake_, which configures the project to be built
 - Ninja_ which builds the project
-- `esptool.py`_ for flashing the target.
+- `esptool`_ for flashing the target.
 
 For more details about configuring the build system using ``idf.py``, please refer to :doc:`IDF Frontend <tools/idf-py>`.
 
@@ -718,7 +718,7 @@ Project_include.cmake
 
 For components that have build requirements that must be evaluated before any component CMakeLists files are evaluated, you can create a file called ``project_include.cmake`` in the component directory. This CMake file is included when ``project.cmake`` is evaluating the entire project.
 
-``project_include.cmake`` files are used inside ESP-IDF, for defining project-wide build features such as ``esptool.py`` command line arguments and the ``bootloader`` "special app".
+``project_include.cmake`` files are used inside ESP-IDF, for defining project-wide build features such as ``esptool`` command line arguments and the ``bootloader`` "special app".
 
 Unlike component ``CMakeLists.txt`` files, when including a ``project_include.cmake`` file the current source directory (``CMAKE_CURRENT_SOURCE_DIR`` and working directory) is the project directory. Use the variable ``COMPONENT_DIR`` for the absolute directory of the component.
 
@@ -1109,7 +1109,7 @@ You can find more detailed information on how the project configuration works in
 Flash Arguments
 ===============
 
-There are some scenarios that we want to flash the target board without IDF. For this case we want to save the built binaries, esptool.py and esptool write_flash arguments. It's simple to write a script to save binaries and esptool.py.
+There are some scenarios that we want to flash the target board without IDF. For this case we want to save the built binaries, esptool and esptool write-flash arguments. It's simple to write a script to save binaries and esptool.
 
 After running a project build, the build directory contains binary output files (``.bin`` files) for the project and also the following flashing data files:
 
@@ -1119,9 +1119,9 @@ After running a project build, the build directory contains binary output files
 
 .. highlight:: bash
 
-You can pass any of these flasher argument files to ``esptool.py`` as follows::
+You can pass any of these flasher argument files to ``esptool`` as follows::
 
-  python esptool.py --chip esp32 write_flash @build/flash_project_args
+  esptool --chip esp32 write-flash @build/flash_project_args
 
 Alternatively, it is possible to manually copy the parameters from the argument file and pass them on the command line.
 
@@ -1567,7 +1567,7 @@ For integration into IDEs and other build systems, when CMake runs the build pro
 
 - ``compile_commands.json`` is a standard format JSON file which describes every source file which is compiled in the project. A CMake feature generates this file, and many IDEs know how to parse it.
 - ``project_description.json`` contains some general information about the ESP-IDF project, configured paths, etc.
-- ``flasher_args.json`` contains esptool.py arguments to flash the project's binary files. There are also ``flash_*_args`` files which can be used directly with esptool.py. See `Flash arguments`_.
+- ``flasher_args.json`` contains esptool arguments to flash the project's binary files. There are also ``flash_*_args`` files which can be used directly with esptool. See `Flash arguments`_.
 - ``CMakeCache.txt`` is the CMake cache file which contains other information about the CMake process, toolchain, etc.
 - ``config/sdkconfig.json`` is a JSON-formatted version of the project configuration values.
 - ``config/kconfig_menus.json`` is a JSON-formatted version of the menus shown in menuconfig, for use in external IDE UIs.
@@ -1750,7 +1750,7 @@ Application Examples
 .. _esp-idf-template: https://github.com/espressif/esp-idf-template
 .. _cmake: https://cmake.org
 .. _ninja: https://ninja-build.org
-.. _esptool.py: https://github.com/espressif/esptool/#readme
+.. _esptool: https://github.com/espressif/esptool/#readme
 .. _CMake v3.22 documentation: https://cmake.org/cmake/help/v3.22/index.html
 .. _cmake command line documentation: https://cmake.org/cmake/help/v3.22/manual/cmake.1.html#options
 .. _cmake add_library: https://cmake.org/cmake/help/v3.22/command/add_library.html

docs/en/api-guides/partition-tables.rst

@@ -311,14 +311,14 @@ The binary format of the partition table contains an MD5 checksum computed based
 Flashing the Partition Table
 ----------------------------
 
-* ``idf.py partition-table-flash``: will flash the partition table with esptool.py.
+* ``idf.py partition-table-flash``: will flash the partition table with esptool.
 * ``idf.py flash``: Will flash everything including the partition table.
 
 A manual flashing command is also printed as part of ``idf.py partition-table`` output.
 
 .. note::
 
-    Note that updating the partition table does not erase data that may have been stored according to the old partition table. You can use ``idf.py erase-flash`` (or ``esptool.py erase_flash``) to erase the entire flash contents.
+    Note that updating the partition table does not erase data that may have been stored according to the old partition table. You can use ``idf.py erase-flash`` (or ``esptool erase-flash``) to erase the entire flash contents.
 
 
 Partition Tool (``parttool.py``)
@@ -406,13 +406,13 @@ The command-line interface of `parttool.py` has the following structure:
 
 .. note::
 
-    If the device has already enabled ``Flash Encryption`` or ``Secure Boot``, attempting to use commands that modify the flash content, such as ``erase_partition`` or ``write_partition``, will result in an error. This error is generated by the erase command of ``esptool.py``, which is called first before writing. This error is done as a safety measure to prevent bricking your device.
+    If the device has already enabled ``Flash Encryption`` or ``Secure Boot``, attempting to use commands that modify the flash content, such as ``erase_partition`` or ``write_partition``, will result in an error. This error is generated by the erase command of ``esptool``, which is called first before writing. This error is done as a safety measure to prevent bricking your device.
 
     .. code-block:: none
 
         A fatal error occurred: Active security features detected, erasing flash is disabled as a safety measure. Use --force to override, please use with caution, otherwise it may brick your device!
 
-    To work around this, you need use the ``--force`` flag with ``esptool.py``. Specifically, the ``parttool.py`` provides the ``--esptool-erase-args`` argument that help to pass this flag to ``esptool.py``.
+    To work around this, you need use the ``--force`` flag with ``esptool``. Specifically, the ``parttool.py`` provides the ``--esptool-erase-args`` argument that help to pass this flag to ``esptool``.
 
     .. code-block:: bash
 

docs/en/api-guides/tools/idf-docker-image.rst

@@ -130,7 +130,7 @@ And then starting the server by executing
 
 .. code-block:: bash
 
-    esp_rfc2217_server.py -v -p 4000 /dev/ttyUSB0
+    esp_rfc2217_server -v -p 4000 /dev/ttyUSB0
 
 Now the device attached to the host can be flashed from inside a Docker container by using:
 

docs/en/api-guides/tools/idf-py.rst

@@ -7,7 +7,7 @@ The ``idf.py`` command-line tool provides a front-end for easily managing your p
 
 - CMake_, which configures the project to be built.
 - Ninja_, which builds the project.
-- `esptool.py`_, which flashes the target.
+- `esptool`_, which flashes the target.
 
 The :ref:`Step 5. First Steps on ESP-IDF <get-started-configure>` contains a brief introduction on how to set up ``idf.py`` to configure, build, and flash projects.
 
@@ -120,7 +120,7 @@ This command automatically builds the project if necessary, and then flash it to
 
 .. note:: The environment variables ``ESPPORT`` and ``ESPBAUD`` can be used to set default values for the ``-p`` and ``-b`` options, respectively. Providing these options on the command line overrides the default.
 
-``idf.py`` uses the ``write_flash`` command of ``esptool.py`` under the hood to flash the target. You can pass additional arguments to configure the flash writing process using the ``--extra-args`` option. For example, to `write to an external SPI flash chip <https://docs.espressif.com/projects/esptool/en/latest/esptool/advanced-options.html#custom-spi-pin-configuration>`_, use the following command: ``idf.py flash --extra-args="--spi-connection <CLK>,<Q>,<D>,<HD>,<CS>"``. To see the full list of available arguments, run ``esptool.py write_flash --help`` or see the `esptool.py documentation <https://docs.espressif.com/projects/esptool/en/latest/esptool/index.html>`_.
+``idf.py`` uses the ``write-flash`` command of ``esptool`` under the hood to flash the target. You can pass additional arguments to configure the flash writing process using the ``--extra-args`` option. For example, to `write to an external SPI flash chip <https://docs.espressif.com/projects/esptool/en/latest/esptool/advanced-options.html#custom-spi-pin-configuration>`_, use the following command: ``idf.py flash --extra-args="--spi-connection <CLK>,<Q>,<D>,<HD>,<CS>"``. To see the full list of available arguments, run ``esptool write-flash --help`` or see the `esptool documentation <https://docs.espressif.com/projects/esptool/en/latest/esptool/index.html>`_.
 
 Similarly to the ``build`` command, the command can be run with ``app``, ``bootloader`` and ``partition-table`` arguments to flash only the app, bootloader or partition table as applicable.
 
@@ -152,7 +152,7 @@ There are also some format specific options, which are listed below:
 - Only for raw format:
 
   - ``--flash-offset``: This option will create a merged binary that should be flashed at the specified offset, instead of at the standard offset of 0x0.
-  - ``--fill-flash-size``: If set, the final binary file will be padded with FF bytes up to this flash size in order to fill the full flash content with the image and re-write the whole flash chip upon flashing.
+  - ``--pad-to-size``: If set, the final binary file will be padded with FF bytes up to this flash size in order to fill the full flash content with the image and re-write the whole flash chip upon flashing.
 
 - Only for uf2 format:
 
@@ -407,6 +407,6 @@ Basic Usage Examples
 
 .. _cmake: https://cmake.org
 .. _ninja: https://ninja-build.org
-.. _esptool.py: https://github.com/espressif/esptool/#readme
+.. _esptool: https://github.com/espressif/esptool/#readme
 .. _CCache: https://ccache.dev/
 .. _click context: https://click.palletsprojects.com/en/stable/api/#context

docs/en/api-guides/usb-otg-console.rst

@@ -6,7 +6,7 @@ USB OTG Console
 On chips with an integrated USB peripheral, it is possible to use USB Communication Device Class (CDC) to implement the serial console, instead of using UART with an external USB-UART bridge chip. {IDF_TARGET_NAME} ROM code contains a USB CDC implementation, which supports for some basic functionality without requiring the application to include the USB stack:
 
 * Bidirectional serial console, which can be used with :doc:`IDF Monitor <tools/idf-monitor>` or another serial monitor.
-* Flashing using ``esptool.py`` and ``idf.py flash``.
+* Flashing using ``esptool`` and ``idf.py flash``.
 * :doc:`Device Firmware Update (DFU) <dfu>` interface for flashing the device using ``dfu-util`` and ``idf.py dfu``.
 
 .. note::

docs/en/api-guides/usb-serial-jtag-console.rst

@@ -9,7 +9,7 @@ Generally, ESP chips implement a serial port using UART and can be connected to
 {IDF_TARGET_NAME} contains a USB Serial/JTAG Controller providing the following functions:
 
 * Bidirectional serial console, which can be used with :doc:`IDF Monitor <tools/idf-monitor>` or another serial monitor.
-* Flashing using ``esptool.py`` and ``idf.py flash``.
+* Flashing using ``esptool`` and ``idf.py flash``.
 * JTAG debugging, performed simultaneously with serial operations using tools like OpenOCD.
 
 .. note::