■概要
今年に入って地味にアップデートを続けているBlackfin BlueBootですが、前回のVersion 0.4.0に引き続き、これまた地味にVersion 0.5.0へアップデートしました。きっかけとなったのは「KOZOS for Blackfin "BlacKOZOS"の設計方針」で始めたBlacKOZOSの作業です。この中で、コールドスタート時の動作確認用にターゲットにイメージを書き込むためにBlackfin BlueBootを使っていたのですが、稀に書き込みに失敗する事がわかりました。
■どんな失敗？
Blackfin BlueBootの場合、書き込み後に読み込みを実施して比較検証まで実施しているのですが、比較検証段階でターゲットから応答が無い(ような)状態に陥るというのが発生現象でした。現象発生時、表出現象には幾つか種類があるものの、書き込み直後の操作である事は共通した表出現象・・・。「なんだろうな？」と思って設計を見返したところ、手を抜いて気にしていた部分を見つけました。
というのも、Blackfin BlueBoot Version 0.4.0までは、ターゲット上でフラッシュロムへの書き込みがまさに終わったかどうかの確認は行なわず、ターゲット上に搭載されているフラッシュロムのデータシートに規定された書き込みにかかる最大時間をホスト側で待ってから、その次の動作に移行するという設計になっていました。
イメージ図にすること以下のようになります。
ホスト側の処理を台詞にすると、以下のように随分と乱暴な感じ。
これはいけません。
ざっくり言うと「データシートに書かれた最大時間は待ったんだから終わってんだろ？」という話ですが、これには幾つか問題があります。
- 常に最大時間待つので、必然的に書き込みが遅くなる。
- ソフトウェア上で待つという事は、必然的にバラツキを生む事になる。
- 待つ処理に対するバラツキは、実行環境によっても異なる上、それは予想し難い。
- その他。
一番目に挙げた「最大時間待つ」問題は、実はセクタ消去にも適用していたので、のっけから劇遅な状態を生んでいました。これは本来、フラッシュロムのステータスレジスタを参照して、次の処理に移行可能か確認するようにすれば高速ですし、そもそも次の処理が失敗する可能性もなくなります。
二番目に挙げた「待つ処理のバラツキ」問題は、根拠としているデータシート上の最大時間を保証できない可能性もあるという意味で大問題です。これも、先のフラッシュロムのステータスレジスタを参照してから次の処理に移行する事で解決できます。
問題の類としては、H8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」と同じとも言えなくないような・・・。
問題の類としては、H8/3069F writer for KOZOS - kz_h8write 「h8writeリベンジ解決編」と同じとも言えなくないような・・・。
■改良版
Blackfin BlueBoot Version 0.5.0では、プロトコルバージョンを2に変更した上で、フラッシュロムのステータス取得コマンドを追加しました。これにより、ターゲット側のブートローダも更新が必要になりましたが、これによって安定動作が得られるならば何の問題もありません。新しくflash_busyというインターフェースがflash.hに追加され、各ターゲットはこの定義に対する実装を要求されるようになります。
さて、改良版のホスト側の動作をイメージ図にするとこんな感じでしょうか？
ホスト側のコントローラは、ターゲットからフラッシュロムのお仕事が完了したのか、逐次必要に応じて問い合わせるようにしました。
これにより、
- 余計な待ち時間が不要となり、従来よりも動作が高速になりました。
- 書き込み処理の安定性が向上しました。
- より環境に依存せずに書き込みができるようになりました。
- その他。
という結果を得ました。
昔のどこかのバージョンで、フラッシュロムのライトサイクルとかその類の情報をターゲットから貰うようにしたのですが、これも次のバージョンでは整理したいと考えています。
■ダウンロード
Blackfin BlueBootは以下のサイトからダウンロードできます。
趣味でもお仕事でも御自由にお使い下さい。
完全無保証です。
動作させた結果、起きた如何なる問題も当方は責任を持ちません。
