Add Support & Documentation for ESP32-S3 + ESP32-C6 (RCP) Coexistence Pin Mapping & Minimal Hardware Requirements (TZ-2198)

[kunjsn123]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Described the feature in detail and justified the reason for the request.
• Provided specific use cases and examples.

Feature description

Feature Description

Currently, the basic_thread_border_router and related hardware documentation for esp-thread-br do not clearly define how to design a custom board using:

• ESP32-S3 as the Thread Border Router host (Wi-Fi + IP stack)
• ESP32-C6 as the Thread RCP (802.15.4 radio)

The official Thread/Zigbee gateway schematic includes PTA coexistence signals:

WL_ACTIVE
BT_ACTIVE
BT_PRIORITY

These are routed through 0-ohm resistors between the radio module and the ESP32-S3.
However, there is no documentation describing:

1. Whether these coexistence lines are required when replacing the H2 with an ESP32-C6 in RCP role.
2. Which C6 GPIO pins should be used for the coexistence interface.
3. Whether coexistence can be safely disabled when Wi-Fi is only active on the S3 and 802.15.4 is only active on C6.
4. Minimal hardware guidelines for designing a combined S3 (host) + C6 (RCP) board.

This makes it difficult to design a correct, reliable dual-SoC Thread Border Router without reverse-engineering existing schematics.

Requested Feature:

• Official documentation + examples describing:

  • Required / optional coexistence pins for S3 + C6 deployments
  • Recommended GPIO mapping for ESP32-C6 (RCP) coexistence lines
  • Minimal hardware schematic guidelines for S3 + C6 border-router architecture
  • Whether coexistence can be omitted when the radios do NOT share the same RF path
  • Firmware configuration (menuconfig) for custom coexistence pin mapping

This would prevent hardware mistakes and make it easier for developers building commercial border-router boards.

---

Use cases

1. Custom Thread Border Router Products
   Developers integrating ESP32-S3 (host) with ESP32-C6 (RCP) require minimal and correct hardware wiring.
   Missing coexistence documentation leads to guesswork and unreliable RF performance.

2. Community Hardware Designs
   Many users want to adapt the example schematic but do not know which coexistence nets must be kept or removed.

3. Reducing Bring-up Time & Board Revisions
   Clear documentation avoids PCB re-spins, preventing GPIO conflicts or missing coexistence lines.

4. Proper RF Coexistence
   When Wi-Fi and Thread radios must share an antenna or RF switch, coexistence pins are critical.
   Developers need explicit instructions.

---

Alternatives

Alternatives Considered

• Ignoring coexistence pins entirely — works only in limited setups and leads to degraded Thread reliability in real deployments.
• Manually trying different GPIO mappings on the C6 — risky and undocumented.
• Digging through SDK source to infer pin requirements — impractical and not guaranteed stable.

These alternatives are insufficient; formal documentation from Espressif is necessary.

---

Additional context

Additional Context

Reference schematic:
ESP Thread/Zigbee Gateway Schematic v1.2
https://dl.espressif.com/dl/schematics/esp_thread_br_zigbee_gw_schematiccs_v1.2.pdf

The section containing PTA signals (WL_ACTIVE, BT_ACTIVE, BT_PRIORITY) is unclear when substituting ESP32-C6 for ESP32-H2.

A concise guidance document or example schematic snippet for an ESP32-S3 + ESP32-C6-MINI-1 hardware design would solve the ambiguity for many developers.

[kunjsn123]

cc: @zwx1995esp @gytxxsy @chshu

This hardware clarification is blocking completion of our S3 + C6 (RCP) border-router design.

Please provide an update or guidance as soon as possible, specifically regarding:

• Whether PTA coexistence lines are required for S3 + C6,
• Recommended GPIO mapping for the C6 RCP,
• Minimal hardware requirements for stable Wi-Fi + Thread operation.

Your confirmation will prevent unnecessary PCB revisions on our side.

[gytxxsy]

• Whether PTA coexistence lines are required for S3 + C6,

External coexistence is optional. Its applicability to Thread Border Router designs and the required signals are described in the RF External Coexistence documentation, with additional GPIO options and timing/electrical details provided in rf-external-coexistence and RF External Coexistence documentation Chapter 3: Design Implementation

• Recommended GPIO mapping for the C6 RCP,

• ESP32-C6 Datasheet
• RF External Coexistence documentation

If you plan to use the RCP update workflow, connect the ESP32-C6’s UART0 TX/RX pins to the ESP32-S3. The default pins are listed in the ESP32-C6 datasheet, so please refer to it for the exact UART0 pin mapping.
For SPI(optional), select any GPIOs documented in the ESP32-C6 datasheet as supporting SPI functions and follow the listed electrical specifications.

[kunjsn123]

• Whether PTA coexistence lines are required for S3 + C6,

External coexistence is optional. Its applicability to Thread Border Router designs and the required signals are described in the RF External Coexistence documentation, with additional GPIO options and timing/electrical details provided in rf-external-coexistence and RF External Coexistence documentation Chapter 3: Design Implementation

• Recommended GPIO mapping for the C6 RCP,

• ESP32-C6 Datasheet
• RF External Coexistence documentation

If you plan to use the RCP update workflow, connect the ESP32-C6’s UART0 TX/RX pins to the ESP32-S3. The default pins are listed in the ESP32-C6 datasheet, so please refer to it for the exact UART0 pin mapping. For SPI(optional), select any GPIOs documented in the ESP32-C6 datasheet as supporting SPI functions and follow the listed electrical specifications.

Thanks for the clarification @gytxxsy .

I have a few follow-up questions regarding the RCP host connection:

1. Is SPI-based OpenThread RCP officially supported on ESP32-C6 (ot_rcp), or is UART currently the only recommended and fully validated host connection mode?

2. If SPI RCP is supported:

   • Is there any reference example or documentation in ESP-IDF for configuring ESP32-C6 as an SPI-based RCP?
   • Are there known limitations or considerations when using SPI RCP with esp-thread-br compared to UART?

3. From Espressif’s perspective, which host connection mode (UART or SPI) is generally preferred for an ESP32-S3 (host) + ESP32-C6 (RCP) Thread Border Router, and why?

Currently, while referring to the following example:
https://github.com/espressif/esp-thread-br/tree/main/examples/basic_thread_border_router

we only see documented and tested RCP configuration using UART, and do not find clear guidance or examples for RCP configuration or update via SPI.

We also noticed the following SPI RCP configuration in the codebase and would like to confirm whether this configuration is valid and recommended for ESP32-C6:

#elif CONFIG_OPENTHREAD_RCP_SPI

#if CONFIG_IDF_TARGET_ESP32C6
#define OPENTHREAD_RCP_SPI_MOSI_PIN     2
#define OPENTHREAD_RCP_SPI_MISO_PIN     4
#define OPENTHREAD_RCP_SPI_SCLK_PIN     3
#define OPENTHREAD_RCP_SPI_CS_PIN       18
#define OPENTHREAD_RCP_SPI_INTR_PIN     9
#elif CONFIG_IDF_TARGET_ESP32H2
#define OPENTHREAD_RCP_SPI_MOSI_PIN     3
#define OPENTHREAD_RCP_SPI_MISO_PIN     1
#define OPENTHREAD_RCP_SPI_SCLK_PIN     0
#define OPENTHREAD_RCP_SPI_CS_PIN       2
#define OPENTHREAD_RCP_SPI_INTR_PIN     9
#else
#error "Unsupported chip for OpenThread RCP SPI"
#endif

#define ESP_OPENTHREAD_DEFAULT_HOST_CONFIG()                    \
    {                                                           \
        .host_connection_mode = HOST_CONNECTION_MODE_RCP_SPI,   \
        .spi_slave_config = {                                   \
            .host_device = SPI2_HOST,                           \
            .bus_config = {                                     \
                .mosi_io_num = OPENTHREAD_RCP_SPI_MOSI_PIN,     \
                .miso_io_num = OPENTHREAD_RCP_SPI_MISO_PIN,     \
                .sclk_io_num = OPENTHREAD_RCP_SPI_SCLK_PIN,     \
                .quadhd_io_num = -1,                            \
                .quadwp_io_num = -1,                            \
                .isr_cpu_id = ESP_INTR_CPU_AFFINITY_AUTO,       \
            },                                                  \
            .slave_config = {                                   \
                .mode = 0,                                      \
                .spics_io_num = OPENTHREAD_RCP_SPI_CS_PIN,      \
                .queue_size = 3,                                \
                .flags = 0,                                     \
            },                                                  \
            .intr_pin = OPENTHREAD_RCP_SPI_INTR_PIN,            \
        },                                                      \
    }

Could you please confirm:

• Whether the above SPI pin mapping and configuration are valid for ESP32-C6,
• Whether these GPIOs are only examples or intended as recommended defaults,
• And whether this SPI-based RCP configuration is considered production-ready or experimental compared to UART.

This clarification will help us finalize our hardware and interface selection.

[gytxxsy]

1. Is SPI-based OpenThread RCP officially supported on ESP32-C6 (ot_rcp), or is UART currently the only recommended and fully validated host connection mode?

2. If SPI RCP is supported:

   • Is there any reference example or documentation in ESP-IDF for configuring ESP32-C6 as an SPI-based RCP?
   • Are there known limitations or considerations when using SPI RCP with esp-thread-br compared to UART?

3. From Espressif’s perspective, which host connection mode (UART or SPI) is generally preferred for an ESP32-S3 (host) + ESP32-C6 (RCP) Thread Border Router, and why?

In the IEEE 802.15.4-2003, the theoretical maximum data rate is 250 kbps. Therefore, when the UART baud rate is sufficient to meet this requirement (for example, 460800), Spinel communication is no longer the primary factor limiting Thread throughput. In our current mature solutions (including certified deployments and real-world customer production), UART is consistently used. In addition, the RCP update functionality also requires UART.

Overall, we recommend using the UART solution, as it effectively meets all currently known use cases. At present, there is no urgent demand for SPI-based Spinel communication in known scenarios; it remains an experimental solution.