ESP8266 Community Forum

- Wed Nov 01, 2017 2:08 pm #71449 I connected the Sam3x (the micro used in Arduino Due) to the esp8266 via sam3x's Serial2 and Serial on the esp8266. The wiring and basic things like putting the esp8266 into programming mode are all handled correctly.

I can program the esp8266 when using an ftdi chip, but when I try to program it through the sam3x's native usb port using SerialUSB it fails. The sam3x is running a basic program that transfers the SerialUSB TX/RX bytes to Serial2.

Here is that code:

Code: Select all      HardwareSerial *s = g_ctx.esp8266.getSerial();
      while (1) {
        if(SerialUSB.available()){
          s->write(SerialUSB.read());
        }
        if(s->available()){
          SerialUSB.write(s->read());
        }
      }


I found this great site the describes the packets used to program the esp8266 (https://github.com/espressif/esptool/wi ... l-Protocol). Then I attached a logic analyzer. I compared both the passing FTDI case and the failing Sam3x case. In both cases the initialization serial packets are sent to the esp8266 and the esp8266 responds. However, after that response from the esp8266 the FTDI case starts sending data, but the computer doing the programming never seems to get the acknowledgment in the sam3x case.

This made me think that something was wrong with the passing of the serial bytes from sam3x to the computer where the programming was being done. I don't have a logic analyzer that works with USB so instead I hooked up a serial terminal (putty) to the sam3x usb port. Then I sent a spoof initialization packet to the esp8266 that matched what was being sent from my computer for the esp8266 program initialization. In this case I got the exact data I was expecting from the esp8266 on my computer.

At this point I'm not sure why the esp8266 programming is failing when going through the sam3x. Do you experts have any ideas what might be going wrong?

Thanks in advance!

- Fri Nov 03, 2017 7:42 pm #71514 Blimey, not heard of this kind of configuration before. Nothing is impossible, but some things definitely take longer than others to get working.
I'm not sure I want to be seen as encouraging this, because it seems like a very arduous way to do this job (without knowing the details of 'why?'), but what about thinking laterally and since esptool is written in python, then use MicroPython on the Due and adapt esptool to run on it?
I don't want to take the blame for you going insane though!

- Fri Nov 03, 2017 8:07 pm #71515 the guy must have added esp8266 to his sam3x (Arduino DUE), and he doesn't want to remove the ESP8266 serial connection to sam3x for reprogramming, so used the sam3x as a serial bridge when reprogramming the esp8266.

did that before with an arduino micro and esp8266. and was not able to make it work also.
micro seems to reset itself when arduino ide sends the first packets to reprogram the esp8266.

another way to reprogram your esp8266, while connected to another controller, without removing serial connection is to use OTA on your esp8266

- Tue Nov 07, 2017 4:52 pm #71618 Sorry, for the delay in getting back to you. I wanted to say I got this working.

The reason I'm doing this way is I can avoid having an FTDI chip or cable to program the esp8266. This saves a significant amount on the BOM, and it also makes programming easier since you have a single port. First you upload the program to the sam3x. Then you put the sam3x in program esp8266 mode. Then you program the esp8266 through the same usb cable.

OTA updates are great, but I don't want to rely on them all the time since a bad firmware update will break OTA updates until you re-program the esp8266.

I had to dig through the esptool.py, but after a lot of debugging I figured out the problem. By default this python script resets the esp8266 over the ftdi cable. This reset obviously isn't going to work when going through emulated SerialUSB since the wires aren't there and actually trying to do that seems to break the serial connection (it seems like a windows usb->serial driver issue to me). This tool has a way to avoid that reset with the following command line:

esptool.py --port COM3 --before no_reset --after no_reset write_flash 0x0 Esp8266.ino.bin

The version of esptool used in the Arduino IDE doesn't seem to support this so you need to install the standalone version of esptool to make this work today.