I am new to ESP32 and was burning a considerable amount of time in the recent days to enable AT commands via USB for the ESP-AT firmware for DevKitC (tested on SOLO and WROVER boards). The requried information is scattered across multiple places, guides and tutorials, so I figured it might be helpful for the one or the other to drop my collected findings here. They are current as of January 12th, 2019.
By default, UART0 (TXD0 is GPIO1 and RXD0 is GPIO3), connected to the USB bridge chip, acts as debug interface. Issuing AT commands is only possible via an additional UART interface (UART1, GPIO16 is RxD and GPIO17 is TxD) and thus requires additional hardware to fully use the DevBoard with a PC only. (Here is a good overview picture of the pinning: https://randomnerdtutorials.com/esp32-p ... nce-gpios/). So if you liek to explore the ESP-AT firmware's cpabilities on a DevKitC, you need additional hardware, OR, modify the firmware a bit so that the AT interface is also available via UART0.
The following Step-by-Step- guide describes how to proceed on Windows 10x64, from installing the development environment until connecting the DevKitC to a WPA2-enabled WiFi and sending off HTTP requests to a Cloud Platform.
1. Install the Virtual COM Port Driver for the Cypress 210x chip: CP210x_Universal_Windows_Driver. Then you should be able to connect to the DevBoard via a standard terminal using the virtual COM port assigned to your board by the system.
https://www.silabs.com/products/develop ... cp-drivers
2. Download and unzip the pre-built toolchain for ESP32, however, do NOT use the latest one, but this one to ensure compatibility with the ESP32-AT firmware referenced above:
https://dl.espressif.com/dl/esp32_win32 ... 181001.zip
I recommend to stick with the default location 'c:\msys2' -- some paths seem to be hardcoded, and while you can of course use any location to drop the toolchain, you might experience problems with certain tools (e.g. pip) if the path is not the default one.
3. Make sure the path to the idf is set and available all times. The easiest way is to drop an additional file 'export_idf_path.sh' into 'msys32/etc/profile.d' with the line 'export IDF_PATH="C:/msys32/home/username/esp/esp32-at/esp-idf"'
4. Start the toolchain by executing 'mingw32.exe'. Check the IDF_PATH variable with 'printenv IDF_PATH'
5. Clone the ESP-32-AT project (ESP32_AT_V1.1.3) into a directory named '~/esp' in your home directory (Attention: The resulting path of the esp-idf must match the one we just defined in step 3) using the command:
git clone --recursive https://github.com/espressif/esp32-at.git
(I got version b80d4469ee2ecea93ab8bb1df03766c0ef833dd9 from Jan 3rd, 2019)
And here comes the pitfall: Do NOT use the latest esp32-IDF! ESP32-AT comes with its own IDF version against it MUST be built; otherwise you will experience compiler and linker errors.
The corresponding version for the above mentioned ESP-AT FW version is ESP-IDF 7fa98593bc179ea50a1bc8244d5b94bac59c9a10. You get it automatically if you use the parameter --recursive.
If you checked out the latest version via
git clone --recursive https://github.com/espressif/esp-idf.git
you can revert back to the matching version by issuing
git checkout 7fa98593bc179ea50a1bc8244d5b94bac59c9a10
If you go this way, don't forget to also update all submodules
git submodule update --init --recursive
6. Unfortunately, the pre-built toolchain is not complete for the ESP32-AT project. We need further Python libraries which we install with 'pip install pyyaml xlrd'
7. Now we need to reconfigure the ESP32-AT firmware by using 'make menuconfig'. A graphical config console pops up and we select:
- 'Serial flasher config'->'Default serial port' to configure the serial port for downloading. On my Windows machine this is simply 'COM7'. Additionally you may increase the baud rate.
- 'Component config'->'AT'->'AT uart settings' to set the AT cmd UART to the same as the debug interface (both to UART0 so that debug output and AT interfacing runs via the USB bridge chip). The settings are as follows:
- uart port number: 0
- uart rx pin 3
- uart tx pin 1
- uart flow control 0 -- by defaul HW Flow Control via RTS/CTS is enabled. Disable it or the UART-USB bridge won't handle it
8. Now let's build the firmware by issuing 'make flash'. Make sure the board is connected to the specified COM port, because after a successful make (which may take 5-8 minute on a 7th generation i7 with 32 GB RAM), the board is being programmed.
9. After the successful download, start up your favorite terminal and open the corresponding COM port with the settings 115200,N,8,1, and no flow control.
10. Reset the board by pressing its "EN" Button and watch the debug messages coming in. After less than a second the board has fully booted up and outputs "ready" on the console. You will however find out quickly that issuing AT commands does not work. The reason is that we need further modifications to the firmware (and/or its configuration). The problem is also discussed in this issue: https://github.com/espressif/esp32-at/issues/153
11. Open the file 'at_uart_task.c' in the directory 'esp\esp32-at\main\interface\uart'. Scroll to line 252 and comment out the block 'if (data) {...}' until line 273. This block loads the default configuration and somehow clashes with the flow control settings configured in step 7. Save and close. (Notice, it is certainly cleaner to resolve the problem with the competing settings of make config and those stored as factory settings in the file 'factory_param_data.csv'.)
12. Again, 'make flash' (There will be two warnings that the variables for the flow control pins are now defined but not used -- ignore them for now, and fix that issue later), open your terminal, reset the board with the 'EN' button, wait for it to reboot and enter 'AT' followed by a CRLF. The response should now be 'OK', which means the AT-command interface is now fully available via UART0, and thus, via USB.
13. Now we are good to go and issue some more powerful AT commands, documented in the pdf at https://www.espressif.com/sites/default ... les_en.pdf In order to send a simple GET request to an IoT Cloud provider (in our case "thingspeak"), we just need the following AT-commands (CR=#013, LF=#010, '>' means I entered a command, other lines are responses and comments) to modify the factory settings (switch to station mode instead of soft AP mode) and establish a connection. Notice, the GET-Request needs to be terminated by two CRLF!
Code: Select all
New module with factory settings:
// switch to station mode
> AT+CWMODE=1#013#010
// connect to WiFi Network (WPA2)
> AT+CWJAP="mySSID","mypassword"#013#010
// connect to server using tcp
> AT+CIPSTART="TCP","thingspeak.com",80#013#010
// send http request
> AT+CIPSEND=89#013#010
AT+CIPSEND=89
OK
> GET https://api.thingspeak.com/update?api_key=RKLL5DFY7NVJI26Z&field1=79 HTTP/1.0#013#010#013#010
Recv 89 bytes
id:0,Len:89,dp:0x3ffb3f70
SEND OK
+IPD,637:HTTP/1.1 200 OK
Access-Control-Allow-Headers: origin, content-type, X-Requested-With
Access-Control-Allow-Methods: delete
GET, POST, PUT, OPTIONS, DELETE, PATCH
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 1800
Cache-Control: max-age=0, private, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 12 Jan 2019 19:41:56 GMT
ETag: "1679091c5a880faf6fb5e6087eb1b2dc"
Server: nginx/1.9.3 + Phusion Passenger 4.0.57
Status: 200 OK
X-Frame-Options: SAMEORIGIN
X-Powered-By: Phusion Passenger 4.0.57
X-Request-Id: dbdb0815-65f5-47d7-bb99-53d4245901d8
X-Runtime: 0.024321
Content-Length: 1
Connection: Close
6CLOSED
Good luck with your own experiments!