1. A short preliminary introduction

I'm deploying a small network of three MEGAs connected trough an RS-485 bus. Each MEGA is connected to up to 16 push-buttons (wall-mounted) and two relay-module (2 x 8-SSR; located close to the MEGA). The objective is to manage the lighting of the whole house (aka: "switching 'ON' the relay 'R1' when the push-button 'PB1' is pressed").

At the moment, everything runs fine: MEGAs are able to 'broadcast' events along the BUS and each node is able to properly react to both locally-generated events, as well as events coming from the BUS.

Above system is running from a couple of weeks and... I'm starting struggling about "updating" the code: having around 40 push-buttons and 35 relay distributed on the three nodes, chances are "high" that some "tuning" (aka: "trial-and-error") is required.

Things get even worse when... you start enjoying the powerfullness of the system (aka: "Hai! What about turning-OFF ALL the lights of the main-floor by long-clicking PB1?"). This, obviously, requires a "patch" to the code and a related "upload" the the MEGAs. And so on: LOTS of uploads :-(

Having some ESP8266-12E modules sitting around, I decided to investigate the possibility to use them, as a sort of "WiFi gateway": reaching them via WiFi; sending them the new code; asking them to kindly "upload" the code to its own MEGA that is phisically connected via USART.

As mentioned in lots of places (including a comment on this other question) I decided to test the ESP-Link firmware.

As I'm having problems interconneting the MEGA with the ESP, here I'm, asking this community :-)

2. Hardware involved

As for the Arduino side, I'm using a common MEGA (a Chinese one, BTW), so I don't get into details, here, 'cause there is nothing special.

As for the ESP8266, strictly speaking I'm NOT using a straight ESP8266-12E, but a Development Board. Actually, I'm using a Lolin NodeMCU v3, this, that you can see here below:

Lolin NodeMCU v3

My plan is to connect DIRECTLY the USART of the ESP to the USART of the MEGA. This raises some problems, described below.

3. GPIO voltage issues

One of the very first issues that I addressed relates to GPIO voltage. While it's crystal clear that:

  • GPIO PINs, on MEGA, are 5V based and, as such:

    • the TX on the MEGA side will send out a 5V current;
    • the RX on the MEGA side expect to receive a 5V current;
  • GPIO PINs, on ESP8266-12E, are 3.3V based and, as such:

    • the TX on the ESP side will send out a 3.3V current;
    • the RX on the ESP side expect to receive a 3.3V current;

I still am NOT able to understand if this is --in my case-- a real problem. I'm saying this, 'cause:

1 - Transmission from ESP to MEGA should NOT be an issue, as the HIGH/3.3V signal coming in into MEGA should still be recognized as HIGH, from the MEGA, as it's higher than 2.5V;

2 - Transmission from MEGA to ESP COULD be a problem, if PINs on the ESP are NOT 5V tolerant

As for point 2) I deeply searched all-around and found plenty of contradictory assertions. In the end, I would like to "trust" the Hackaday article: "Ask Hackaday: Is The ESP8266 5V Tolerant?" as, in several comments, reports various semi-official statements (like a message from Expressif CTO sent from a Facebook account or a message from an "internal" of Espressif) asserting that: "Yes! GPIO PINs on the ESP8266-12E are 5V tolerant"). So, again, I decided: "Ok! Let me go! Let's connect the two, straight, without a level-shifter". And yes: I know that with such a decision, I'm taking some risks and... can "burn" something, especially on the ESP side.

So, here's my:

Question 1: How much I'm "brave" in connecting straight-away the TX/RX of the ESP8266 to the RX/TX of the MEGA? Would you suggest it? And why?

4. Ground issues

While working on my RS-485 bus, I learnt that it's critically important to have a "common ground" among my MEGAs. That sounds understandable... as otherwise there is NOT a common reference to evaluate the same signal among different devices.

So, now that I've TWO equipment and I'm giving them POWER via two distinct sources (MEGA directly connected to my PC; ESP connected to another PC), I'm wondering if:

Question 2: Do I need to connect a GND PIN on the MEGA to a GND PIN on the ESP? Do the two boards, to properly operate, need a shared/common GND?

5. RESET line on the MEGA

In order to trigger the flashing of the new sketch on the Arduino side, the ESP need to RESET it. To do this, the ESP need to be connected to the RESET line of the MEGA. The RESET PIN is clearly shown on the MEGA so the connection is really easy.

Nevertheless, after some preliminary test... it looks to me that the ESP is UNABLE to reset the MEGA.

This lead to:

Question 3: Is, an ESP8266-12E OUTPUT PIN (operating at 3.3V), able to properly handle the RESET PIN of the Arduino?

I'm asking also 'cause based on the official documentation of the MEGA I read:

Reset PIN: Bring this line LOW to reset the microcontroller. 
Typically used to add a reset button to shields which block 
the one on the board.

6. Physical connections

In the official documentation of ESP-Link I read about potential problems generated (to Arduino) by the ESP as, right after a reboot of the ESP, it send out on TX some debug messages. Due to the USART connections, such characters transmitted by the ESP to the MEGA are received by the MEGA. It's not clear, to me, WHY this could be a problem. Anyway, the same documenation say: "...If you need to avoid this, you can configure esp-link to swap the uart pins..."

So, in the end, I connected the two devices following the official doc, with USART PINs swapped:

  • GPIO13: connect to TX of microcontroller
  • GPIO15: connect to RX of microcontroller and use a pull-down to ensure proper booting
  • GPIO12: connect to RESET of microcontroller
  • GPIO14: connect to ISP of LPC/ARM microcontroller (not used with Arduino/AVR)
  • GPIO0: either a 1k-10k pull-up resistor to 3.3v or a green "conn" LED via a 1k-2.2k resistor to 3.3V (indicates wifi status)
  • GPIO2: either a 1k-10k pull-up resistor to 3.3v or a yellow "ser" LED via a 1k-2.2k resistor to 3.3V (indicates serial activity)

As I don't need (currently) any LED feedback, I haven't used GPIO0 and GPIO2. Also, as I don't have an ARM, I haven't used GPIO14.

With help of this mapping I ended with following connection:

enter image description here

7. Results (...and problems)

To test what's going on, I've uploaded to Arduino a simple sketch that turn ON/OFF the internal LED every second and dump an increasing counter on the console. Here it is:

unsigned long counter;

void setup() {
  pinMode(13, OUTPUT);
  counter = 0;

void loop() {
  Serial.print("[");Serial.print(counter);Serial.print("] ");
  digitalWrite(13, HIGH);
  Serial.print("[");Serial.print(counter);Serial.print("] ");
  digitalWrite(13, LOW);

so, from the console output, I can see if Arduino is correctly operating and if it's restart.

On the ESP-Link side, I've configured the PIN as shown below:

enter image description here

With all the above in place, up to know, I've been experimenting the following:

  • If I connect ONLY the RESET line and the TX/MEGA to the D7/GPIO13/ESP, I can succesfully reset the Arduino from the ESP-Link web interface and I can see the "console" of the MEGA (I can be sure of succesfully reset, as the counter in the Arduino console, restart);
  • Above apply:

    • when the MEGA is powered via a full-USB connection from a PC;
    • when the MEGA is connected via a power-only USB cable from the PC;
    • when the MEGA is powered via a USB-power-bank, but in this case ONLY if thereis a shared-GND between ESP and MEGA
  • As soon as I connect the D8/GPIO15/ESP to the RX/MEGA, everything still work, but up to next reset. If I "reset" the Arduino via the ESP-Link web-interface, it reset but.... never boot (I'm sure, as the "blinking" never start).

So, the last question:

Question 4: What's wrong with above testbed? Why the D8/GPIO15/ESP disrupt the boot process on the MEGA? I've swapped the UART PINs exactly to avoid this... as far as I understood...

Sorry to be so long but... I think that details matter :-)

  • do you have a common ground between the boards? The ESP's GPIO 4+5 are the only pins that are low during reset+default on boot; you might want to use those two to avoid issues with "boot noise". You can use a relay/mosfet to reset the mega w/o shared electrical connections.
    – dandavis
    Apr 2, 2017 at 18:13
  • @dandavis: As for "common ground" the boot-problem (Arduino NOT booting properly after a "reset", when the ESP/TX is connected to Arduino/RX) persist even with shared ground. As for "relay/mosfet" to restart Arduino, please note that it's not needed: I've tested that ESP is surely able to reset Arduino. Problem is that after a reset, Arduino "hang" in the boot-process, and never launch the sketch. As soon as I plug-away Arduino/RX and reset it again (via ESP), boot process complete regularly - Currently I'm investigating problems related to the bootloader, even evalutating to "upgrade" it. Apr 3, 2017 at 18:58

1 Answer 1


I have successfully used ESP-link firmware with esp-01 and Arduino Pro Mini.

For the ESP-01 and Pro Mini, you can find out more on my blog post. I have connected GPIO 0 of ESP-01 to reset pin of Pro Mini and the Pro Mini can be reset using ESP-Link the web interface. I try to use the same voltage level for both micro-controllers and a single power source. For my example, the Pro Mini is driving the ESP-01 and of-course sharing the common ground.

To answer your questions.

  1. I try not do that as ESP has stated that all the GPIO pins are only 3.3v compatible.

  2. Yes, both controller must share a ground.

  3. My understanding is RESET is an output pin. If connected to ESP8266, there is a possibility that the ESP will be damaged.

  4. Not sure if your wiring is correct. You may reference my diagram on how the ESP and Arduino Pro Mini is wired up. For your case, I will recommend a level shifter to prevent damaged to your ESP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.