feat(monitor): Add support for decoding output based on multiple ELF files

docs/en/api-reference/system/ulp-lp-core.rst

@@ -287,12 +287,17 @@ When programming the LP core, it can sometimes be challenging to figure out why
 
 * Share program state through shared variables: as described in :ref:`ulp-lp-core-access-variables`, both the main CPU and the ULP core can easily access global variables in RTC memory. Writing state information to such a variable from the ULP and reading it from the main CPU can help you discern what is happening on the ULP core. The downside of this approach is that it requires the main CPU to be awake, which will not always be the case. Keeping the main CPU awake might even, in some cases, mask problems, as some issues may only occur when certain power domains are powered down.
 
-* Panic handler: the LP core has a panic handler that can dump the state of the LP core registers by the LP-UART when an exception is detected. To enable the panic handler, set the :ref:`CONFIG_ULP_PANIC_OUTPUT_ENABLE` option to ``y``. This option can be kept disabled to reduce LP-RAM usage by the LP core application. To recover a backtrace from the panic dump, it is possible to use  esp-idf-monitor_., e.g.:
+* Panic handler: the LP core has a panic handler that can dump the state of the LP core registers by the LP-UART when an exception is detected. To enable the panic handler, set the :ref:`CONFIG_ULP_PANIC_OUTPUT_ENABLE` option to ``y``. This option can be kept disabled to reduce LP-RAM usage by the LP core application. To recover a backtrace from the panic dump, it is possible to use ``idf.py monitor``.
+
+.. warning::
+
+    If multiple ULP applications are used in a single project, backtrace decoding might not work correctly. In such cases, it is recommended to use the esp-idf-monitor_ tool directly with the correct ULP ELF file:
 
     .. code-block:: bash
 
         python -m esp_idf_monitor --toolchain-prefix riscv32-esp-elf- --target {IDF_TARGET_NAME} --decode-panic backtrace PATH_TO_ULP_ELF_FILE
 
+
 Debugging ULP LP Core Applications with GDB and OpenOCD
 -------------------------------------------------------
 

docs/zh_CN/api-reference/system/ulp-lp-core.rst

@@ -287,12 +287,17 @@ ULP LP 内核的时钟源来自系统时钟 ``LP_FAST_CLK``，详情请参见 `
 
 * 通过共享变量共享程序状态：如 :ref:`ulp-lp-core-access-variables` 所述，主 CPU 和 ULP 内核都可以轻松访问 RTC 内存中的全局变量。若想了解 ULP 内核的运行状态，可以将状态信息从 ULP 写入变量中，并通过主 CPU 读取信息。这种方法的缺点在于它需要主 CPU 一直处于唤醒状态，而这通常很难实现。另外，若主 CPU 一直处于唤醒状态，可能会掩盖某些问题，因为部分问题只会在特定电源域断电时发生。
 
-* 紧急处理程序：当检测到异常时，LP 内核的紧急处理程序会把 LP 内核寄存器的状态通过 LP-UART 发送出去。将 :ref:`CONFIG_ULP_PANIC_OUTPUT_ENABLE` 选项设置为 ``y``，可以启用紧急处理程序。禁用此选项将减少 LP 内核应用程序的 LP-RAM 使用量。若想从紧急转储中解析栈回溯，可以使用 esp-idf-monitor_，例如：
+* 紧急处理程序：当检测到异常时，LP 内核的紧急处理程序会把 LP 内核寄存器的状态通过 LP-UART 发送出去。将 :ref:`CONFIG_ULP_PANIC_OUTPUT_ENABLE` 选项设置为 ``y``，可以启用紧急处理程序。禁用此选项将减少 LP 内核应用程序的 LP-RAM 使用量。若想从紧急转储中解析栈回溯，可以使用 ``idf.py monitor``。
+
+.. warning::
+
+    如果在单个项目中使用多个 ULP 应用程序，栈回溯解码可能无法正常工作。此时建议直接使用 esp-idf-monitor_ 工具，并指定正确的 ULP ELF 文件：
 
     .. code-block:: bash
 
         python -m esp_idf_monitor --toolchain-prefix riscv32-esp-elf- --target {IDF_TARGET_NAME} --decode-panic backtrace PATH_TO_ULP_ELF_FILE
 
+
 调试 ULP LP 内核应用程序：使用 GDB 和 OpenOCD
 ----------------------------------------------
 

tools/idf_py_actions/serial_ext.py

@@ -5,6 +5,7 @@ import os
 import shlex
 import signal
 import sys
+from pathlib import Path
 from typing import Any
 from typing import Dict
 from typing import List
@@ -170,8 +171,11 @@ def action_extensions(base_actions: Dict, project_path: str) -> Dict:
         if print_filter is not None:
             monitor_args += ['--print_filter', print_filter]
 
+        elf_list = [str(elf) for elf in Path(args.build_dir).rglob('*.elf')]
         if elf_file:
-            monitor_args += [elf_file]
+            # prepend the main app elf file to the list; make sure it is the first one
+            elf_list.insert(0, elf_list.pop(elf_list.index(elf_file)))
+        monitor_args.extend(elf_list)
 
         if encrypted:
             monitor_args += ['--encrypted']