初期セルフテストでROMのサム検査はされていますか?
顧客から初期セルフテストでROMのサム検査をするように要求がありますが、本当に必要ですか?
電源立ち上げから早く動作させたいシステムが多いのでROMもRAMもチェックしないです。とは言っても結構のんびりしたコードを書いてます。
SHよりも新しいRL78は機能安全が考慮されてます。チェックサムではありませんがフラッシュエリアのチェックのための機能が搭載されていることがホームページに記載されてます。欧州家電安全規格(IEC60730)は多少目を通したのですが、具体的な要求が記載されてません。検討委員会などのペーパを探れば一般的なフラッシュメモリに予想される不具合が分かると思います。ルネサス様は検討委員会メンバーのようですから、具体的に営業様経由で聞いてみるのが良いと思います。
kijo さん
情報ありがとうございます、なるほど「欧州家電安全規格(IEC60730)」なにか難しくなって来そうですね、対応しているのがRL78系だけなのでしょうか?今少し手間なのが製品としてROMに書き込む時いちいち内部でSUM計算させてそれをまたどこかに保存することをしています、なにかコンパイラで自動的に付与されるような方法はないものでしょうか?
チョコです。
RL78は、対応したハードウェアを内蔵していますが、セットとして対応できれば
いいだけのはずです。
コンパイラで対応するというよりは、ライブラリで対応になるのではないかと思います。
ライブラリを探してみてください。
欧州家電安全規格(IEC60730)あるいはそれを考慮したルネサスでは、ROMデータ化けチェックが安全に必要と考えているということです。なぜ、ROMデータ化けチェックが必要なのかはいろいろとインターネットを検索したのですが答えは得られてません。私も非常に興味があります。
また、チョコさんの「セットとして対応できればいいだけのはずです。」に同感ですが、RL78はSIL3とかアピールされてしまうと、SHでソフト(ライブラリ)のROMデータのチェックを入れても欧州安全規格を満足できないような「だけ」ではないと感じてしまいます。
チョコ さん
「セットとして対応」というのはハードウェア的に確認する機能が備わっていて、ライブラリでそれを呼び出して使用するということですか?
欧州家電安全規格(IEC60730)はまた勉強しておきます、難しそうですね、私は簡単に考えていまして、プログラムの先頭でSUMテストを行い内部のデータが実行するに値しない場合(データ化け)であればスリープモードに移行する等ですが、これを簡単に実現するため、コンパイル終了後のイベントとしてバイナリオブジェクトの最後に4バイトのSUMを追加するようなソフトを作成してそれを実行させるようにすれば良いと思いましたが、VC++等では統合開発環境に自由にコンパイル前、後にイベント追加できましたがHEWではありましたでしょうか?
IKUZOさん。
機能によっては、ハードが必要なものもあります。
ただ、ROMのチェックでは、ソフトだけでも可能です。専用のハードが
あれば、高速にできますが。
ありがとうございます、良くわかりました。
「バイナリオブジェクトの最後に4バイトのSUM」ですがよく考えたら、バイナリオブジェクト出力等あまり使用しませんね、あまり有効な方法ではないようです。SUMテストと言っても0番地から0x7FFFのようになっている場合は簡単に実現はできるのですが、0x200000~0x280000等これどうしたらいいの?0x200000~0x280000までですよということになるとSタイプから難しい?
「バイナリオブジェクトの最後に4バイトのSUM」ですが、実際にリンカをバイナリ出力に設定してみたら、キャッシュ領域などの高いアドレスは無視して実行ROM領域のみ出力してくれるようですので、外付けSUMも可能と思いました、ただコンパイル終了後のイベント追加の項目がHEW自体に無いようですので別の方法を探すのが必要かと思います。
私の間違いでした、Sフォーマットでは214KByteに対してバイナリでは524.293KBでした。
チョコさんの「セットとして」は、「欧州向け家電用マイコンとして」ですよね?Fault Tree Analysisを用いて「マイコンの故障」までで安全を確保するように設計するので私の関わる製品ではROMデータ(プログラム)のチェックは不要と考えてます。しかし、IKUZOさんのセットが欧州向けの家電なら「セットとして(安全に)対応できればいいだけのはずです。」になりません。どのようなシステム構成でも法令なので考えずにROMチェックを組み込まなければなりません。根拠が気になる場合はIEC60730を細かく確認するしかありません。
RL78のROMにあるCRC発生はCS+の機能かCALLWARKERのような別ツールなのかは不勉強で私には分かりません。チェック実行のマイコン内部用ライブラリはあるようです。IKUZOさんのように前回と比較するならマイコン内部用ライブラリだけでOKですが、最初が問題ですね。SH向けではありませんがRL78での手順やサンプルやライブラリは参考になるのではないでしょうか?
貴重なアドバイスをありがとうございます、
「RL78のROMにあるCRC発生」「マイコン内部用ライブラリ」ですか、調べてみたいと思います。
「欧州向け家電用マイコン」ではないのですが、そのようにして欲しいとの要望で、欧州ではIEC60730で厳しく規定されているということですね、反面ほとんどの日本製では焼きこんだ後はそのままですね、20年経過してマイコンが暴走しても関与しない、その前に壊れるようにしてありますから、ということなのでしょうか?
IEC60730ですが
クラスA:フェイルセーフ機能を要求しないもの(照明器具など)
クラスB:フェイルセーフ機能が要求されるもの(洗濯機など)
クラスC:高度なフェイルセーフ機能が要求されるもの(燃焼器具など)
3つのカテゴリから
1.マイコンやプログラムカウンタのスタック故障診断
2.割り込みの周期異常診断
3.マイコンのクロック周波数の異常診断
4.メモリの異常診断(ROM/RAM)
5.外部インタフェース(通信)の異常診断
とても厳しいのですね(当たり前といえば当然なのでしょうが)
この中のメモリの異常診断(ROM/RAM)というのが今回の客先の依頼になるのでしょうか
マイコン等の暴走で火災等を防止するというのが、眼目なのでしょう。
「RL78のROMにあるCRC発生」ですがこれはハードウェアマニュアルに銘記してありますか?RL78のハードウェアマニュアルのダウンロードが30分以上たっても終わりません。
CS+ RL78 コンパイラ CC-RL V1.01.00 リリースノートR20UT3367JJ0100 Rev 1.00 Page 12 of 142015.02.26④ CRC計算範囲にpadding拡張した領域を含めた場合、CRC計算結果が期待した結果とならない注意事項CRC計算範囲にpadding拡張した領域を含めた場合、CRC計算結果は期待する値とならないことがあります。【発生条件】以下の条件を全て満たす場合に発生します。(1)-paddingオプションを指定してパディングする。(2)-crcオプションを指定する。(3)CRC計算範囲にpadding拡張した領域が含まれる。【回避策】以下のいずれかの方法で回避できます。(1)-paddingオプションを指定しない。(2)CRC計算範囲にpadding拡張した領域を含めない。
うーんなんのことを言っているのか?
RL78/G13の安全機能は、「第22章 安全機能」にあります。
この中に高速CRC/汎用CRC機能があります。
この機能はハードとしてサポートされた機能ですが、言語処理
でもサポートしています。
CS+で、CC-RLのプロパティのヘキサ出力オプションにCRC演算
の項目があり、そこで設定します。
例えば、デバイスの高速CRCではフラッシュ・メモリCRC制御レジスタで
CRCを求める範囲を指定します。一番小さな領域では、16K-4バイトが
指定でき、このときの計算範囲は0x00000~0x03FFBとなります。
この場合のCRCの計算結果をあらかじめCC-RLで計算して0x03FFC~に
埋め込んでおきます。その上で、起動時に高速CRC演算を行い、得られた
結果と、あらかじめ埋め込んでおいた値と比較するような使い方です。
このようにCC-RLと連携することで、CRCのチェックが可能です。
> ....あらかじめ埋め込んでおいた値と比較するような使い方....
別CPUですが、数年前、客先の強い要望で、ECUにROMサムチェック、RAMチェックを織り込むはめに。
CRC計算のためにコンパイル。その後、そのCRC値の埋め込みのためにコンパイル。
と、二度手間をかけ、はじめてまともに実装。 おまけに、ゆったり起動。
この事を知らずに実装すると、CRCチェックエラー! ....以降、実行できず。
すばらしい!?(皮肉) いや、偽造防止に効果ありか? (笑)
尚、安全機能の目的、趣旨は、理解しています。皆さんの意見を否定するものではありません。
丁寧に説明してくださり、ありがとうございます
なるほど安全規格IEC60730,IEC61508に対応しているのですね
(1)フラッシュ・メモリCRC演算機能(高速CRC,汎用CRC)フラッシュ・メモリのデータ誤りを検出します。
(2)RAMパリティ・エラー検出機能
(3)RAMガード機能 CPUの暴走によるRAMデータの書き換えを防止します。
(4)SFRガード機能 CPUの暴走によるSFRの書き換えを防止します。
(5)不正メモリ・アクセス検出機能 不正なアクセスを検出します。
(6)周波数検出機能
手順としては
1.コンパイラのCRC演算のオプションを指定(CRC範囲格納アドレス等)
2.リンク時CRC計算結果がオブジェクトに埋め込まれる
3.実行時にレジスタにアクセスしてCRC演算結果を求める
4.CRC演算結果==埋め込まれたCRCであればOK
というような流れと理解できました、これは次世代対応ですね
RL78のみというのが寂しいですね
LEON さん
私はその事良くわかります、なんで「こんなに不便なの」と思わされます、RL78のようなものがすでにあるとは、知ってびっくりです、起動速度がSUM演算で遅くなることについては、SDRAMにロードしてから実行するとキャッシュメモリのためか驚くほど速く終わります、それで有効なのかどうか疑問なのですが。