概要
Web Serialを調べていたところChromebookでちょっと不安定な動作をしていたので、ESP32のリセット関連の動作を調査し直しました。
実験方法
ロジックアナライザをESP32やUSBシリアルに接続して、既存ツールをつかってリセット信号を確認していきます。
実験1 USBシリアル
USBシリアルのRESET(EN)信号とダウンロードモードの制御であるGPIO0の変化を確認してみたいと思います。
if mode != 'no_reset':
self._setDTR(False) # IO0=HIGH
self._setRTS(True) # EN=LOW, chip in reset
time.sleep(0.1)
if esp32r0_delay:
# Some chips are more likely to trigger the esp32r0
# watchdog reset silicon bug if they're held with EN=LOW
# for a longer period
time.sleep(1.2)
self._setDTR(True) # IO0=LOW
self._setRTS(False) # EN=HIGH, chip out of reset
if esp32r0_delay:
# Sleep longer after reset.
# This workaround only works on revision 0 ESP32 chips,
# it exploits a silicon bug spurious watchdog reset.
time.sleep(0.4) # allow watchdog reset to occur
time.sleep(0.05)
self._setDTR(False) # IO0=HIGH, done
上記の処理をロジックアナライザで取得してみます。
esptool flash_id
上記のコマンドで未接続のUSBシリアルの端子を観察します。
上記のような波形が観測されました。短い波形と、長い波形がセットになっていて、右端にあるのが次のループだと思われます。
上記が約0.1秒なのでtime.sleep(0.1)のところですね。
ソースコードのタイミングからみると上記のような波形になる気がするんですが、Resetがかなりずれていますね。本当はリセットの立ち上がりでGPIO0をLOWにしているのかな?
ちなみにTXDの信号も確認したところ、ダウンロードモードへリセットしたあとにSyncパケットを定期的に投げて、反応がなかったら再度リセットしています。そのときにはesp32r0_delayオプションをtrueにしていますので長い時間リセットまで待機する動きとなるようでした。
自作ツールだとリセットは一度だけだったので、この動きをしないと安定運用できなそうですね。
実験2 ESP32-DevKitC
あれ、こちらだとある程度予想した波形になっていますね。
リセット信号をアナログで観察してみました。最初にLOWからHIGHになってからLOWになっていますね。その後HIGHに戻ったときにコンデンサが接続されているのでHIGHになる信号がなまっています。ここの遅延時間までにGPIO0がLOWに落ちていればダウンロードモードへのリセットが成功するはずです。
実験3 再びUSBシリアル
波形が気になったのでものすごいコンデンサがResetのEN端子に入っているかと思ったらそうでもないですね。。。これResetが遅延しすぎていて、GPIO0がHIGHになってからリセットかかっているようにもみえるんですよね。。。
まとめ
M5StackのUSBシリアル端子って実はReset信号を遅延する処理が内部で実装されている気がします。。。
そもそも普通のUSBシリアル端子ってDTRとRTS信号が外に出ているの少ないですよね。M5StackのUSBシリアルはESP32開発に特化しているので使いやすいのかもしれませんが遅延が大きすぎるようにも見えます、、、
もうちょっとFT232とかのUSBシリアルで検証したほうが良さそうですが、現状問題になっているリセットが不安定問題が解決しそうなのでここまでとします。
コメント