初期セルフテストでＲＯＭのサム検査はされていますか？
顧客から初期セルフテストでＲＯＭのサム検査をするように要求がありますが、本当に必要ですか？
電源立ち上げから早く動作させたいシステムが多いのでROMもRAMもチェックしないです。とは言っても結構のんびりしたコードを書いてます。
SHよりも新しいRL78は機能安全が考慮されてます。チェックサムではありませんがフラッシュエリアのチェックのための機能が搭載されていることがホームページに記載されてます。欧州家電安全規格(IEC60730)は多少目を通したのですが、具体的な要求が記載されてません。検討委員会などのペーパを探れば一般的なフラッシュメモリに予想される不具合が分かると思います。ルネサス様は検討委員会メンバーのようですから、具体的に営業様経由で聞いてみるのが良いと思います。
kijo さん
情報ありがとうございます、なるほど「欧州家電安全規格(IEC60730)」なにか難しくなって来そうですね、対応しているのがRL78系だけなのでしょうか？今少し手間なのが製品としてROMに書き込む時いちいち内部でSUM計算させてそれをまたどこかに保存することをしています、なにかコンパイラで自動的に付与されるような方法はないものでしょうか？
チョコさんの「セットとして」は、「欧州向け家電用マイコンとして」ですよね？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)というのが今回の客先の依頼になるのでしょうか
マイコン等の暴走で火災等を防止するというのが、眼目なのでしょう。
「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にロードしてから実行するとキャッシュメモリのためか驚くほど速く終わります、それで有効なのかどうか疑問なのですが。
IKUZOさんの書き込みを補足すると、クラスB・Cに使われるマイコンに5項目の自己診断を推奨してるです。さらに、私の経験的に推奨は必須と解釈すべきです。
私の関わるほとんどの製品はEU向け家電でなく、かつ、安全に関してマイコン内部故障まで検討が不要、かつ、お客様からの要望も無いのでROMチェックが不要。
私たちには、国内法令を決める、あるいは、国内外の規格作成に参加するチャンスがあったわけで、IEC60730作成にルネサスさんは参加してます。したがって、ルネサスさんのホームページには多くの情報が以前からあります。チャンスを無駄にして決まってから皮肉や不満を言ってもダメです。法令は知らなかったでは済まされません。
そうですね、量産をしているメーカーさんは大変そうですね、うちがあまり量産とは疎遠なので、責任逃れではありませんが、商品を輸出しているメーカさん等はそういったところを見逃すと存亡の危機に立たされることもあるわけですね。
法律関係は一つ置いても、単なる信頼性を保証できるという点では、努力すべき項目ではあると思います。