Pitfalls While Setting Up esp8266 ESP-03
by kacang bawang
Here are some obvious and not-so-obvious pitfalls you may encounter while trying to communicate with an ESP-03 over UART. We will be using a USB-Serial device to connect directly to the ESP.
1. Wiring
run mode:
-CH_PD HI
-GPIO15 LO
flash mode:
-CH_PD HI
-GPIO15 LO
-GPIO0 LO
User program won’t start automatically in flash mode
but may be triggered to run via the esp-upload-tool (esptool.py)
.
2. Flashing
when flashing, new firmware will consist of two pieces:
0x00000.bin
(or eagle.app.v6.flash.bin
) <– this is the “user” code (eg. AT command handling)
0x40000.bin
(or eagle.app.v6.irom0text.bin
) <– this is the SDK code (ie, binary-only libs provided by Espressif), this makes up the bulk of the data
If you flash only one of the two, fully expect the result to not be able to run. You should still be able to see bootloader output though (at 75k baud – use a logic analyzer). I wonder how one would go about modifying the bootloader…
One notable phenotype of such a “bad flash” where I only wrote the 0x00000.bin
was this: I was able to connect to the chip, at the specified baudrate, however, instead of meaningful data, the chip just kept sending a never-ending stream of garbage data. This was true at both 9600 and 115200 baud.
Oh, another thing – if you specify an invalid address for write_flash, you will get
an error like this:
1 2 3 4 5 6 7 8 9 10 |
$sudo esptool.py write_flash 0x400000 firmware/0x40000.bin #one extra zero, oops Connecting... Erasing flash... Traceback (most recent call last): File "/home/projects/esp8266/esp_upload_tool/esptool.py", line 456, in esp.flash_begin(blocks*esp.ESP_FLASH_BLOCK, address) File "/home/projects/esp8266/esp_upload_tool/esptool.py", line 183, in flash_begin raise Exception('Failed to enter Flash download mode') Exception: Failed to enter Flash download mode |
3. UART
If the chip is flashed with AT firmware and working, it will first output bootloader stuff (at 75k), then will switch to either 9600 or 115200 baud. The stock ones from factory do 9600, flashing the latest AT firmware (0.20)
will default to 115200 baud. Both of the bootloader and rom output should be readable with the logic analyzer at this point. If you don’t see non-bootloader output, your firmware is corrupted/incomplete/just bad.
Use a terminal program to connect to the UART console. You MUST end lines with cr lf
aka \r\n
. Not all terminal emulators are helpful in this regard. So, if you’re here, maybe you tried to communicate with the esp8266
, and can see “AT” being typed in, but no output is produced. Here are some suggestions:
minicom
– is not able to send cr lf
line endings automatically no matter the settings. Here’s what happens if you only send one of the two:
\r
– nothing happens
\n
– command read, but ERROR returned
\r\n
– command read and accepted
Solution: manually – do this: AT+whatever[Ctrl-M][Ctrl-J]
cutecom
– able to do CR/LF
(setting at bottom of screen)
screen
– didn’t try
putty
– I believe it can do CR/LF
on its own, but haven’t tried.
Edit: seems you have to use Ctrl-M/Ctrl-J (thanks rawe)
echo
– echo -ne "\r\n" > /dev/ttyUSB0
if you get “permission denied” with the above, even when using sudo (??), add yourself to the ‘dialout’ group like this:
1 2 3 |
$ sudo adduser "name of account" dialout $ su - "name of account" #new group only works in new sessions $ minicom -D /dev/ttyUSB0 |
If your firmware is bad, and you only get boot loader output, is there a way to reflash the module?
absolutely. If you get bootloader output, that means all is not lost. Use a USB-Serial device or use your RaspberryPi or BeagleBone to connect via a serial port, set up pins for flashing and run pytool.py
just tried putty 0.64 beta on winxp. Ctrl-M (CR), Ctrl-J (LF) works, but Return/Enter does not (implicit LF on CR or implicit CR on LF settings do not fix this)
oh, hey – thanks for the feedback. I’ll add it to the article