初期セルフテストでＲＯＭのサム検査はされていますか？
顧客から初期セルフテストでＲＯＭのサム検査をするように要求がありますが、本当に必要ですか？
電源立ち上げから早く動作させたいシステムが多いのでROMもRAMもチェックしないです。とは言っても結構のんびりしたコードを書いてます。
SHよりも新しいRL78は機能安全が考慮されてます。チェックサムではありませんがフラッシュエリアのチェックのための機能が搭載されていることがホームページに記載されてます。欧州家電安全規格(IEC60730)は多少目を通したのですが、具体的な要求が記載されてません。検討委員会などのペーパを探れば一般的なフラッシュメモリに予想される不具合が分かると思います。ルネサス様は検討委員会メンバーのようですから、具体的に営業様経由で聞いてみるのが良いと思います。
kijo さん
情報ありがとうございます、なるほど「欧州家電安全規格(IEC60730)」なにか難しくなって来そうですね、対応しているのがRL78系だけなのでしょうか？今少し手間なのが製品としてROMに書き込む時いちいち内部でSUM計算させてそれをまたどこかに保存することをしています、なにかコンパイラで自動的に付与されるような方法はないものでしょうか？
チョコです。
RL78は、対応したハードウェアを内蔵していますが、セットとして対応できれば
いいだけのはずです。
コンパイラで対応するというよりは、ライブラリで対応になるのではないかと思います。
ライブラリを探してみてください。
欧州家電安全規格(IEC60730)あるいはそれを考慮したルネサスでは、ROMデータ化けチェックが安全に必要と考えているということです。なぜ、ROMデータ化けチェックが必要なのかはいろいろとインターネットを検索したのですが答えは得られてません。私も非常に興味があります。
また、チョコさんの「セットとして対応できればいいだけのはずです。」に同感ですが、RL78はSIL3とかアピールされてしまうと、SHでソフト（ライブラリ）のROMデータのチェックを入れても欧州安全規格を満足できないような「だけ」ではないと感じてしまいます。
チョコ さん
「セットとして対応」というのはハードウェア的に確認する機能が備わっていて、ライブラリでそれを呼び出して使用するということですか？
欧州家電安全規格(IEC60730)はまた勉強しておきます、難しそうですね、私は簡単に考えていまして、プログラムの先頭でSUMテストを行い内部のデータが実行するに値しない場合（データ化け）であればスリープモードに移行する等ですが、これを簡単に実現するため、コンパイル終了後のイベントとしてバイナリオブジェクトの最後に４バイトのSUMを追加するようなソフトを作成してそれを実行させるようにすれば良いと思いましたが、VC++等では統合開発環境に自由にコンパイル前、後にイベント追加できましたがHEWではありましたでしょうか？
IKUZOさん。
機能によっては、ハードが必要なものもあります。
ただ、ROMのチェックでは、ソフトだけでも可能です。専用のハードが
あれば、高速にできますが。
ありがとうございます、良くわかりました。
「バイナリオブジェクトの最後に４バイトのSUM」ですがよく考えたら、バイナリオブジェクト出力等あまり使用しませんね、あまり有効な方法ではないようです。SUMテストと言っても0番地から0x7FFFのようになっている場合は簡単に実現はできるのですが、0x200000～0x280000等これどうしたらいいの？0x200000～0x280000までですよということになるとSタイプから難しい？
「バイナリオブジェクトの最後に４バイトのSUM」ですが、実際にリンカをバイナリ出力に設定してみたら、キャッシュ領域などの高いアドレスは無視して実行ＲＯＭ領域のみ出力してくれるようですので、外付けＳＵＭも可能と思いました、ただコンパイル終了後のイベント追加の項目がＨＥＷ自体に無いようですので別の方法を探すのが必要かと思います。
私の間違いでした、Sフォーマットでは214KByteに対してバイナリでは524.293KBでした。
チョコさんの「セットとして」は、「欧州向け家電用マイコンとして」ですよね？Fault Tree Analysisを用いて「マイコンの故障」までで安全を確保するように設計するので私の関わる製品ではROMデータ(プログラム)のチェックは不要と考えてます。しかし、IKUZOさんのセットが欧州向けの家電なら「セットとして(安全に)対応できればいいだけのはずです。」になりません。どのようなシステム構成でも法令なので考えずにROMチェックを組み込まなければなりません。根拠が気になる場合はIEC60730を細かく確認するしかありません。
RL78のROMにあるCRC発生はCS+の機能かCALLWARKERのような別ツールなのかは不勉強で私には分かりません。チェック実行のマイコン内部用ライブラリはあるようです。IKUZOさんのように前回と比較するならマイコン内部用ライブラリだけでOKですが、最初が問題ですね。SH向けではありませんがRL78での手順やサンプルやライブラリは参考になるのではないでしょうか？
貴重なアドバイスをありがとうございます、
「RL78のROMにあるCRC発生」「マイコン内部用ライブラリ」ですか、調べてみたいと思います。
「欧州向け家電用マイコン」ではないのですが、そのようにして欲しいとの要望で、欧州ではIEC60730で厳しく規定されているということですね、反面ほとんどの日本製では焼きこんだ後はそのままですね、２０年経過してマイコンが暴走しても関与しない、その前に壊れるようにしてありますから、ということなのでしょうか？
IEC60730ですが
クラスA：フェイルセーフ機能を要求しないもの（照明器具など）
クラスB：フェイルセーフ機能が要求されるもの（洗濯機など）
クラスC：高度なフェイルセーフ機能が要求されるもの（燃焼器具など）
３つのカテゴリから
1.マイコンやプログラムカウンタのスタック故障診断
2.割り込みの周期異常診断
3.マイコンのクロック周波数の異常診断
4.メモリの異常診断(ROM/RAM)
5.外部インタフェース(通信)の異常診断
とても厳しいのですね(当たり前といえば当然なのでしょうが）
この中のメモリの異常診断(ROM/RAM)というのが今回の客先の依頼になるのでしょうか
マイコン等の暴走で火災等を防止するというのが、眼目なのでしょう。