AT FAQ

[中文]

AT Documentation

How to select the correct AT documentation version?

Please select the corresponding chip platform and documentation version based on the actual AT firmware version you are using; there may be functional and behavioral differences between different firmware versions.

  • For Officially Released Firmware (Recommended), you can directly obtain the corresponding document link through the AT+USERDOCS? command, without needing to confirm the version information.

  • For unofficial firmware, please confirm the following information first, and then select the corresponding document version:

    • The chip platform of the AT firmware you are using (e.g., ESP32, ESP32-C3, etc.)

    • The version number of the AT firmware (you can use the AT+GMR command to view the version number of the AT core library)

    Choose AT documentation target and version

AT Firmware

There is no released firmware for my module. Where can I get the firmware for it?

If there is no released firmware for your module in AT Binary Lists, consider:

How to get the source code of AT firmware?

The esp-at project is distributed as a combination of source code and pre-compiled libraries in this repository. The pre-compiled core libraries (under the directory: esp-at/components/at/lib/) are closed-source, and there is no plan for open-sourcing them.

How to download the AT firmware on Espressif’s official website?

Download the Flash Download Tool. Refer to the Flash Download Tool User Guide for instructions. See AT Downloading Guide for the download address.

How to combine all the bin files compiled by ESP-AT?

No manual combination is required. The released and compiled firmware already includes pre-combined 2MB/4MB bin files in the build/factory directory.

Why does a newly purchased ESP series module print “flash read err” error after power-up? How to use AT commands?

ESP series modules are shipped without ESP-AT firmware in Flash, so the error “flash read err” is reported after power-up. To use AT commands, refer to AT Downloading Guide.

Does the AT firmware shipped in modules support flow control?

Hardware flow control is supported, but software flow control is not. Configure hardware flow control using AT+UART_CUR or AT+UART_DEF. See Hardware connection for wiring details.

AT Commands and Responses

Why does AT prompt busy p…?

The “busy p…” prompt indicates that the previous command is being executed, and the system cannot respond to the current input. AT commands are processed serially, so you must wait for the previous command to complete before receiving the next one.

When there are extra invisible characters (such as spaces after a command), the system will also prompt “busy p…” or “ERROR”, because any serial port input is considered a command input.

If the MCU sends AT+CIPSEND and receives a busy p… response, it means the previous command is still executing and the current input is invalid. Wait for the previous command response to complete before sending a new command.

Why does the AT firmware always return the following message after I power up the device and send the first command?

ERR CODE:0x010b0000
busy p...

This message means “the previous command is being executed”. Normally only “busy p…” is displayed. The ERR CODE is shown because the error code prompt is enabled.

If you receive this error on the first command after power-up, possible reasons:

  • The command is followed by unnecessary newline/space/other symbols

  • Multiple AT commands were sent in succession

What commands are supported by the default AT firmware on different modules, and from which version are they supported?

Commands supported by default firmware on different modules: refer to ESP-AT Firmware Differences

Command version support and fixes: refer to release notes

When the host MCU sends an AT command to the ESP32-C6 device, there is no response. What is the reason?

A terminator (“AT\r\n”) must be added after an AT command. See Check Whether AT Works.

How to handle special characters in AT commands?

Refer to the escape character syntax described in the AT Command Types section.

Can the serial port baudrate be modified in AT Commands? (Default: 115200)

Yes, you can use one of the three ways below to modify it:

How to modify the UART pins of the AT command port?

You can use either of the three ways below to modify it:

  • Please refer to the How to set AT port pins document. Modify the UART configuration parameters in the factory_param_data.csv file, then recompile and flash the firmware.

  • If you want to modify the UART configuration at runtime through AT commands without recompiling the firmware, please refer to AT+SYSMFG command examples. This method allows you to dynamically modify the factory default UART configuration, including baudrate, pins, and other parameters.

  • If you already have AT firmware and only need to modify the UART pins, you can use the at.py tool to directly modify the firmware parameters without recompiling.

How to solve TCP/SSL data loss during transmission?

If data loss occurs without hardware flow control enabled, it is recommended to enable hardware flow control (AT+UART_CUR or AT+UART_DEF) to verify if it is caused by the lack of flow control. If the problem persists after enabling flow control, please refer to Debugging the Data Sending and Receiving Process of TCP Connections for further troubleshooting; if it is confirmed to be an issue caused by AT, please submit an issue on esp-at/issues.

After ESP32-C6 enters the passthrough mode using AT commands, can ESP32-C6 give a message if the connected hotspot is disconnected?

Configure with AT+SYSMSG, set AT+SYSMSG=4. The serial port will report WIFI DISCONNECT\\r\\n when the connected hotspot is disconnected.

Note: This command was added after AT v2.1.0.0. It is not available for v2.1.0.0 and earlier versions.

Why is Wi-Fi disconnected (WIFI DISCONNECT)?

Check the disconnection reason on AT log port, which prints wifi disconnected, rc:<reason_code>. See Wi-Fi Reason Code for details.

Generic firmware may not provide detailed reasons. To obtain specific information, register the Wi-Fi disconnect event in code and output reason code.

What are the common Wi-Fi compatibility issues?

  • AMPDU compatibility issue.

    • If the router does not support AMPDU, ESP32-C6 will automatically disable the AMPDU function when interacting with the router.

    • If the router supports AMPDU but there is a compatibility issue with AMPDU transmission between the router and ESP32-C6, it is recommended to disable the function on the router or ESP32-C6. For information on how to disable it on ESP32-C6, please refer to Compile ESP-AT Project Locally and select the following options in the fifth step of configuring the project:

      • Disable Component config > Wi-Fi > WiFi AMPDU TX

      • Disable Component config > Wi-Fi > WiFi AMPDU RX

  • Phy mode compatibility issue. If there is a compatibility issue with the phy mode between the router and ESP32-C6, it is recommended to switch it on the router or ESP32-C6. For how to switch it on ESP32-C6, please refer to the AT+CWSTAPROTO command.

Do AT commands support ESP-WIFI-MESH?

Currently, AT commands do not support ESP-WIFI-MESH.

Can AT commands set Bluetooth LE transmit power?

Yes, use the AT+RFPOWER command to set Bluetooth LE transmit power. ESP32-C6 Wi-Fi and Bluetooth LE share the same antenna.

How to enable the notify and indicate functions on Bluetooth LE clients?

  • Besides the read and write properties, Bluetooth LE characteristics also have the notify and indicate properties, which allow the server to send data to the client, but the client must first register for notification by writing the value of “CCCD”.

  • To enable notify, write 0x01. To enable indicate, write 0x02 (for the descriptor “0x2902”). To enable both notify and indicate, write 0x03.

  • The example below demonstrates how to enable the notify and indicate properties for the descriptor 0x2902 under the services 0xC305 and 0xC306 respectively. ESP-AT includes these two services by default. You can notify 0xC305 and indicate 0xC306.

    AT+BLEGATTCWR=0,3,6,1,2
>
// Write low byte 0x01 high byte 0x00 (if you want to use hex format, it is: 0100)
OK
// Server: +WRITE:0,1,6,1,2,<0x01>,<0x00>
AT+BLEGATTCWR=0,3,7,1,2
>
// Write low byte 0x02 high byte 0x00 (if you want to use hex format, it is: 0200)
OK
// Server: +WRITE:0,1,6,1,2,<0x02>,<0x00>
// Writing ccc is a prerequisite for the server to be able to send notify and indicate

Hardware

How big is the chip flash required for AT firmware on different modules?

Refer to ESP-AT Firmware Differences.

How to view the error log of AT firmware?

Usually check the error log from AT log port.

The UART1 communication pin used by AT on the ESP32-C6 module is inconsistent with the default UART1 pin described in the ESP32-C6 module’s datasheet?

ESP32-C6 supports IO matrix. When compiling ESP-AT, you can configure UART1 pins in menuconfig, so they may be inconsistent with the pins described in the module datasheet. See factory_param_data.csv for details.

Performance

How long does it take for AT to connect to Wi-Fi?

In an office scenario, AT takes about 5 seconds to connect. Actual connection time depends on router performance, network environment, module antenna performance, etc. The maximum timeout can be set using the <jap_timeout> parameter of AT+CWJAP.

Is it possible to change the TCP send window size in AT firmware?

It cannot be changed by AT commands. Re-compile the firmware and configure in menuconfig: Component config > LWIP > TCP > Default send buffer size.

How to test and optimize the AT throughput?

It is recommended to use the iperf example in esp-idf for testing (use passthrough mode, adjust data length to 1460 bytes, and send data continuously). If the test rate does not meet your requirements, refer to How to Improve ESP-AT Throughput Performance.

How to modify the default maximum number of TCP segment retransmissions for AT?

By default, the maximum number of TCP segment retransmissions is 6 (range: [3-12]). Reconfigure it as follows:

Other

What interfaces of ESP32-C6 chips can be used to transmit AT commands?

How to enable debug log for AT?

Refer to the How to enable more AT debug logs document.

How to modify the default Wi-Fi mode when AT firmware starts for the first time?

Modify the source code. Call esp_wifi_set_mode() in the esp_at_ready_before() function to set the Wi-Fi mode, for example: esp_wifi_set_mode(WIFI_MODE_STA).

How does the AT command implement the functionality of resuming HTTP transfers after interrupts?

Two methods:

How to download files from HTTP server and store them to FATFS, or upload files from FATFS file system to HTTP server?

Refer to GitHub examples:

Do open ports reported by nmap on an AT device indicate a security risk?

Summary: Default AT firmware does not listen on any port after Wi-Fi is connected. If no connection or service was created via AT commands, open / open|filtered reported by nmap does not mean the firmware is providing a service.

Ports are used only with AT+CIPSTART, AT+CIPSERVER, AT+WEBSERVER, AT+MDNS, and similar commands.

Common causes of false positives

  • UDP scans are unreliable: nmap -sU uses ICMP port-unreachable to detect closed ports; without a reply, ports are marked open|filtered, which does not mean the port is listening. UDP and ICMP replies can be lost; full-port high-speed scans (e.g. -p 1-65535 -T4) cause more false positives and must not be treated as proof of open ports.

  • Wrong target or existing connections: Confirm the IP matches AT+CIFSR; high UDP ports come from AT+CIPSTART sockets; 5353 appears only after AT+MDNS is enabled.

Troubleshooting

  1. AT+CIFSR, AT+CIPSTATE? — verify IP and current connections; no listening ports is expected.

  2. TCP scan: sudo nmap -sS -p- <IP>; all closed if no connections were created.

  3. For UDP scans, use -T2 to slow down, or capture packets to confirm port-unreachable arrives.

  4. AT+RST, then only AT+CWJAP to connect Wi-Fi, and scan again.

If the issue persists, record the scan command, AT+GMR version, and AT command sequence, and report it at esp-at/issues.

The esp-idf-sbom scan of AT firmware reports many CVEs. Does this affect RED, EN 18031, or CRA compliance?

CVEs reported by tools such as esp-idf-sbom are associated with a specific version of a software component (library) and do not mean the final compiled AT firmware is necessarily affected. Most CVEs are only compiled into the firmware and become exploitable when the related feature or code path is enabled; for features that are not enabled in the AT firmware, the source code is not included in the final binary, so the corresponding vulnerability has no trigger conditions. Such CVEs therefore usually do not affect the AT firmware’s compliance with the cybersecurity requirements of the EU Radio Equipment Directive (RED, 2014/53/EU; Delegated Regulation (EU) 2022/30 and the harmonized EN 18031 series) or the Cyber Resilience Act (CRA). In such cases, a documented self-assessment is typically sufficient to justify the non-applicability of the reported CVE.

Scan results tend to overestimate the risk for the following reasons:

  • Tools match CVEs against public vulnerability databases (such as NVD) by component version number, reporting any version that falls within the affected range without analyzing whether the vulnerability is actually reachable in your specific build configuration.

  • ESP-AT tailors features via menuconfig (Kconfig). The source code of disabled features is not compiled into the firmware, so any vulnerabilities it carries do not exist in the final binary.

  • Even when the code is compiled into the firmware, a vulnerability often requires multiple preconditions to hold simultaneously; if any condition is not met, it cannot be exploited.

Take CVE-2026-34873 (Client Impersonation During TLS 1.3 Session Resumption) as an example. It affects Mbed TLS versions 3.5.0–3.6.5 and 4.0.0 (reported by the SBOM). According to the official security advisory, a deployment is affected only when Mbed TLS runs in the server role and meets all of the following conditions:

  • It supports both TLS 1.2 and TLS 1.3.

  • It is configured to authenticate clients.

  • It issues TLS 1.3 session tickets to authenticated clients for later session resumption.

Although the AT firmware can act as an SSL client via AT+CIPSTART and as an SSL server via AT+CIPSERVER, its Mbed TLS does not enable TLS 1.3 by default (it must be enabled manually in menuconfig; see Change the TLS Protocol Version). As a result, it neither negotiates TLS 1.3 nor issues TLS 1.3 session tickets, so the conditions above cannot be met. Therefore, although the SBOM reports this CVE based on the Mbed TLS version, the vulnerability is not reachable in the default AT firmware configuration and has no practical impact.

To handle reported CVEs, follow these steps:

  1. Review each CVE’s official description (e.g. NVD, component security advisories) to determine the configuration and runtime conditions required to trigger it.

  2. Compare against the actual AT firmware: check whether the related feature is enabled, whether the code is compiled in, and whether the trigger scenario can occur at runtime. Refer to How to Clone Project and Compile It to confirm the build configuration.

  3. Mark each CVE as affected / not affected with the rationale, as self-assessment material for compliance.

  4. If a CVE is confirmed reachable under your configuration, upgrade to a component version that includes the fix or disable the related feature and rebuild the firmware. You are also welcome to contact us via esp-at/issues. We continuously monitor upstream security advisories, update dependencies when appropriate, and incorporate relevant fixes into future AT firmware releases.

Provide feedback about this document