こんにちは。
タイトルの通り、「FITを利用したSCIのプログラム」について、皆様のアドバイスを頂けると幸いです。
【発生している問題】
テラタームを用いて、PCよりシリアル通信を行うプログラムの試験中です。（エコーバック）
PCより一文字受信すると、CPUが固まります。
一度固まると（デバッグモードで）再開を押しても固まったままです。
一度終了（デバッガと切断）し、再度デバッグを開始するとCPUは動きます。
【不具合詳細】
CPUが固まった時は、添付画像の用にe2studio上に
"0x446の_$s_bsp_swint_nested_int_status()"に対して使用できるリソースがありません。
と表示されます。
その時の逆アセンブルを表示すると、
0000446:dbt
という命令が表示されています。
何を以て「CPUが固まった」と判断してるかと言うと、RTOSの周期ハンドラでLEDを点滅させています。
これが消えたままになったり、ついたままになっているからです。
（SCIを受信しなけれなば点滅を繰り返しています。）
【環境】
e2studioにて、FITを用いてのプログラム作成中です。
CPUはRX65Nです。
また、μITORN仕様のOS「NORTi」を使用しています。
（NORTiのメーカーの）ミスポ様より、RX231用でのFITを用いたサンプルは頂いていますので参考にしています。
【考察】
FITのマニュアル等も確認し、FITのヘッダファイルでのチャンネル指定や
R_SCI_Open関数コール前後のピンの設定の記述等も確認したつもりです。
が、なぜかr_sci_rx65n.c内の割込み関数の引数に対して、エディター上でエラーが出ます。
しかし、ビルドは通ります。ここが怪しいかとは思うのですが、思いつく限りの確認はしたのですが
症状は改善されません。
具体的に言うと、（SCIの割込み関数４つ全てなのですが1つの例として）
void sci2_eri2_isr(void *cb_args){ ient_int(); eri_handler(&ch2_ctrl); iret_int();}
※ient_int()とiret_int()というのはRTOSとFITを接続するための関数ですので、今回は関係ないかとは思います。
のch2_ctrlに対して「シンボルが解決できません」と赤波下線がエディタ上で表示されています。
しかし、デバッグ状態にしてカーソルを持ってい行きF2を押すと、値は入っています。（添付画像）
アドバイスを頂けると幸いです。
よろしくお願いいたします。
明日は所用で一日おりませんので、明日以降にも再度プログラムを見直しますが、アドバイスを頂けると幸いです。
しんちょろす さん、こんにちは。NoMaYです。たぶん、しんちょろすさんの頭の中では、ツールがバグっている筈が無い、という観念があるかと思うのですが、そういう人とe2 studioは相性が悪い、ということの実際の事例になっているような気がするのです。どうしても私は思ってしまうのですが、そういう人はCS+を使った方が良い、と思うのです。当然、初学者さんは皆そういう観念を持っているのでは？という話になるかと思うのですが、ですので、私は初学者さんはCS+を使った方が良い、と思っているのです。(もちろんCS+にバグが全く無いとは言いませんけれど。)それはそれとして、現象に関してですが、まずタイトルが良くないですよね、、、送信というのはPC視点ですよね、、、文面を追っていってすぐ気付いたのですが、マイコン側での受信時のトラブルの話、でしたね、、、そして、これはまず第一に、マイコン側での受信割り込みで何か起きているのでは？というのが、たぶん、多くの人の最初の考えだと思います。きっと、受信割り込みは発生しているに違いない、と。(ですので、その場合、もうピン設定を確認するなどしても、無意味(といっていいぐらい)かなぁ、とも思うのですけど。）次にすることは、FITの受信割り込み処理は多くの人が使っていますので単純素朴なバグは無いと思いますので、受信割り込みコールバックのソースを再確認することですね。そうして、問題が見付からなければ、その次はデバッグですね。まずは、以下の2点の確認かと思います。(もし、コールバック内でNORTiのシステムコールを行っていたら、一時的にコメントアウトしてみるのも手かと思います。)(1) ちゃんとRETI命令まで辿り着いているか(FITのソースを追いかけて割り込み処理の最後にブレークポイントを設定して、ブレークポイントで止まるか)どうかですね。(もちろん、割り込み処理の最初にもブレークポイントを設定して、ブレークポイントで止まるかどうかは、念のため、確認しておきます。)(2) ちゃんとRETI命令まで辿り着いたら、RETI命令を命令単位ステップ実行して、ちゃんとメイン処理に(つまり割り込み発生箇所(と思しきところ)に)戻るかどうかですね。[追記] すみません、念のため、NORTiのおまじない関数の ient_int() と iret_int() も、NORTiのシステムコールともども、コメントアウトしてみて下さい。相談されている文面から推測すると、どちらかで期待した動作にならないのではないか、という予感がするのです。あと、ちょっと確認なのですが、RX231のNORTi+FITのサンプルプログラムをミスポ様より頂いている、とのことですが、それは、FITでのSCI使用時の受信割り込み処理も含まれているものですか？もし含まれているのなら、それを試しにTB-RX231などで動かしてみると、動作してくれないRX65Nの現象との比較確認対象に出来るかも？と思ったのです。
しんちょろす さん、こんにちは。NoMaYです。マイコンからのエコーバックの送信動作時に送信完了割り込みで問題が発生していましたか。そうなると、実は、RX231とRX65Nでマイコンの動作が微妙に異なり、FITの割り込み処理の流れも微妙に異なっていて、気になる点があるのです。(A) RX231ではFITはSCIモジュールで直接送信完了割り込みを受けている(送信完了割り込みハンドラはRETIで戻る割り込み関数)(B) RX65NではFITはBSPモジュールでグループ割り込みの1要因としてとして送信完了割り込みを受けて、そこから普通の関数呼び出しでSCIモジュールの送信完了割り込みハンドラを呼び出している(送信完了割り込みハンドラはRETで戻る通常関数)そのことにより、NORTiのおまじない関数の ient_int() と iret_int() を入れる場所がRX231とRX65Nで違っていなければいけないのではないかなぁ、という予感がするのです。
NoMaYさん
エスパーかと思うほどのアドバイスのピンポイントぶりに
>相談されている文面から推測すると、どちらかで期待した動作にならないのではないか、という予感がするのです。
> RX65NではFITはBSPモジュールでグループ割り込みの1要因としてとして送信完了割り込みを受けて・・・
に本当に感謝しかありません。
大変厚かましいお願いではございますが、引き続きアドバイスを頂けると幸いです。
午前中に何か怪しい箇所を探しておりました。
仰る通り、r_sci_rx_config.h内にも
#define SCI_CFG_ERI_TEI_PRIORITY (6) /* (RX64M/RX71M/RX65N/RX72M/RX72N/RX66N ONLY) 1 lowest, 15 highest */
と言う記述があました。
また、
＞BSPモジュールでグループ割り込みの1要因としてとして・・・
とのご指摘の通り、以下の作業までしか追えていませんが、最終的にr_bspのr_bsp_software_interrupt.c内に辿り着きました。（最初の質問に添付している画像の）
0x446の_$s_bsp_swint_nested_int_status()"に対して使用できるリソースがありません。
と言う関数もここにありました。
【以下行った作業】
①r_sci_rx65n.c内の996行目からの送信割り込み関数 txi_handlerにブレークポイントを設定
R_BSP_ATTRIB_STATIC_INTERRUPT void sci2_txi2_isr(void){ ient_int(); //NORTiおまじない txi_handler(&ch2_ctrl); iret_int(); //NORTiおまじない}
②PCのテラタームより受信を行う。上述のブレークポイントにて停止するので、ステップインで順次実行していく。
③byte_qのSCIに依存するFITの関数を進みながら、プログラムは進んで行く
④無事 NORTiおまじない関数の下段側「iret_int()」まで到着する
⑤送信タスク内の
for (;;) { err = R_SCI_Send(Console, (uint8_t *)msg->buf, strlen((char *)msg->buf)); if (err == SCI_SUCCESS) break; if (err != SCI_ERR_INSUFFICIENT_SPACE && err != SCI_ERR_XCVR_BUSY) break; dly_tsk(1); }
if (err == SCI_SUCCESS)側を通り、その下の行
rel_mpf(ID_ComMpf, msg);
で、r_bspの関数に飛ぶ。
具体的にはr_bsp_interrupt.c内の
R_BSP_ATTRIB_INTERRUPT void undefined_interrupt_source_isr(void){ /* If user has registered a callback for this exception then call it. */ R_BSP_InterruptControl(BSP_INT_SRC_UNDEFINED_INTERRUPT, BSP_INT_CMD_CALL_CALLBACK, FIT_NO_PTR);}
⑥その後ステップイン実行を繰り返すと、以下の同じ個所を回る
r_cg_hardware_setup.c内のvoid r_undefined_exception(void)
と⑤のR_BSP_ATTRIB_INTERRUPT void undefined_interrupt_source_isr(void)
です。
【愚見】
rel_mpf(ID_ComMpf, msg);というNORTi(μITORN)関数でハングアップするので、メモリ操作を誤ったかと思いましたが、タスク数も少なく、余裕を以てメモリを確保しています。
＋セクションの分割はミスポ様のRX321+FITと同様に変更済み。
上述のステップインの実行中に通る関数は
undefined_interrupt_source_isr
等の名称があるので、NoMaY様のアドバイス通り、NORTiのおまじない関数の入れる個所が違うのでは？
を参考にしようと思うのですが、何を当たっていけばいいかの助言を頂けると幸いです。
FITのbspモジュールとマニュアルと、RX65Nの割込みコントローラーは再度見直します。
しんちょろす さん、こんにちは。NoMaYです。以下のr_bspの関数に飛んだということは、もうプログラムが暴走しているのですよ。まず、ひとつの仮説ですけど(かつrel_mpf()のソースを見ていない時点では荒っぽいやり方ですが)、rel_mpf(ID_ComMpf, msg);の前で割り込み禁止にして実行後に割り込み許可に戻す、というコードを追加して、rel_mpf()をステップオーバー実行するとどうなりますでしょうか？rel_mpf()のソースを見ていない時点での荒っぽい予想ですが、ちゃんと戻ってくるのではないかなぁ、と思うのです。(ただ、rel_mpf()内で、常に割り込み許可にする、という処理が入っている可能性もありますが、、、その場合は、NORTiのクリティカルセクションの出入り関数(すみません、名前は分からないです)でrel_mpf(ID_ComMpf, msg);をサンドイッチして、試してみてください、、、)結局、どういうことかというと、たまたま何かの割り込み処理がrel_mpf(ID_ComMpf, msg);実行中に発生し、その割り込みが暴走して、くだんのr_bspの関数に飛んだのではないだろうか、という可能性について実験したいのです。＞ if (err == SCI_SUCCESS)側を通り、その下の行＞ rel_mpf(ID_ComMpf, msg);＞ で、r_bspの関数に飛ぶ。＞ 具体的にはr_bsp_interrupt.c内の＞ R_BSP_ATTRIB_INTERRUPT void undefined_interrupt_source_isr(void)＞ {＞ /* If user has registered a callback for this exception then call it. */＞ R_BSP_InterruptControl(BSP_INT_SRC_UNDEFINED_INTERRUPT, BSP_INT_CMD_CALL_CALLBACK, FIT_NO_PTR);＞ }
しんちょろす さん、こんにちは。NoMaYです。＞ NORTiのおまじない関数の入れる個所が違うのでは？＞ を参考にしようと思うのですが、何を当たっていけばいいかの助言を頂けると幸いです。これは、SCIモジュールの送信完了割り込みハンドラの出口にブレークポイントを設定して、Goすれば、いずれそのブレークポイントで止まりますので(筈ですので)、そこからステップ実行を繰り返していけば、どんどん親の関数に戻って行けますよ。
しんちょろす さん、こんにちは。NoMaYです。あと、このような暴走した場合のデバッグ手法として、デバッガのトレース機能を使う、という手もあります。関連リンク【CS+】リセット時に再起動させたくないjapan.renesasrulz.com/cafe_rene/f/forum21/7053/cs/37745#37745
頂いたアドバイス通り
clrpsw_i(); rel_mpf(ID_ComMpf, msg); setpsw_i();
と割り込みを制限してみましたが、同じ結果（R_BSP_InterruptControl）に飛びました。
が、割込み禁止をする前と比較し挙動が変わりました。
【挙動が変わった場所】
① 送信タスク内の
err = R_SCI_Send(Console, (uint8_t *)msg->buf, strlen((char *)msg->buf));より前にある
rcv_mbx(ID_ComMbx + ch, &msg);に一度処理が移ってから暴走
②rel_mpf実行時に、デバッガに以下のメッセージが表示されました。
msgの値がエラーの用です。
msgはリスト型のバッファです。
typedef struct t_commsg { /* message packet for communication */ struct t_commsg *next; /* reserved for OS space */ B buf[BUFSZ];} T_COMMSG;
/*デバッガのメッセージ*/
複数のエラーが報告されました。
1) Failed to execute MI command:-var-update 1 var12Error message from debugger back end:value has been optimized out
2) Failed to execute MI command:-var-update 1 var12Error message from debugger back end:value has been optimized out
ということは
NORTiのクリティカルセクションの出入り関数に・・・
のご指摘の通りメモリ操作がおかしいということになるのでしょうか。
（知識不足で恥ずかしい限りですが「NORTiのクリティカルセクションの出入り関数」というのが
私の理解だとメモリにアクセスする個所か？との認識です）
ありがとうございます。
辿っていき、sci_transfer関数の最後にNORTiのおまじない関数を入れてみましたが同じ結果でした。
もう少し考えてみます。
（仰る通り、bspモジュールのFITにもグループ割り込みの記述もありましたので）
また、メモリプールやメールボックスなどのRTOSの機能を使わずに R_SCI_Send関数を実行しても暴走しています。
しんちょろす さん、こんにちは。NoMaYです。すみません、私も不注意だったのですが、送信割り込みと送信完了割り込みとを使い分けていた訳では無かったのですね。BSPモジュールで一旦受けているのは、送信割り込みの方ではなくて、送信完了割り込みの方だった、のです。それで、送信完了割り込み(および送信割り込み)の確認方法も、受信割り込みの場合と同様です。(1) ちゃんとRETI命令まで辿り着いているか(2) ちゃんとRETI命令まで辿り着いたら、RETI命令を命令単位ステップ実行して、ちゃんとメイン処理に(つまり割り込み発生箇所(と思しきところ)に)戻るかどうかまずは、この2つが意図通り動くかどうかがデバッグ作業の節目かと思います。あと、rel_mpf(ID_ComMpf, msg);内で暴走する件(私の予想は、たまたま、rel_mpf()実行中に割り込みが発生し、その割り込みの最中もしくはRETI後に暴走したのでは？というものですが)は、以下のやり方でも目星を付けることが出来るかも知れないという考えが思い浮かびました。以下のように時間稼ぎのループを挿入してやれば、割り込み発生タイミングをループ内にすることが出来るので、これでループ中に暴走するならrel_mpf()はもう気にせずデバッグすれば良いと思うのです。
for(i = 0; i < 大きな数値; i++){ /* このループ中に割り込みが発生するように大きな数値の値を調整する */ nop();}rel_mpf(ID_ComMpf, msg);
また、以下については、ごめんなさい、余りにソースが断片的過ぎて、なんのことやらわからないです、、、(ただ、②はe2 studionのウォッチウィンドウで良く見掛けるエラー表示である、というのは分かりますが。)【挙動が変わった場所】① 送信タスク内の err = R_SCI_Send(Console, (uint8_t *)msg->buf, strlen((char *)msg->buf));より前にあるrcv_mbx(ID_ComMbx + ch, &msg);に一度処理が移ってから暴走②rel_mpf実行時に、デバッガに以下のメッセージが表示されました。msgの値がエラーの用です。msgはリスト型のバッファです。typedef struct t_commsg { /* message packet for communication */ struct t_commsg *next; /* reserved for OS space */ B buf[BUFSZ];} T_COMMSG;/*デバッガのメッセージ*/複数のエラーが報告されました。1) Failed to execute MI command:-var-update 1 var12Error message from debugger back end:value has been optimized out2) Failed to execute MI command:-var-update 1 var12Error message from debugger back end:value has been optimized out
NoMayさん おはようございます。
お付き合いいただき本当にありがとうございます。
頭をクールダウンさせ、整理をしました。
結論から言うと、やはりTEI（送信完了割り込み）が悪さをしているようです。
私が、途中で用語の勘違いをしていました。
TXI：送信割り込み
TEI：送信完了割り込み （RX65Nでグループ割り込みの対象の方）
という認識であっていますでしょうか。
FITのマニュアルや、ルネサスセミナー（通信編）での呼称が全て違うのです。
TXIが「送信”終了”割り込み」と記述されていたり、TEIが「送信バッファエンプティ割り込み」と記述されていたりです。
見苦しい言い訳ですが、言葉の定義をしっかりとエバーノートに再記載しました。
その上で、以下の確認を行ったので「TEIが悪さをしているのではいか」との結論に至りました。
【行った確認】
①TEI割り込み記述中の、NORTiおまじない関数をコメント化
送信は出来ませんでしたが、プログラムは暴走しませんでした。（受信するとLEDの点滅が一定時間止まるプログラムには影響なし）
②単純にR_SCI_Send関数のみを試す
単純に「1文字送信」をすると、暴走しました。
※ここでの「暴走」とは昨日と同じR_BSP_ATTRIB_INTERRUPT void undefined_interrupt_source_isr(void)に飛ぶという意味です。
もう一度BSPモジュールと割り込みコントローラー周りのマニュアル等も含めて確認してみます。
しんちょろす さん、こんにちは。NoMaYです。その後、どうでしょう？なお、RTOSでFITを使用する場合、以下の注意点があります。RX Driver Package V1.27でもケアされていなかったと思いますので、御自身でFITを改造する必要があると思うのです。e2 studio v7.5.0のFreeRTOS ProjectでVisual Expression＋Renesas RX Simulator/TB-RX65Nで試せるSample Programを作ってみたjapan.renesasrulz.com/cafe_rene/f/forum21/5970/e2-studio-v7-5-0-freertos-project-visual-expression-renesas-rx-simulator-tb-rx65n-sample-program/34046#34046「RTOS未使用時は大丈夫だけれどもRTOS使用時は拙い排他制御のやり方(通常処理側と割り込み処理側の排他制御)・個別の割り込みマスクフラグを使用して割り込み一旦禁止と割り込み再度許可を行う理由・RTOSによるタスク切り替えが上記による割り込み禁止期間中に発生すると禁止期間がミリ秒オーダーになってしまう(タスク切り替えにより暫くの間は他タスクに行ってしまうから)対応・RTOS側で用意されているクリティカルセクションへの出入り関数(FreeRTOSならtaskENTER_CRITICAL()とtaskEXIT_CRITICAL()など)を使用するように手を加える」
NoMayさん
こんにちは。気にかけて下さりありがとうございます。
生産の仕事が入っており、先週からあまり触れていなかったのですが
頂いたアドバイス通り、やはりグループ割り込みの問題に帰着しそうです。
NORTi側の割込み退避・復帰関数を、r_bspのマニュアルやコードを見ながら、様々な個所に入れましたが
やはり、本質を理解できていない「トライ＆エラー」では解決しておりません。
上記に頂きましたリンク先も今週末か来週の頭には熟読致します。
【進捗】
（恥ずかしながら問題個所は特定できたので）ミスポ様にも聞いてみた所、ミスポ様側からの回答としては
「FITでのグループ割込みでなく、NORTiでの割り込みをグループ割込みに対応した修正」を頂きました。
そもそも、「NORTiは割込み処理をOSに管理させる場合は、RAM上に割り込みを設定する」
「FITはROM上にベクターテーブルがあることが前提」とのことで、「相性が悪いのか？」と勝手に考えています。
ただ、FITにこだわる理由としては、以前にRTOSを使わないRX231でのプログラムでも、私レベルでもE2フラッシュや、USBマスストレージクラスが半日程度で、簡単なプログラムも作成できるほどでしたので、FITを利用したいと考えています。
また、私の知識不足で恥ずかしい限りなのですが
＞RTOSでFITを使用する場合、以下の注意点があります。RX Driver Package V1.27でもケアされていなかったと思いますので、御自身でFITを改造する必要があると思うのです。
ということやリンク先の情報からも
「freeRTOSでも、同じ問題が発生する可能性が高い」ということなのでしょうか。
→RTOSでの割込みは（NORTi等のμITORNのOSに関わらず、freeRTOSを含むすべてが）RAM上に割込みを記述が前提なので、FITとの割込み処理の接続には、一定の操作が必ず必要。
世間の趨勢も考え、freeRTOSが主流になるのであれば、（NORTiが勿体ないですが）freeRTOSの導入も視野に入れております。（合間に触れるように65N Cloud kitは注文はしました）
（現在どちらのＯＳも知識がゼロですので、ちょうど良い機会ではあります）
しんちょろす さん、こんにちは。NoMaYです。＞ リンク先の情報からも 「freeRTOSでも、同じ問題が発生する可能性が高い」ということなのでしょうか。そうです。こういった落とし穴は、RTOS非対応で開発が始まったライブラリには何かしら存在する、のでは無いかと思うのです。最初からRTOS対応であるRenesas Synergyのようなものであれば存在しない、だろうとは思いますが。＞ →RTOSでの割込みは（NORTi等のμITORNのOSに関わらず、freeRTOSを含むすべてが）RAM上に割込みを記述が前提なので、FITとの割込み処理の接続には、一定の操作が必ず必要。私はFreeRTOSに関してトライアル中ですが、他のRTOSに関してはもっと知識不足ですけど、どこまでがそのRTOS仕様から来ているもので、どこからが素朴に実装上の事情(または単に将来的な利便性への備え)なのか、なかなか判断が付かないですね。FreeRTOSでは、割り込み記述をフラッシュメモリ上に置いて全然問題が無い、ですね。もちろん、プログラムでファームウェアを書き換える場合など、FreeRTOSの仕様/実装とは関係無しに、一時的に処理(や場合によってはベクタも)RAM上に移さないといけない(場合もある)、といったことはあります。また、FreeRTOSでは、RX(やCortexやPIC32など)の場合、既存の割り込みコードにおまじないを追加する必要は無い、ですよ。(ただ、代償として、そうしない実装よりも数十CPUクロック程度のオーバーヘッドが発生しますけれども。) そのあたりに関しては、以下のスレッドにちょっと説明(というかヒントぐらいかも)があります。RL78 FreeRTOS APIを特別なおまじない記述無しで割り込みルーチンから呼び出せるようにしてみた(CC-RL/GNURL78)japan.renesasrulz.com/cafe_rene/f/forum21/5845/rl78-freertos-api-cc-rl-gnurl78[追記]ただ、以下のスレッドのサンプルプログラムでは、ある利便性を実現するために、結局、別のおまじないを導入するように方針を変更しています。FreeRTOSのRL78のsample programを作成していこうかと思います(RL78/G13,G14の他にRL78/G23もやろうかと思います)japan.renesasrulz.com/cafe_rene/f/forum18/7083/freertos-rl78-sample-program-rl78-g13-g14-rl78-g23
毎度のことながら詳しく教えて頂きありがとうございます。
本当に勉強になります。
「H8S2368 での既存システムの更新」が目的ですので、
＞数十CPUクロック程度のオーバーヘッド
は許容範囲かと考えています。（元システムがH8S2368+NROTiで、10[ms]のラウンドロビンで余裕があると聞いているので）
>FreeRTOSでは、RX(やCortexやPIC32など)の場合、既存の割り込みコードにおまじないを追加する必要は無い。
午前中にルネサス様にもダメ元で2点質問しました。
１．グループ割込みについて、r_bspで分岐している個所（レジスタ退避・復帰のNORTiのおまじない関数）の候補のヒントを貰えないか。
２．「おまじない関数」の処理はfreeRTOSでは不要か？
の「２」の回答を今NoMay様より頂けました。
【今後の方針】
FreeROTSの導入をメインに考えます。
ただ、現状のNORTiグループ割込みのバグも、頂いたアドバイスからコードを見て排他制御の構造を見直す。
（現システムがNORTi + H8S2368ですので、NORTiも使えれば嬉しいので）
来週を目途に、一度進捗を報告に参ります。
（FreeRTOSに完全に移行を決定し、NORTiは諦めたのか等も含めて）
しんちょろす さん、こんにちは。NoMaYです。＞ 【今後の方針】＞ FreeROTSの導入をメインに考えます。私が思ったのは、今回の業務案件(H8S2368+NROTi⇒RX65N+何かしらのRTOS)ではRTOSを変更するのは得策では無い、ような気がするなぁ、ということです。RTOSを変更するとなると、変更元と変更先の両方のRTOSのある程度の知識は必要になると思いますので、なかなか大変になると思うのです。(両方のRTOS(μITRON⇔非μITRON)でAPIが1対1の関係になっているのならさほど苦労無く置き換え出来ると思いますが、大抵そうなっていませんので苦労するのでは無いかと思うのです。)＞ 現状のNORTiグループ割込みのバグも、頂いたアドバイスからコードを見て排他制御の構造を見直す。あと、これは、NORTiバグというよりは、しんちょろすさんのスキル不足の要因が大きいような気がしますけれど、、、(さらに、何かその後に用事でもあって、その前に急いでリプライしたからかも知れませんが、グループ割り込みの話と排他制御の構造の話は全くの別物ですが、文章がごちゃまぜになっちゃっていると思うのです、、、)なお、ちょっと気になったのでウェブで検索してNORTiのUMを探して読んでみたのですが、私が予想していたような割り込みハンドラの記述ノウハウは、ちゃんと書かれていました、、、([追記] もっとも、RTOSを初めて使うような人が、これを読んで理解出来るだろうか？、と考えてみると、ちょっと無理ですよねぇ、とは思います、、、)www.mispo.co.jp/document/no4guid.pdf画面コピー(3枚)
しんちょろす さん、こんにちは。NoMaYです。NORTiのUMの別のページも読んでみて、たぶんこれで私の側でそれなりに試せるようになるかな、と思ったのですが(私は、NORTiを使ったことは無く、もちろん持ってもいない、ですが)、ただ、まだ足りないピースがあると思っていて、それは、NORTiでは割り込み処理をRAMに置かなければならないのかな？、という点です。ここまでUMを読んでみた限りでは、そのような記載は見当たらなかったのです。その話はどこから来たのでしょうか？ちなみに、今回のしんちょろすさんのように、ユーザさんがRTOSベンダとライブラリベンダ(今回はマイコンベンダでもありますが)との板ばさみになる課題+その他もろもろ、を解消しようとしたのがRenesas Synergyだったのです。RTOSから何でもかんでもルネサスさんでワンストップでサポートしますよ、ということでしたけど、、、でも、その課題はそもそも多くのユーザにとって大きな関心事で無かったことが判明したからなのか(？)、Renesas Synergyの代わりに、RAマイコン+FSPフレームワークを最近は強くプッシュしているみたいです、、、www.mispo.co.jp/document/no4guid.pdf追加画面コピー(3枚)
NoMaYさん、こんにちは。
＞ 現状のNORTiグループ割込みのバグも・・・
お恥ずかしい限りですが、ご指摘の通りリプライを急いだ為の言葉足らずになってしまいました。
「自身の能力も含めて、自分の意図する動きをしない状態 ＝バグ」と言い換えていました。
結論から申し上げますと、FreeROTSに変更します。
次回号機の開発まで1年半程度の猶予もあり、先方の担当者の定年の為引継ぎに、新人さんに教えるのでタスク構造から資料を作り直すとのことで、RTOSの変更も了承頂きました。
ルネサスの技術サポートの方からも、回答を頂き、上記の問題はfreeRTOSでは発生しないという旨も教えて頂きました。
ミスポ様のRX231+FIT用のプロジェクトに、上記添付画像のent_int();をFIT対応用に、修正したient_int();と言うものに修正したものがあったので、それを利用したのですが、TEIがグループ割込みの為・・・とう事になりました。
そして、ミスポ様からも「FITでのグループ割込みは対応するのに、色々修正が必要だが、対応はしない。FITを使わない方法を推奨している（意訳）」との回答も頂きましたので。
（誰かを責めているという意味ではありません）
＞ちなみに、今回のしんちょろすさんのように、ユーザさんがRTOSベンダとライブラリベンダ(今回はマイコンベンダでもありますが)との板ばさみになる課題+その他もろもろ、を解消しようとしたのがRenesas Synergyだったのです。RTOSから何でもかんでもルネサスさんでワンストップでサポートしますよ、ということでしたけど、、、でも、その課題はそもそも多くのユーザにとって大きな関心事で無かったことが判明したからなのか(？)、Renesas Synergyの代わりに、RAマイコン+FSPフレームワークを最近は強くプッシュしているみたいです、、、
との背景をご教授ありがとうございます。
最近RAマイコン推しが強いので、少し不安ですが、さすがにRXコアのマイコンはすぐには消えないと信じて（コンパイラも購入しているので）RX + FreeROTSで頑張ってみます。
ライン入りの写真で申し訳ございませんが（テキストファイルが見つかりませんでした・・・）
がFミスポ様から頂いたRX231+FITのサンプルに付属していた説明です。
今後も別の案件でNORTiとFITで色々悩むよりは、freeRTOSでしたら情報も集めやすいかと思うのもあり
（ルネサスさんも公式に対応しているので、アップデートも行わなれると思うので）
freeRTOSで行こうかと思う所存です。
色々とアドバイスを頂き本当にありがとうございました。