docs: update cn trans for api-guides

docs/en/api-guides/fatal-errors.rst

@@ -284,7 +284,7 @@ The GDB prompt can be used to inspect CPU registers, local and static variables,
 RTC Watchdog Timeout
 --------------------
 
-The RTC watchdog is used in the startup code to keep track of execution time and also helps to prevent a lock up caused by an unstable power source, it is enabled by default, see :ref:`CONFIG_BOOTLOADER_WDT_ENABLE`. If the execution time is exceeded, the RTC watchdog will restart the system. In this case, the ROM bootloader will print a message with the ``RTC Watchdog Timeout`` reason for the reboot.
+The RTC watchdog is used in the startup code to keep track of execution time and it also helps to prevent a lock-up caused by an unstable power source. It is enabled by default (see :ref:`CONFIG_BOOTLOADER_WDT_ENABLE`). If the execution time is exceeded, the RTC watchdog will restart the system. In this case, the ROM bootloader will print a message with the ``RTC Watchdog Timeout`` reason for the reboot.
 
 .. only:: esp32
 
@@ -298,7 +298,7 @@ The RTC watchdog is used in the startup code to keep track of execution time and
 
         rst:0x10 (RTCWDT_RTC_RST)
 
-The RTC watchdog covers the execution time from the first stage bootloader (ROM bootloader) to application startup. It is initially set in the ROM bootloader, then configured in the bootloader with the :ref:`CONFIG_BOOTLOADER_WDT_TIME_MS` option (9000ms by default). During the application initialization stage, it is reconfigured again because the source of the slow clock may have changed, and finally disabled right before the ``app_main()`` call. There is an option :ref:`CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE` which allows the RTC watchdog to not be disabled before ``app_main`` and instead the RTC watchdog remains active and must be explicitly reset in your application.
+The RTC watchdog covers the execution time from the first stage bootloader (ROM bootloader) to application startup. It is initially set in the ROM bootloader, then configured in the bootloader with the :ref:`CONFIG_BOOTLOADER_WDT_TIME_MS` option (9000 ms by default). During the application initialization stage, it is reconfigured because the source of the slow clock may have changed, and finally disabled right before the ``app_main()`` call. There is an option :ref:`CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE` which prevents the RTC watchdog from being disabled before ``app_main``. Instead, the RTC watchdog remains active and must be fed periodically in your application's code.
 
 .. _Guru-Meditation-Errors:
 

docs/en/api-guides/linker-script-generation.rst

@@ -13,7 +13,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 or the ULP coprocessor.
+    :SOC_RTC_MEM_SUPPORTED: * 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.

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

@@ -127,6 +127,7 @@ If a function is not explicitly placed into :ref:`iram` or RTC memory, it is pla
 
 During :doc:`startup`, the bootloader (which runs from IRAM) configures the MMU flash cache to map the app's instruction code region to the instruction space. Flash accessed via the MMU is cached using some internal SRAM and accessing cached flash data is as fast as accessing other types of internal memory.
 
+
 .. _drom:
 
 DROM (data stored in flash)

docs/zh_CN/api-guides/bootloader.rst

@@ -150,7 +150,6 @@ ROM 中的 :ref:`first-stage-bootloader` 从 flash 中读取 :ref:`second-stage-
 
     引导加载程序有 :ref:`CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP` 选项，可以减少从深度睡眠中唤醒的时间（有利于降低功耗）。当 :ref:`CONFIG_SECURE_BOOT` 选项禁用时，该选项可用。由于无需镜像校验，唤醒时间减少。在第一次启动时，引导加载程序将启动的应用程序的地址存储在 RTC FAST 存储器中。而在唤醒过程中，这个地址用于启动而无需任何检查，从而实现了快速加载。
 
-
 自定义引导加载程序
 ----------------------
 

docs/zh_CN/api-guides/fatal-errors.rst

@@ -279,6 +279,27 @@ GDB Stub
 
 在 GDB 会话中，我们可以检查 CPU 寄存器，本地和静态变量以及内存中任意位置的值。但是不支持设置断点，改变 PC 值或者恢复程序的运行。若要复位程序，请退出 GDB 会话，在 IDF 监视器 中连续输入 Ctrl-T Ctrl-R，或者按下开发板上的复位按键也可以重新运行程序。
 
+.. _RTC-Watchdog-Timeout:
+
+RTC 看门狗超时
+----------------
+
+RTC 看门狗在启动代码中用于跟踪执行时间，也有助于防止由于电源不稳定引起的锁定。RTC 看门狗默认启用，参见 :ref:`CONFIG_BOOTLOADER_WDT_ENABLE`。如果执行时间超时，RTC 看门狗将自动重启系统。此时，ROM 引导加载程序将打印消息 ``RTC Watchdog Timeout`` 说明重启原因。
+
+.. only:: esp32
+
+    ::
+
+        rst:0x10 (RTCWDT_RTC_RESET)
+
+.. only:: not esp32
+
+    ::
+
+        rst:0x10 (RTCWDT_RTC_RST)
+
+RTC 看门狗涵盖了从一级引导程序（ROM 引导程序）到应用程序启动的执行时间，最初在 ROM 引导程序中设置，而后在引导程序中使用 :ref:`CONFIG_BOOTLOADER_WDT_TIME_MS` 选项进行配置（默认 9000 ms）。在应用初始化阶段，由于慢速时钟源可能已更改，RTC 看门狗将被重新配置，最后在调用 ``app_main()`` 之前被禁用。可以使用选项 :ref:`CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE` 以保证 RTC 看门狗在调用 ``app_main`` 之前不被禁用，而是保持运行状态，用户需要在应用代码中定期“喂狗”。
+
 .. _Guru-Meditation-Errors:
 
 Guru Meditation 错误

docs/zh_CN/api-guides/linker-script-generation.rst

@@ -7,13 +7,14 @@
 
 {IDF_TARGET_NAME} 中有多个用于存放代码和数据的 :ref:`内存区域<memory-layout>` 。代码和只读数据默认存放在 flash 中，可写数据存放在 RAM 中。不过有时，用户必须更改默认存放区域。
 
-.. only:: SOC_ULP_SUPPORTED
+例如：
 
-    例如为了提高性能，将关键代码存放到 RAM 中，或者将代码存放到 RTC 存储器中以便在 wake up stub 和 ULP 协处理器中使用。
+.. list::
 
-.. only:: not SOC_ULP_SUPPORTED
-
-    例如为了提高性能，将关键代码存放到 RAM 中，或者将代码存放到 RTC 存储器中以便在wake up stub 中使用。
+    * 将关键代码存放到 RAM 中以提高性能；
+    * 将可执行代码存放到 IRAM 中，以便在缓存被禁用时运行这些代码；
+    :SOC_RTC_MEM_SUPPORTED: * 将代码存放到 RTC 存储器中，以便在 wake stub 中使用；
+    :SOC_ULP_SUPPORTED: * 将代码存放到 RTC 内存中，以便 ULP 协处理器使用。
 
 链接器脚本生成机制可以让用户指定代码和数据在 ESP-IDF 组件中的存放区域。组件包含如何存放符号、目标或完整库的信息。在构建应用程序时，组件中的这些信息会被收集、解析并处理；生成的存放规则用于链接应用程序。