Computing stuff tied to the physical world

The esp-bridge circuit

by Thorsten von Eicken

Putting a printed circuit board together for the esp-bridge appears simple at first blush: after all, the esp-03 module contains all the circuitry and it must be just a matter of bringing out the appropriate I/O pins to the FTDI connector. As it turns out this is far from the truth. The first question to resolve is what connectors are needed for the esp-bridge’s desired functionality. On the one side we need an FTDI port to plug into the JeeNode, Arduino or similar device to be programmed. The FTDI port needs to have ground, power, serial RX and TX, a line to reset the attached microcontroller, and for attached ARM processors another line to put it into ISP (in-system-programming) mode. With respect to power, the JeeLabs tradition with USB-BUB’s has been to place the USB’s 5v on the FTDI connector.

Another connector is needed to power the esp-bridge. Since no USB is required, which is the whole purpose of the esp-bridge, another 2-pin power & ground connector will do. Speaking of power, the esp8266 operates at 3.3v and a look at the power consumption specs shows that WiFi transmission does require a good amount of juice:

Image

This table from the ESP8266EX Datasheet shows up to 170mA at 3.3V. Earlier datasheets showed a little over 200mA. The goal is to power the esp-bridge via the 2-pin power connector and then be able to power an attached microcontroller and perhaps some peripherals as well. To support this, the power supply shouldn’t be dimensioned too tight. A linear 500mA LDO regulator like the MCP1825S-3302 keeps the circuit simple: it needs two capacitors, one on the input and one on the output and it can supply enough power.

The next step is to hook the esp-03 module to the FTDI connector, this is best explained with the full schematic at hand:

Screen 2015 06 12 641

The FTDI connector is in the bottom left and its RX and TX go straight to the esp-03’s RX and TX. To reset the attached microcontroller the DTR pin is connected to GPIO (general purpose I/O) pin 12 with a pull-up so the microcontroller is not reset when the esp is not running (reset is active low). For the ISP function the CTS pin is similarly hooked up to GPIO 13.

When putting together this type of tinker board it’s always good to be able to see what is happening, for this purpose two LEDs are hooked up to another two GPIO pins. The SER LED is shown connected to GPIO 14 but it would be better on GPIO 2 as this would eliminate both R6 and R8 because the LEDs are sufficient as a pull-ups. These are details that were discovered after making a few prototype boards with the schematic shown above. (I prefer to show the actual schematic of the prototype boards that work with all the warts it may have over showing a modified “better” schematic that I can’t guarantee actually works.)

The final pieces of the circuit have to do with programming the esp8266 itself. While it will be possible to update the firmware via WiFi there has to be some mechanism to bootstrap the process. The esp-bridge circuit was designed before the WiFi update was implemented and so it’s a bit of a luxury version when it comes to flashing the esp8266.

To flash the esp8266 one has to hold GPIO 0 and GPIO 15 low, GPIO 2 high, pulse reset low, and then upload the firmware via the TX/RX pins. To make all this easy there are two push buttons with pull-ups: one for GPIO 0 and the other for reset. GPIO 15 is pulled low permanently, however, GPIO 0 must be high for a normal reset (i.e. to enter the normal firmware). All this can be summarized as follows:

Screen Shot 2015 06 22 at 10 55 43

There remains one problem: a close look at the schematic reveals that the reset button is not actually connected to a pin labeled “reset” on the esp-03 and a pin labeled “CH_PD” is connected to 3.3v. Unfortunately this is a long story. The CH_PD pin is a chip-enable: when low it powers down the entire esp8266 chip, when brought high it enables it. The esp-bridge is not designed to have an external circuit put the esp-03 into low-power mode, so it is pulled high permanently, which is another imperfection of this circuit.

The reset button goes to a pin mislabeled as GPIO 18, which should be labeled GPIO 16 or XPD_DCDC. The mystery behind that is that the esp8266 can put itself into a “deep sleep” mode where it consumes just 10μA. In this mode it is really mostly powered down except for some 256 bytes of memory and a small timer, which can activate the GPIO 16 output. The GPIO 16 output can be connected to the esp8266’s reset input and what happens is that during deep sleep the GPIO 16 output keeps reset low (active) and when the time expires it brings GPIO 16 high causing the esp8266 to start-up. Connecting GPIO 16 to reset is the only way the esp8266 can wake itself up from deep sleep as opposed to using an external circuit for this purpose.

A further obscure detail is that the esp-03 module does not connect GPIO 16 to reset by default, but instead provides a pair of tiny surface mount pads to solder a 0Ω resistor or a jumper to connect the two. So, coming back to the reset button, the way the circuit works is that it requires the tiny jumper to be closed to connect GPIO 16 to the chip’s reset input and then having the button on GPIO 16 forces the line low.

DSC 5137

If you are thinking that there must be a better way, you are correct. This is another imperfection of the esp-bridge circuit above. The better way is to ignore the GPIO 16 pin altogether and instead use CH_PD to reset the chip. This is what happens when the circuit designer (yours truly) thinks that a reset signal should be connected to the chip’s reset input! Two more details: the esp8266’s reset input has an internal pull-up resistor, otherwise none of this works (CH_PD does not, contrary to some of the documentation). Also, in order to use the self-wakeup from deep-sleep one has to connect the tiny jumper.

The circuit has one very final detail, which is that instead of using a two-pin power connector there are three pins with GPIO 2 connected to the third. The purpose of this is that GPIO 2 can be used as second UART TX for debug output. So it is possible to connect the “main” UART to an attached microcontroller and output debug statements on GPIO 2 at the same time. Once the firmware is running well this is no longer needed.

To wrap all this up, the esp-bridge circuit has the following parts:

  • a 500mA linear LDO regulator with two bypass capacitors
  • an FTDI connector hooked up to the esp8266 UART0 and the DTR/CTS lines hooked up to GPIO pins in order to be able to put the attached microcontroller into programming mode
  • two push buttons to make reprogramming the esp8266 itself via serial input easy, and pull-ups to ensure the attached microcontroller isn’t reset when the esp8266 is not active or resetting
  • two LEDs to show the WiFi connection status and to blink when serial data is sent/received
  • a power input connector with an additional debug UART1 output

In addition, the circuit could be simplified by:

  • removing some of the unnecessary pull-up resistors
  • switching the reset button to the CH_PD input (doesn’t require closing the tiny jumper on the esp-03)
  • hard-wiring GPIO 15 to ground
  • omitting GPIO 2 from the power connector

The finished esp-bridge prototype board looks as follows with two thru-hole resistors in place of the planned surface mount ones (oops!):

DSC 5127

Coming up: the software, in particular the serial bridge functionality.

[Back to article index]