ESP32の「自動書き込み機能には、2つのトランジスタをクロス接続した特別な回路が必要」と思っていませんか？

結論から言うと、ファームウェアの自動書き込みを行うだけなら、特別な回路は必要ありません。 DTR / RTS信号を直接 ESP32 に接続するだけで動作します。

しかし、なぜ市販の開発ボードには必ずあの回路が載っているのでしょうか？
本記事では、以下のステップで「自動書き込みの仕組み」と「あの回路の役割」を解き明かしていきます。

実証： DTR / RTSの直結だけで自動書き込みができることを確認
深掘り：なぜ直結だけで「ダウンロードモード」に遷移できるのか？
納得：それでも「あの特別な回路」が実装されている理由

「自動書き込みしたい」「自作回路を簡略化したい」という方の参考になれば幸いです。

はじめに

ESP起動ログ（ESP32-WROOM-32E）

SPIブート（通常ブート）

 ets Jul 29 2019 12:21:46

 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
 configsip: 0, SPIWP:0xee
 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
 mode:DIO, clock div:2
 load:0x3fff0030,len:4200
 load:0x40078000,len:15236
 load:0x40080400,len:3332
 entry 0x400805a8

ダウンロードブート

 ets Jul 29 2019 12:21:46

 rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
 waiting for download

ESP32 は UART でファームウェアを書き込むブートモードがあります。ダウンロードブートです。このモードに入るためには、ESP32 の IO0ピンをLOにしたまま ENピンを LO→HIにします。

ENピンをLO→HIにするタイミングで、
IO0ピンがLOであればダウンロードブート、HIであればSPIブートとなる。

^{IO0ピンはマイコン内部でプルアップされているため、何も配線しなければ HI 。}

ところで、

自動で書き込む機能と言えば、トランジスタ(MOSFET) 2個をクロス接続した次の回路図が有名です。実際、この回路図は、ESP32-DevKitC v4 で使われているものです。

ところが、自動書き込みするだけならば、この回路は 必要無い ということです。

1. 自動書き込みは`esptool`が制御

ESP32にファームウェアを書き込むときに使うコマンドであるesptoolの公式ページに、次の説明があります。

意訳すると、
USBシリアル変換チップの DTR および RTS信号を ESP32 の IO0 および ENピンに接続しておくと、esptool は、DTR および RTS信号を制御することで、ESP32 を自動的にリセットし、ファームウェアダウンロードモードで起動します。

先に説明したような 特別な回路が必要との記述はありません。
そこで、CH340C を使ったUSBシリアル変換モジュールを使って試してみます。
CH340C 以外でも、DTR / RTS信号が取り出せるシリアル変換ICであれば、何でもよいです。

2. DTR / RTSのみで自動書き込みはできるのか?

DTR / RTSのみ（特別な回路不要）で、自動書き込みできるのかを検証します。

・使用機材

・結果

本当にできました。

もちろん、ファームウェアの自動書き込みもできました。

DTR / RTSを接続せずに同じコマンドを実行すると、エラーになります。

ESP32がダウンロードモードになっていないからです。

DTR / RTSのみ（特別な回路不要）で、自動書き込みができることを確認できました。では、冒頭で紹介したあの回路は、何のためにあるのでしょうか??

3. あの回路は何のために必要か

DTR および RTS信号が ESP32 の IO0 および ENピンに接続されていることを前提に、esptoolコマンドは、DTR および RTS信号を制御することで、ESP32 をダウンロードモードで起動します。

これは、UARTプロトコルで規定した RTS / CTS、DTR / DSR によるハードウェアフロー制御とは直接関係ありません。あくまで、自動書き込みは esptoolコマンドの機能であって、他のシリアルモニタ系のコマンドではこのような制御はありません。

逆に、UARTプロトコルによるハードウェア制御に基づいて各信号が制御されるため、DTR / RTS が ESP32 の IO0 / EN に接続されていると、悪影響を受けます。DTR および RTS信号がLOのため、ESP32がリセットされたまま起動しないという現象です。

これを回避するために、あの回路の出番となります。右下に真理値表がありましたが、

DTR / RTS が LO / LO、HI / HI の場合に、この回路は、EN / IO0 を HI / HI に維持することで、影響を打ち消しているのです。

一般のUSBシリアルモジュールには、このような特別な回路は実装されていませんので、DTR / RTS を IO0 / EN に接続していると、自動書き込みは出来ますが、通常のシリアルモニタとして使用するときに不都合が起きてしまいます。

一方、ESP32ダウンローダーと言われるUSBシリアルモジュールや USBシリアル搭載のDEVボードには、この回路が実装されているため、自動書き込みが出来て、かつ、シリアルモニタとしても使用できる。
ということです。

esptoolの公式ページの次の説明（An additional circuitry）が、この回路の存在を示しています。

DTR / RTS を非アクティブにできるシリアルモニタプログラムにてこの問題を回避する方法を、@laddgeさんがこちらの記事で紹介されています。

また、74thさんの記事では、シリアルモニタで見ようとするとRTS(=EN)ピンとDTR(=IO0)ピンがLOWのままになってESP32が起動しないという問題が示されていたが、自分が使っているPlatformIOのpio device monitorというコマンドでは、RTS, DTRそれぞれを明示的にinactiveにすることができるため、その問題を回避できた。

確かに、screenコマンドでは ESP32がリセットされ動作しませんでした。

screen <シリアルポート> 115200

一方、pio device monitorのベースとなっている pyserial（miniterm）にオプション--dtr=0 --rts=0を指定すれば、問題なく動作します。

python -m serial.tools.miniterm --dtr=0 --rts=0 <シリアルポート> 115200

もちろん、pio device monitorにオプション--rts 0 --dtr 0を指定しても、問題なく動作します。

pio device monitor --port <シリアルポート> --baud 115200 --rts 0 --dtr 0

ただし、minitermもpio device monitorも、コマンド起動時にESP32をリセットしてしまう点に注意が必要です。もし、リセットされては困るタイミングで使用する場合は、やはり、RTS/DTRを外す必要があります。

なお、引用した＠laddgeさんの記事で紹介されている CH340X は、
CH340シリーズの中で、DTRとRTS信号が取れる最小ICで便利ですが、自分が調べた限りでは、このICは あの回路相当までは内蔵されていないようです。この点、もしかすると少し認識違いがあるのかもしれません。

4. なぜ、DTR / RTS信号のみでダウンロードブートにできるのか?

DTR / RTS は負論理（Active LOW signals) です。

active : 0v (GND) LO
inactive : 3v3 (VCC) HI

2項で試したときに、CH340C の信号をロジックアナライザで可視化しました。

esptoolコマンドがシリアルポートをオープンした直後の 0s では、RTS / DTR ともに HI (inactive) です。esptoolコマンドは、
まず ① RTS を LO (active) にしておよそ100ms維持します。
次に ② RTS を HI (inactive) にすると共に、DTR を LO (active) にしておよそ60ms維持します。その後 ③ DTR を HI (inactive) にします。

この信号をみると、EN LO, IO0 HI → EN HI, IO0 LO にするだけで、これでどうしてダウンロードモードに入るのか不思議ですね。

ここで重要なのが、ENピンとGNDの間のコンデンサ（キャパシタ）の存在です。

① RTS を LO にすると、このコンデンサは放電します
② RTS を HI にすると、このコンデンサの充電時間だけ、ENピンはわずかに遅延して HI になります。ENピンが HI になったタイミングでは、DTR(=IO0)は LO です

このコンデンサにより、『 EN をLO→HIになるタイミングに、IO0 がLOである状態が発生し』ダウンロードブートで起動することになります。

RC遅延回路として、ESP32のデータシートで推奨されているため、大抵のDEVモジュールは、（10KΩプルアップ抵抗と）0.1μFのコンデンサが実装されています。
今回使用したピッチ変換基板も同様です。

もし、このコンデンサがない場合、自動書き込みできるのかギリギリな気がします。
（100％失敗するのかどうなのかは、未検証のため不明）

なお、ロジックアナライザの 1030ms 付近で、再び RTS がLO(active)になるタイミングがあります。

これは、esptoolによる一連の処理が完了し、ESP32を再起動するためのリセット動作です。esptoolが最後に出力する ↓次のメッセージのタイミングです。
Hard resetting via RTS pin...

DTR / RTS を接続せず、手動でダウンロードモードにしてファームウェアを書き込んだ場合は、"Hard resetting via RTS pin..." が出力されていても、実際にはESP32はリセットされていません。よって、手動でリセットする必要があります。

疑問点

esptoolの公式ページの次の説明に疑問が残ります。

（すべてのEspressif製ボードは搭載している、）この回路を実装した場合、リセット回路を確実に動作させるには、ENピンとGNDの間に、追加のキャパシタ（1μF〜10μF）が必要。

しかし、「ESP32-DevKitC v4」の回路図から、追加のキャパシタの存在を確認できませんでした。

ENピンを追っても、RC遅延回路のC9(0.1μF)と、RESET(SW2)スイッチと並列に入っているC14(0.1μF)しか見当たりません。

DevKitC v4等の実機では0.1µF程度しか載っていないが、使用するPCやUSBケーブル、シリアルチップの相性によってはタイミングがシビアになり、自動書き込みに失敗する場合がある。そのため、公式ガイドやトラブルシューティングでは、より確実な動作のために1µF以上の追加が推奨されているようです。

▶︎なぜ「コンデンサ不足」で失敗するのか
　自動書き込みは、esptoolが DTR/RTS信号を操作して「ENをLO→HIにする瞬間に IO0 がLOである」という状態を作り出すことで機能します。しかし、以下の要因でこのタイミングが狂うことがあります。

信号の立ち上がりが速すぎる：コンデンサの容量が小さいと、EN信号の電圧が瞬時に立ち上がってしまいます。PC側の信号制御のわずかな遅れにより、ENがHIになった瞬間にまだIO0がLOになりきっていないと、通常モードで起動してしまう
PCや変換チップの個体差：USBシリアル変換チップや、PCのOS、ドライバによって、DTR/RTS信号が切り替わるタイミングに数ミリ秒単位のバラツキが生じる
ノイズの影響：書き込み開始時の突入電流などで電源電圧がわずかに変動し、リセット動作が不安定になることがある

おわりに

これまで、漠然と理解していましたが、検証も含めて一通りの説明はできたかと思います。自分も誤解していた部分がクリアになりました。

もし、誤りや説明不足等があればコメントで指摘していただけると幸いです。

2026.3.1 追記

DTR/RTS信号が取り出せる、おすすめのUSBシリアル変換モジュールをご紹介します。

秋月電子通商さんの
『CH9102F USBシリアル変換モジュールキット Type-C』

^{付属しているピンヘッダーを自分でハンダ付けするので『キット』となっています。}

おすすめポイント；
- DTR/RTS信号が用意されている
- 小型で USB Type-C である
- 安価（執筆時点で税込500円）

ピンヘッダーをハンダ付けする前に、VIOを3.3Vに変更する必要があります（下記赤印）。_{（デフォルトは5Vになっているので、ESP32やRP2040が壊れます。）}

3v3	RXD
DTR	TXD
RTS	GND
CTS	5V

以上