工場で基板に実装済みのROMを書き換えたいという話が出ている。
以前もあった話で、手順を教えてやってもらったところ、失敗したという経緯がある。
(失敗した基板は製品にできないので捨てられた)
この基板に実装済みのROMを書き換えるのは複数のデバッグ機能を組み合わせて使う都合、いろいろな問題がある。
- ROM書き換えに使うデバッグ用ツールの操作が煩雑
- ROM書き換えに約30分かかる(その代わり、同時に十数枚の書き換えができる)
- 同時に複数枚書き換えても、ベリファイは代表の1枚にしか行われない
1.は工場で失敗した最大の要因だ。開発者にとっても操作がめんどくさくて困っている。(使用頻度はさほど高くないが)
2.はROMデータの転送が遅いんだよね。アーキテクチャ的な問題もあるのだが、デバッグ用機能だったというのもある。
デバッグ機能なので転送速度は求めておらず、他の機能に干渉しないことを重視しているというのもある。
これでも改善した方で、当初は同時に1枚だけしかできず、1枚で約30分ということで本当に割に合わなかったが、
補助器具を用意することで、複数枚同時にROMデータの書き込みができるように改良され、フル実装すれば1枚あたり2分程度でそれなり。
ところが、その代償として、3.に書いたベリファイが不十分という問題が生じた。
次に工場でROM書き換えするときにはこの問題を解決しないとなぁということで、こういう対策をすることになった。
- デバッグ用ツールのサブセットとして、ROM書き換え専用ツールを作る
- データ転送シーケンスの見直し + ベリファイをターゲットボード上でやらせる
- 補助器具を改良して、ライトは一括、リードは個別でできるようにする
1.は工場で失敗したという話を聞いたときに作りかけていたので、これを完成させて使ってもらうことにした。
2.の対策は2つある。
1つはデータ転送に専念させることで高速化しようということ。少し速くなった気もするが、残念ながら、期待したほどの差は出なかった。
転送方式を抜本的に見直せば、高速化できそうなんだけど、そこまで無理しなくていいかなと。
もう1つが全体のおよそ半分を占めるベリファイを、書き込んだROMデータをPCに吸い上げてチェックする方式から、
ターゲットボード上でマイコンにチェックさせる方法に改めた。これだとチェック結果をリードするだけなので、圧倒的に速くなる。
この対策をすることで、3.のベリファイが1枚しかできないという問題も解決できると思っていた(時間だけの問題だと思っていた)のだが、
補助器具の設計にも問題があったので、リードは1枚ずつ個別にできるように改良した。
この改良の結果、ROM書き込みに要する時間は十数分となってほぼ半減した。フル実装すれば1枚あたり1分未満だ。
さらに全部にベリファイができるようになって、信頼性が高まるのかな?
ここでしくじっても、この後の製造検査でROMの検査もするので、大丈夫だと思うけどね。
とはいえ、普段、ROMライターで書き込む時は1つずつベリファイやってるんだから、1枚ずつベリファイするのがあるべき姿なのは言うまでもない。
ところで、マイコンが自身のROMを書き換える場合、書き換え用のプログラムをRAMに置く必要がある。
なので、こういう手順でROMの書き換えを行っている。
- メンテナンスモードに切り替える
- フラッシュドライバのプログラムデータを転送して、RAM上に展開する
- RAM上のフラッシュドライバにジャンプする
- ROMのプログラムデータを消す
- 書き換え用のプログラムデータを転送して、ROMに書き込む
- 書き込み完了後にROMデータのCRCを計算する (★今回追加)
- ソフトリセットを行い、ROMから通常通りに起動させる
1～3は書き換え前のマイコンにあるプログラムの機能で、4～7は2.で転送したフラッシュドライバの機能で実現されている。
けっこう複雑な仕組みなのだけど、少なくとも1～3の機能はあらかじめ作り込まれていないと通信経由での書き換えはできない。
仕組みを知っている人にとっては当たり前なのだが、工場の人はこういう背景を知らないので、
なにも書き込まれていないROMにこの方法で書き込めると思ったようだが、そういう風には作っていない。
基板実装後にまっさらのROMに書き込む方法もあるけど、工場で使うことは全く想定されていない。
工場で使うことを想定していないのは、大量生産を考えるとROMライターで書き込む方法にはかなわないという事情もある。
ただ、工場としては、ROMライターで書いて、プリント版に実装して、とやるのは管理上めんどくさいのも確からしい。
だから臨時で、基板実装後にROMを書き換えたいという要望が来たんだけど。
でも、そのために非定常作業が発生するのはどうなんですかね? 僕はそっちの方がめんどくさいと思うんだけど。
こちらは技術的に可能だし、ツールの改良はもともと着手していたので、じゃあ準備しますという話だけど。