0:38IKUZOさん、こんにちは。私の先程の投稿のやり直しです。ダンプ有難う御座います。chg_pmusr()はインラインアセンブラ展開されていましたね。それで、私が知りたいと思っているのは、以下のところです。・IKUZOさんの10:56の投稿main()ではChange_PSW_PM_to_UserMode()がインラインアセンブラ展開されていないと思われますが、main()でChange_PSW_PM_to_UserMode()を呼び出しているところのリストファイルはどうなっていますでしょうか?今の、私の推測は、以下の通りです。スタックの内容をコピーするのでは駄目で、IスタックポイントとUスタックポインタとの位置関係を合わせないと駄目だと思います。この時点では、Iスタックポインタは進んでいますが、Uスタックポインタは最初の位置のままですので、コピーした後にUスタックポインタを同じ深さになるように補正する必要があると思います。・IKUZOさんの10:24の投稿IスタックからUスタックへの切り替わりのせいで、mpu_init()の最後のRTS命令を実行したところで暴走するという仮説を立てている訳ですが、そうであれば、これも当然暴走しますね。・IKUZOさんの10:32の投稿mpu_init()の内容をmain()の中に挿入すると、暴走するRTS命令が無くなる訳ですので、暴走しなくなったのだと考えられます。(ですが、もしも仮に試しにmain()からリターンさせるようにしたら、main()の最後のRTS命令の実行で暴走するのでは無いかと考えられます。)・IKUZOさんの10:44の投稿メモリプロテクションのバックグランドの設定が全許可になっており、許可と禁止では許可が優先される仕様ですので、例外は発生しないですね。・IKUZOさんの10:56の投稿これはmain()ではChange_PSW_PM_to_UserMode()がインラインアセンブラ展開されていないと思われます。Change_PSW_PM_to_UserMode()が通常の関数としてコールされてしまっていて、Change_PSW_PM_to_UserMode()の最後のRTS命令の実行で暴走するのでは無いかと思われます。・IKUZOさんの13:03の投稿メモリプロテクションのバックグランドの設定が全禁止に変更されたことにより、また、RSPAGE0の設定が全禁止であることにより、(インラインアセンブラ展開されていない?)Change_PSW_PM_to_UserMode()ではRTE命令の次に実行される命令、もしくは、main()ではインラインアセンブラ展開されたchg_pmusr()のRTE命令の次に実行される命令、にてアクセス例外が発生するようになったのだと考えられます。NoMaY:NoMaYさんお世話になります「main()ではChange_PSW_PM_to_UserMode()がインラインアセンブラとして展開されていないと思われます。IKUZO:NoMaYさんお世話になります「IスタックポイントとUスタックポインタとの位置関係を合わせないと駄目だと思います。この時点では、Iスタックポインタは進んでいますが、Uスタックポインタは最初の位置のままですので、コピーした後にUスタックポインタを同じ深さになるように補正する必要があると思います。IKUZO:NoMaYさんお世話になります「メモリプロテクションのバックグランドの設定が全許可になっており」この意味がわかりませんマニュアルの記述には「領域がオーバラップして設定され、各領域のアクセスの制御情報が異なる場合は、許可が優先されます。「領域オーバラップの処理あるアドレスに対して領域がオーバラップして設定され、各領域のアクセス制御情報が異なる場合、許可が優先されます。バックグラウンド領域のアクセス制御情報はバックグラウンドアクセス制御レジスタ(MPBAC)で設定します。つのアクセス制御領域と異なり、メモリプロテクション機能が有効(MPEN.MPENビットが“1”)であれば有効となります。つのアクセス制御領域と異なり、メモリプロテクション機能が有効(MPEN.MPENビットが“1”)であれば有効となります。1:48IKUZOさん、こんにちは。Change_PSW_PM_to_UserMode(void){。V2.03ではエラーもワーニングも出ませんでした。Change_PSW_PM_to_UserModeの記述も無いのかも。それが無いのであれば、コンパイラはインラインアセンブラ展開出来ないと思います。実行>}これでも、もしも仮にmain()がリターンして来たらDo_Main_on_UserMode()からリターンするところで、暴走すると思います。(また、Do_Main_on_UserMode()がPowerON_Reset_PC()から呼ばれているとして、たとえmemcpy()を入れても、PowerON_Reset_PC()内でのIスタックポインタ/Uスタックポインタの初期値からは、Iスタックポインタは4バイト進んでいますがUスタックポインタは元のままですので、Uスタックポインタを4バイト進めてやらないと、Do_Main_on_UserMode()からリターンするところで、暴走すると思います。)>各領域設定:バックグラウンド領域設定で0:0であればということなんでしょうか?そうだと思います。バックグラウンド領域設定で1(許可)を設定したアクセス種別は、各領域設定で0(禁止)にしても無意味(禁止出来ない)だと思います。(私は、マニュアルの記述を、そのように解釈しました。=0x00000000>11111111111111111111111111111111111111←設定後すぐに例外発生しますバックグランド領域でも各領域でも、実行(およびリード/ライトも)を許可していないからです。*p=(char*)0;>p[0]=1;>でも例外発生せずですバックグランド領域で、(実行/リードと)ライトを許可しているからです。つのアクセス制御領域と異なり、>メモリプロテクション機能が有効(MPEN.MPENビットが“1”)であれば有効となります。」>これはどういう意味なんでしょうか?教えていただけませんでしょうか?各領域の設定にはVビットがありますが、バックグランド領域の設定にはVビットが無い、という意味だと思います。23:58このスレッドに後から来た人向けに、オンラインドキュメントの画面コピーを幾つか貼り付けました。Change_PSW_PM_to_UserMode(void);失礼かもしれませんが、アドレス0~16番地を禁止する設定というのがありましたら、教えていただけないですか、すぐにテストしてみますので、わたくしのあたまがどうにもついていけなくて。NoMaY:IKUZOさん、NoMaYさん該当アプリケーションノートの図3.1、表3.1にメモリ保護領域0~6(7は未使用)、それ以外の領域がバックグラウンド領域と記載されています。2:34IKUZOさん、こんにちは。Change_PSW_PM_to_UserMode(void);main()のあるソースでmpu.hがインクルードされているとします。main()でChange_PSW_PM_to_UserMode()を呼び出している箇所の前方向(ソースの先頭方向)に、以下の記述が無いのだと思います。R1RTENOPNOPNOPNOPNOPNOP}>アドレス0~16番地を禁止する設定というのがありましたら、教えていただけないですか、>すぐにテストしてみますので、わたくしのあたまがどうにもついていけなくて。いう時は、自分の経験上も、一晩寝て、明日の朝もう一度考えると分ることも多い、と思います。RXシミュレータで試してみますが、バックグランドは全禁止、4領域を使ってIROM/IRAM(先頭16番地除く)/IO/SDRAMの各メモリ空間について適切に設定、勘違いが無いかどうかチェック、あと、(今更だけど)本当にMPUのシミュレーションがRXシミュレータで出来るよねのチェック、とかで暫く時間が掛かりそうです。以下の記述が無いのだと思います。3:11IKUZOさん、circleさん、こんにちは。IKUZOさん、>RSPAGE1=0x00000000>REPAGE1=0xFFFFFFFF今度は、ここで全空間を全許可にしてますよ。circleさん、>サンプルコードではバックグランド領域はアクセス制御で"読み出し"、"書き込み"、"実行"を>全て禁止の設定としていますが、スーパバイザモードでアクセスしているため、>アクセス例外が発生しないのではないでしょうか?すみません。これはIKUZOさんのどのパターン(どの投稿)と関連する話になりますか?(ごめんなさい。本当にどれと関連しているのか分らなくて、、、)今のところ、私には、MPUのレジスタ設定が不適切である為そのように動作している、言い換えると、不適切に設定したMPUレジスタ通りに動作している、と見受けられるのです。IKUZOさんが試されたパターンの中にはアクセス違反の例外が発生しているというパターンがありますので、私は、以下のコードはmain()のchg_pmusr()以後にあるのだと解釈しています。推論の根拠については私の勘違いでした。(それはそれとして、このコードは0番地アクセスですので、CC-RXがどんなコードを生成しているか注意する必要がありそう、だとも思っています。