Programming firmware: DTR/RTS issues
Posted: Tue Apr 14, 2015 4:28 pm
I'm experienced with microcontrollers, and had no trouble setting up an ESP-01 module to communicate through AT commands, connecting to wifi, etc. However, when I wanted to take it to the next level and update to the NodeMCU firmware, I ran into a block.
The firmware flashing software esptool.py uses DTR and RTS. To quote its documentation on github:
I verified that by looking at the python source code. However, the odd thing is, it is extremely rare for a USB-Serial adapter to actually have pins for both of those. "Standard" FTDI adapter cables have CTS and RTS, like these:
http://www.amazon.com/GearMo®-Header-Like-FTDI-TTL-232R-5V/dp/B004LC28G2
http://www.amazon.com/GearMo®-3-3v-Header-like-TTL-232R-3V3/dp/B004LBXO2A
http://www.adafruit.com/products/70
http://www.adafruit.com/products/284
https://www.pololu.com/product/1308
etc.
Ones that are designed to be maker-friendly for Arduino put out DTR instead of RTS, like these:
https://www.sparkfun.com/products/9716
https://www.sparkfun.com/products/11736
http://www.dfrobot.com/index.php?route= ... uct_id=147
A *few* of the items I linked are full-pins breakout boards that break out *all* the pins from the FTDI chip. However, this is definitely the exception rather than the norm. I have three usb-serial TTL adapters lying around already and none of them make it possible to access both DTR and RTS.
This seems odd to me because I've looked at every "getting started" guide I can find, and none of them say anything about using an odd, rare kind of adapter to run esptool.py. Including the esptool.py documentation... no mention at all.
Am I missing something? Is there some reason why it's obvious to everyone else, but not to me? Is that why none of the authors of any of the getting-started guides mention this?
It seems like the most obvious thing to do is simply to manually pull GPIO_0 low for programming, as described in many (but not all) of the guides I've seen, like this one:
http://randomnerdtutorials.com/flashing ... g-windows/
I guess that's good enough, but the esptool.py documentation really had me running up the DTR/RTS blind alley for a while.
Side note: this one simply has an error:
https://www.openhomeautomation.net/gett ... d-esp8266/
Connecting CTS won't do you any good, since that is an input not an output...
The firmware flashing software esptool.py uses DTR and RTS. To quote its documentation on github:
esptool uses the RTS and DTR modem status lines to automatically enter the bootloader. Connect RTS to CH_PD (which is used as active-low reset) and DTR to GPIO0.
I verified that by looking at the python source code. However, the odd thing is, it is extremely rare for a USB-Serial adapter to actually have pins for both of those. "Standard" FTDI adapter cables have CTS and RTS, like these:
http://www.amazon.com/GearMo®-Header-Like-FTDI-TTL-232R-5V/dp/B004LC28G2
http://www.amazon.com/GearMo®-3-3v-Header-like-TTL-232R-3V3/dp/B004LBXO2A
http://www.adafruit.com/products/70
http://www.adafruit.com/products/284
https://www.pololu.com/product/1308
etc.
Ones that are designed to be maker-friendly for Arduino put out DTR instead of RTS, like these:
https://www.sparkfun.com/products/9716
https://www.sparkfun.com/products/11736
http://www.dfrobot.com/index.php?route= ... uct_id=147
A *few* of the items I linked are full-pins breakout boards that break out *all* the pins from the FTDI chip. However, this is definitely the exception rather than the norm. I have three usb-serial TTL adapters lying around already and none of them make it possible to access both DTR and RTS.
This seems odd to me because I've looked at every "getting started" guide I can find, and none of them say anything about using an odd, rare kind of adapter to run esptool.py. Including the esptool.py documentation... no mention at all.
Am I missing something? Is there some reason why it's obvious to everyone else, but not to me? Is that why none of the authors of any of the getting-started guides mention this?
It seems like the most obvious thing to do is simply to manually pull GPIO_0 low for programming, as described in many (but not all) of the guides I've seen, like this one:
http://randomnerdtutorials.com/flashing ... g-windows/
I guess that's good enough, but the esptool.py documentation really had me running up the DTR/RTS blind alley for a while.
Side note: this one simply has an error:
https://www.openhomeautomation.net/gett ... d-esp8266/
Connecting CTS won't do you any good, since that is an input not an output...