Due to high demand expect some shipping delays at this time, orders may not ship for 3-4 business days. On MLK Day no orders will be shipped.
0

Huzzah Feather 8266 autoreset issue
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Huzzah Feather 8266 autoreset issue

by marfis on Sun May 15, 2016 4:45 pm

Hi Adafruit team,

I have a bunch of Huzzah Feahter 8266 boards here which I use to program micro python using the esptool.py, directly over USB.

So far so good..

I wanted flash to the board from a docker container. Since the serial port is not available, I thought I could route it over TCP, using RFC2217 (see also pyserial documentation). Basically the data is sent over a TCP socket to a server which then routes it to the serial port. It didn't work, the board was not entering bootloader mode.

Looking at the schematic I saw the "autoreset" thing and wondered what the benefit of this extra circuitry is since I believe it can introduce a raise condition, as explained below.

On the esptool.py there is this function to enter the bootloader:
Code: Select all | TOGGLE FULL SIZE
            # issue reset-to-bootloader:
            # RTS = either CH_PD or nRESET (both active low = chip in reset)
            # DTR = GPIO0 (active low = boot to flasher)
            self._port.setDTR(False)
            self._port.setRTS(True)
            time.sleep(0.05)
            self._port.setDTR(True)
            self._port.setRTS(False)
            time.sleep(0.05)
            self._port.setDTR(False)


The first toggling sequence sets the board in reset (RESET=low), with GPIO0 = pull up. That's fine.
However, the second sequence
Code: Select all | TOGGLE FULL SIZE
            self._port.setDTR(True)
            self._port.setRTS(False)
            time.sleep(0.05)
            self._port.setDTR(False)

introduces a problem on the Huzzah feather: setDTR releases the Reset pin with GPIO0=pull up. If there is now a slight delay between the next setRTS instructions, the board has already booted to normal mode, so the next instructions does nothing.

On directly connected serial ports the time delay is small and poses no problem. But over a TCP socket, the delay was just too much.

You can reproduce the problem on if you add a time.sleep(0.1) between the 2 instructions (and connect the board as usual over USB). It will not enter the bootloader.

So I wondered: Why is this circuitry there in the first place? Why not just hooking DTR/RTS it up directly to Reset and GPIO0?

Thanks for feedback,
Martin
Last edited by marfis on Mon May 16, 2016 2:33 pm, edited 2 times in total.

marfis
 
Posts: 6
Joined: Tue Jan 27, 2015 3:32 pm

Re: Huzzah Feather 8266 autoreset issue

by marfis on Sun May 15, 2016 5:20 pm

Ok to follow up on this.

I desoldered Q1 + Q2 and made a wire from collector to emitter (both Q1/Q2). That directly routes the control signals to Reset/GPIO0.

Now it is working ok. No more timing issues - I could even wait for 1sec between the 2 instructions.

marfis
 
Posts: 6
Joined: Tue Jan 27, 2015 3:32 pm

Re: Huzzah Feather 8266 autoreset issue

by marfis on Sun May 15, 2016 5:51 pm

Console will be available with this modification only if you provide the --rts=0 and --dtr=0 option to your miniterm call.
e.g.
Code: Select all | TOGGLE FULL SIZE
python -m serial.tools.miniterm --rts=0 --dtr=0 /dev/cu.SLAB_USBtoUART 115200

marfis
 
Posts: 6
Joined: Tue Jan 27, 2015 3:32 pm

Re: Huzzah Feather 8266 autoreset issue

by marfis on Tue May 24, 2016 4:04 pm

ping
any comments on this autoreset thing? Why is it there?

marfis
 
Posts: 6
Joined: Tue Jan 27, 2015 3:32 pm

Re: Huzzah Feather 8266 autoreset issue

by marfis on Tue May 31, 2016 12:58 am

ping

marfis
 
Posts: 6
Joined: Tue Jan 27, 2015 3:32 pm

Re: Huzzah Feather 8266 autoreset issue

by adafruit_support_mike on Tue May 31, 2016 2:33 am

The circuit is an XOR, and it exists for compatibility between the ESP8266 and the Arduino IDE Serial Monitor.

If you hold GPIO0 low while RST is low, it puts the ESP8266 in bootloader mode instead of just restarting the firmware. When communicating through a Serial connection, the ESP8266 uses GPIO0 as the RTS signal for flow control.

The Arduino IDE uses both the DTR and RTS signals to reset a chip and launch the bootloader, but its standard signals would put the ESP8266 into flash programming mode instead of just resetting the serial interface.

The XOR allows the Serial connection to use RTS for flow control while the regular firmware is running, but prevents GPIO0 from being held low during reset.

adafruit_support_mike
 
Posts: 63937
Joined: Thu Feb 11, 2010 2:51 pm

Re: Huzzah Feather 8266 autoreset issue

by marfis on Sun Jun 05, 2016 7:19 am

Thank you for the clarification.

So to summarize, it seems to be the arduino serial monitor that creates the need for this hw... I guess the arduino serial monitor cannot be configured to individually control rts and dtr line?

Anyway.. for me the matter is solved. Thanks again for the feedbakc.

Martin.

marfis
 
Posts: 6
Joined: Tue Jan 27, 2015 3:32 pm

Re: Huzzah Feather 8266 autoreset issue

by adafruit_support_mike on Mon Jun 06, 2016 4:01 am

You can configure the signals, but it involves digging through the board support files to find the connection options and editing them. People want the board to just work, hence the XOR.

adafruit_support_mike
 
Posts: 63937
Joined: Thu Feb 11, 2010 2:51 pm

Please be positive and constructive with your questions and comments.