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:

flash mode:

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:

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)

echoecho -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: