Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

RAMチェックはどのように行えばよいでしょうか

例えば、RL78G14_80pin でCS+でソフトを作るとします。

ユーザーが使用できるRAM領域に対し、

1バイトづつ0x55を書いて0x55かどうか確認。

1バイトづつ0xAAを書いて0xAAかどうか確認。

を行いたいです。

自動的にスタートアップ関数で行われれているのでしょうか?

ユーザー側で記入する場合、どのように書けばよいか、ご存知の方教えてください。

よろしくお願いします。

  • In reply to IKUZO:

    ほや です。

    本当に壊れているならチェックした所でどうしようもないのですが、
    例えば高温などで一時的に動作がおかしくなり リセットに飛んだ状況ならば、温度が正常に戻れば復旧するはずで、
    それまで暴れずに待機させる手段の一環としては有効なのかもしれません。

  • In reply to ega258:

    eg258さん、スタートアップルーチン(cstart.asm)の中で「 CALL !!_hdwinit」となっているところの後に以下のプログラムを追加してください。

    ここで、「RAMTOP .EQU 0xFCF00」の「0xFCF00」はRAMの先頭アドレスの定義です。使用しているデバイスに応じて書き替えてください。

    エラーを検出すると,HALT命令でCPUは停止します。

    (この0xFCF00はRAMが12kバイトのときの値です。16kバイトなら0xFBF00、・・・48kバイトなら0xF3F00となります。)

    チェックするアドレスは汎用レジスタの直前までになっています。レジスタ・バンク0以外もチェックしたいなら「CMPW AX,#0xFEE0 」の

    「FEE0」を「FEF8」に変更して下さい。

    ;-----------------------------------------------------------------------
    ;
    ;   RAM test
    ;
    ;-----------------------------------------------------------------------
    RAMTOP .EQU 0xFCF00     ; define RAM top address
    RAMTEST:
     MOVW HL,#LOWW RAMTOP    ; set RAM top address

    RAMTEST_LOOP:
     MOV  [HL],#0x55     ; write data to RAM

     MOV  A,[HL]      ; read RAM data
     CMP  A,#0x55      ; check RAM data
     SKZ
     HALT        ; HALT if error

     MOV  [HL],#0xAA     ; write next data

     MOV  A,[HL]      ; read RAM data
     CMP  A,#0xAA      ; check it
     SKZ
     HALT        ; HALT if error
     INCW HL       ; increment pointer(HL)
     MOVW AX,HL
     CMPW AX,#0xFEE0     ; check RAM end address or not
     BC  $RAMTEST_LOOP    ; lopp until RAM end

  • In reply to EB68:

    起動時のRAMチェックの必要性は、安全設計で決定済みで、ここで持ち出すと発散します。安全とお客様の満足からフォルト(好ましくない特性)を決めて、その要因に起動時のRAM故障が有ったのでしょう。そのためのセーフ機能(対応)を組み込むのでしょう。

    弊社の経営陣は品質・安全・信頼性・要求の区別が付かないので、思い付きでつじつまの合わない要求がしばしばあります。これは経営陣の安心になりますが、組織の底辺は従うだけです。

    僕の気持ちです。ソースコードが欲しいのは私も感じてましたが、コンパイルできないとか、保証とか厄介なことになる予感を感じてました。また、努力が足らないようで残念と思います。

  • In reply to EB68:

    EB68さん
    丁寧な解説ありがとうございます。
    具体的なソースコードありがとうございます。

    開発環境でE1を使っています。
    E1/E20/E2エミュレータユーザーズマニュアル別冊を見ますと
     3.3.2項(38/50ぺ-ジ)にデバッグ用のスタック領域が書かれています。
    最大で12byte(網掛け部)を使用するようです。

    ご回答頂いたコードでは網掛け部も含みます。
    この領域も0x55,0xAAを書いても大丈夫なのでしょうか?
    初学者ではこの辺は良くわからないです。
    よろしくお願いします。
  • In reply to ega258:

    ega258さん、提示したプログラムをデバッグするかどうかで変わってきます。
    提示したプログラムは非常に単純なことしかやっていないので、あえてデバッグは無視しています。
    因みに、標準状態ではスタートアップが完了してmain関数のところで最初のブレークが掛かるので,デバッグ用のスタックとバッティングすることはありません。
    また、スタートアップの指定したところはスタックが使われていない(hdwinitを呼び出して、そこから戻った)ところです。そこでRAMの内容が書き換わってもスタートアップの動作には影響しません。
    RL78/G14の環境を持っていないので、コード生成でCSI00だけのプログラムをダミーで作ってシミュレータで確認しています。プログラムとしてRAMは殆ど使っていないので、シミュレータでRAMを確認したところ、RAMの先頭に少しコード生成されたCSI00の変数が確保されていて、FFE20の直前がスタックで使われていて値が変わっている以外はAAになっていました。
  • In reply to ega258:

    量産機器ではROM/RAMチェックはやっているのが当たり前かわかりませんが、やっているのは多いのではという印象です。自分が携わった装置のソフトや他社の機器を見るときの仕様書とかにROM/RAMチェックと書かれている事がありますので。
    今まで実施していない場合は、必要性に疑問を感じ、またスタート前にルーチンを入れるのに抵抗があると思いますが、最初から実装している場合は、不要と感じても外せなくなるし、ソフトもそのような記述方法でスタートするので、よほど起動時の時間を短縮とかしない限りはデメリットは少ないという事だと思います。
    電気系の会社ですと、割と新しくて機能的な考えですとそちらにシフトしやすい感じがしますが、特に車関係は安全性という言葉を強く意識して、以前ものを変えないや安全機能を入れるというイメージがあります。

    スタート時の最初にROM/RAMチェックをアセンブラ記述すれば、55やAAを書いても問題ないと思います。電源投入時ですので、短期間で電源OFF/ONですと以前のRAMの値が残っている可能性がありますが、通常はFFが書かれていると思いますので。
  • > ユーザーが使用できるRAM領域に対し、
    > 1バイトづつ0x55を書いて0x55かどうか確認。
    > 1バイトづつ0xAAを書いて0xAAかどうか確認。
    > を行いたいです。

    このテストの方法では CPU から RAM へのアドレス信号がどうにかなってたとしてもエラー検出されないと思いますがこの内容で十分でしょうか?

  • In reply to fujita nozomu:

    RAMに値を書き込んで、その値を読み込んで正しいかだけが分かればよいという事だと思います。
    問題ないソフトで問題ないタイミングなら当然当たり前の結果になって、本来の動作を開始させますが、
    もしこの時にRAMが正しい値が読み込めない場合はRAMエラーと判断し、起動させないや、
    安全な最小限な動作だけさせるという事かと思います。

    あとは、確率的にどの程度の効果は分からなくても、何となくの安心感とかではないでしょうか。
  • In reply to IKUZO:

    皆さん、ご意見ありがとうございます。
    私もIKUZOさんと同じように「CS+のコード生成で対応していただきたい」と望んでいます。
    個人的な意見かもしれませんが、ユーザーとしては、本来の製品の制御ソフトの部分にパワーを集中させたいです。
    既に、IEC60730/60335 セルフテスト・ライブラリが存在するので、
    これをコード生成で生成すれば良いのでは と思ってしまいます。
    ルネサスのスタッフの方がみられましたら検討していただきたいです。
  • In reply to ega258:

    IKUZOさんのコメントを確認しましたが、「必要性をあまり感じないので、そもそも不要。万人が必要な内容ならcs+の機能にあってもよさそう」なので、逆の意見かと思います。
    私が実際にみたり経験したROMチェックは、書き込んだ内容のチェックサム照合で、RAMチェックは55,AA書き込み読み出しチェックです。どなたかがリンク貼られていたPDFファイルのRAMチェックは、もっと細かい内容に見受けましたので、55,AAのチェックは、ある程度最低限に近い確認なのかもしれません。
    cs+のオプションでRAMチェックが付く事はありがたいと思いますが、必要な人によっては、やり方が違うとかが出てきますし、本質的に必要性の話が先に出てきますので、cs+の機能にするには難しいのではと思います。
  • In reply to ega258:

    わわいです
    内蔵RAMのRAMチェックは無意味です。
    というより、そもそもそのCPU自体のエラーチェックはどーすんだ?ということに目をつぶって、RAMの健全性だけを問題にしても全く意味はないでしょう。
    #狂ってるかもしれないCPUでRAMのチェックして、OKだからどーすんのというはなしに

    そして、それでもなお、RAMのエラーチェックを行うという場合、
    よっぽどの誤動作が許されない、ミッションクリチカルである場合、とおもわれますが、
    そういう重要なコードを、自動生成やら外部ライブラリで、「どこの誰が作ったのかもわからない」「なにをしてるかわからない」モノを持ってくるのは理屈に合わないでしょう。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page