ESP32のOTAアップデートをわざと破壊、それでも復旧できるかを検証
We broke an Over-The-Air update on the ESP32 on purpose
ESP32-C6でのOTAアップデートを、ソフトウェアリセット、リセットピン操作、電源断の3通りで意図的に中断。ESP-IDFのロールバック機構により、18回の試行すべてでデバイスは旧バージョンで起動し、自動的に再アップデートを完了した。復旧時間は中断方法によって異なり、電源断が最速で約100秒、ソフトウェアリセットは約166秒だった。中断タイミングを変えても復旧は成功し、ダウンロードの進行度に応じて復旧時間が延びることも確認された。
中断はブートローダーがブートポインタを切り替える前に起こるため、再起動したデバイスは依然として古いファームウェアで動作し、同じロールバック機構が新たな試行を導く準備ができている。
- leoedin
なんて中身のない記事だ。OTAアップデートがダウンロード中の電源断に耐えられるかテストするのは、あまりにも基本的なテストだ。こんなに長い記事にする必要なんてない。数行のプロンプトからAIが書いたんだろう？
彼らは面白いテストを何もしていない。ブラウンアウト、電圧リップル、リセット信号のタイミングを計ってアップデートプロセスにクリティカルな瞬間がないか調べる、壊れたアップデートファイル、高EMC環境などなど。そういうのが面白いんだ。
この記事は、こうしたテストを自動化できるテストプラットフォームの広告だと思う。でも変なことに、彼らのプラットフォームがどうやって自動化しているのか見せていないから、すごく基本的なエンジニアリングをやって自分たちで大満足しているようにしか見えない。
- rurban
2つのファームウェア用のフラッシュRAMと、どのパーティションがアクティブ／検証済みかを知っている適切なブートローダーがあればいいだけだ。それだけのこと。最大の問題は十分なフラッシュを確保することだ。
ブートローダーを書くのは些細なことだ。
- mikewarot
個人的な体験談：似たような問題に遭遇したのは1985年頃だった。収集したデータを独自のシリアルプロトコルでPCにアップロードして最終的にレポートする、ハンドヘルドのバーコードスキャナを持っていた。
顧客はアップロード中に「今これを切断したらどうなる？」と聞いてきた。それは私が考慮していなかったコーナーケースだった。それを堅牢にするのに数日しかかからなかった。
---
著者たちは、非常に遅い、あるいは断続的なインターネットの場合を考慮していないようだ。
私はダウンロードの破損を心配して、それをチェックするだろう。また、ウォッチドッグハードウェアが確実にオンになっていて、コードがそれを尊重していることも非常に注意深く確認するだろう。
OTAコードには2つではなく3つのバッファが必要だと思う。新しいアップデートに加えて、X秒間動作する最後のバージョンを保持する方法があるべきだ。Xはかなり大きく、おそらく丸一日くらい。