デュアルバンク機能時の割り込み処理について

RX65N(2MB)で、FIT(r_flash_rx)を使用してコードフラッシュの書き換え機能を実装しています。

デュアルバンク機能を用いて、非動作バンクへ書き込む処理をしていますが、

フラッシュのアクセス時に、割り込みが発生するとプログラムが停止してしまいます。

当該箇所を割り込み禁止にすることで期待する処理は実装できるのですが、デュアルバンク機能では

割り込み処理をRAMに置く必要がないという認識でしたので、納得がいっておりません。

この認識は間違っているのでしょうか?

また、デュアルバンクなら動作バンクのフェッチが可能だと思うのですが、r_flash_rx の一部の関数を

RAMに配置する必要があるのは何故なのでしょうか?

Parents
  • YYさん、こんにちは。NoMaYです。

    > デバッガで処理を追うと、flash_write_faw_reg関数の処理中に割り込みが発生すると、プログラムが停止してしまう様です。
    > flash_write_faw_reg関数はデュアルバンク時にRAMに置かれるのですが、RAMに置かれた関数の処理時は割り込み禁止する必要があるという事でしょうか。

    R_FLASH_Control(FLASH_CMD_ACCESSWINDOW_SET)を実行する時にはRAM実行をする必要がある、ということを理解しましたので、RAM実行時の注意点を以下のスレッドから引用します。必ずしも割り込み禁止にする必要はありませんが、発生する可能性のある割り込み全ての割り込み関数が、フラッシュメモリからコード/データをフェッチ/リードすることが絶対に無い、ようにしておく必要があります。加えて、以下の引用元では書き忘れてしまったのですけれども、割り込みベクタテーブルもRAMに配置する(あるいは一時的にフラッシュメモリからRAMへコピーしたものを使用する)必要があります。

    思うに、ここが、ちょっとでも気を抜くとプログラムが動かなくなってしまう、そういう難しい点のように思うのです。

    r_flash_rx のサンプルについて
    community-ja.renesas.com/cafe_rene/forums-groups/mcu-mpu/rx/f/forum5/7726/r_flash_rx/40473#40473

    > フラッシュアクセスとCMT動作は何か関連があるのでしょうか?
    > フラッシュアクセス時はCMTを停止する必要がある? (とは思えないので)、

    関係あります。コードフラッシュ書き換え中は、書き換える領域以外の部分であっても、フラッシュメモリからコード/データを
    フェッチ/リードすることが出来ません。ですので、この場合の言わばセオリー的に気になりますことは、以下の点です。

    (1) 割り込み処理コードがRAM上で実行されるようになっていますか?(今回はCMT割り込みです)
    (2) この時、割り込み関数だけでなく、以下の点にも気を配る必要があります
    (2-1) 割り込み関数から呼ばれているサブルーチンも全てRAMに配置されていますか?
    (2-2) 加えて、もしコンパイラがランタイムライブラリを呼び出していたら、それもRAMに配置する必要があります
    (3) データに関しても気を配る必要があります
    (3-1) 割り込み処理内でconstデータをリードしようとしていませんか?
    (3-2) 加えて、コンパイラが生成したコードでswitch文のジャンプテーブルがフラッシュメモリに配置されている場合もあります

    このあたりはどうでしょうか?


  • YYさん、NoMaYさん

    シェルティです、こんにちは。

    解析がありがとうございます。ここまでの書き込みを確認させていただきました。

    ご推察の通りで、①オプション設定メモリを書き込む際はRAM実行である必要があるのと、②RAM実行の最中に割込みが発生した際、割込み先の関数もまたRAM実行である必要があります。②の方でCMT割込みが発生した際に動作不良になっているのだと思います。

    実際のコードではオプション設定メモリのうち、アクセスウィンドウやバンクスワップのビットを書き換える際は以下ループに到達してRAM上でステータスビットをポーリングして完了待ちしています。# 本当は他の処理と同じく割込みを使いたかったのですが、上記②の問題もありちょっと妥協してこの形にしてあります。

    https://github.com/renesas/rx-driver-package/blob/efa200d686d4f5083e21a8b9ef57f49950dd3c3c/source/r_flash_rx/r_flash_rx_vx.xx/r_flash_rx/src/flash_type_4/r_flash_type4.c#L221

    ということで、対処方法としては、②実行中に割込みが入らないように、R_FLASH_Control() 前後で割込み禁止・許可になるかと思います。

    あるいは難しいかもしれませんが、CMTの割込み関数もFRAM2セクションに配置してしまうことですね。

    当該関数(CMTの割込み関数)前に「R_BSP_ATTRIB_SECTION_CHANGE(P, FRAM2)」、関数後に「#define FLASH_SECTION_CHANGE_END R_BSP_ATTRIB_SECTION_CHANGE_END」を書くとRAMに関数を配置できます。RAMにコードをコピーする処理はR_FLASH_Open()時に実行されますので、CMTの処理がR_FLASH_Open()より前にあるとこれまた暴走します。CMT以外にもR_FLASH_Control() 実行中に割込みが発生する可能性がある場合同様に暴走するので割込み関数をそれぞれRAM実行する処置を施す必要があります。

    以上です

  • NoMaYさん、シェルティさん、回答ありがとうございました。

    この先、CMT以外もいくつか割込み処理が追加する予定ですので、
    R_FLASH_Control() 前後で割込み禁止・許可する方式で実装しようと思います。

Reply
  • NoMaYさん、シェルティさん、回答ありがとうございました。

    この先、CMT以外もいくつか割込み処理が追加する予定ですので、
    R_FLASH_Control() 前後で割込み禁止・許可する方式で実装しようと思います。

Children
No Data