RX e2studioのスマートコンフィグレータのクロック設定の発信源を外部発信入力にしE2liteでデバッグしようとすると無限ループします

RXをe2studioのスマートコンフィグレータのクロック設定で発信源を外部発信入力にしてコード生成し、E2liteでデバッグ実行するとPLLクロックのOSCOVFSRのチェック処理で無限ループします。

mcu_clocks.c 

/* Set the oscillation stabilization wait time of the main clock oscillator. */
#if BSP_CFG_MAIN_CLOCK_SOURCE == 0 /* Resonator */
SYSTEM.MOSCWTCR.BYTE = BSP_CFG_MOSC_WAIT_TIME;
#elif BSP_CFG_MAIN_CLOCK_SOURCE == 1 /* External oscillator input */
SYSTEM.MOSCWTCR.BYTE = 0x00;
#else
#error "Error! Invalid setting for BSP_CFG_MAIN_CLOCK_SOURCE in r_bsp_config.h"
#endif

/* Set the main clock to operating. */
SYSTEM.MOSCCR.BYTE = 0x00;

/* Dummy read and compare. cf."5. I/O Registers", "(2) Notes on writing to I/O registers" in User's manual.
This is done to ensure that the register has been written before the next register access. The RX has a
pipeline architecture so the next instruction could be executed before the previous write had finished.
*/
if(0x00 == SYSTEM.MOSCCR.BYTE)
{
R_BSP_NOP();
}

/* WAIT_LOOP */
while(0 == SYSTEM.OSCOVFSR.BIT.MOOVF)
{
/* The delay period needed is to make sure that the Main clock has stabilized.
If you use simulator, the flag is not set to 1, resulting in an infinite loop. */
R_BSP_NOP();
}

で無限ループします。

何か良い回避方法ありませんでしょうか?

Parents
  • Muraさん、こんにちは。NoMaYと申します。

    すみませんが、少し教えて下さい。お使いのマイコンはRXマイコンの何でしょうか?(念の為に型番も教えて下さい。) お使いのマイコンボードは何でしょうか?(御社設計ボードであれば、その旨、リプライ下さい。) また、以下のものをzipファイルに固めてリプライに添付して頂き、見せて頂くことは出来ますでしょうか?

    (1) ○○○.scfgファイル (ぜひ)
    (2) src/smc_gen/r_config/r_bsp_config.h (ぜひ)
    (3) .projectファイルと.cprojectファイル (出来れば。なお、個人情報もしくはマル秘情報が含まれていれば"XXX"等で伏字にして下さい。)

    それで、何か良い回避方法ありませんでしょうか、とのことですけれども、RXスマートコンフィグレータの設定や生成されたコードが正しければ、これは以下の状況になっているということ、の筈ですのでハードウェアを確認されるのが良いと思うのです。これらの点はどうでしょうか?

    (1) 外部発振入力されていない(回路設計ミス、基板設計ミス、基板製造不良)
    (2) 発振器でなく発振子であるならば、発振回路のマッチングがとれていなくて、発振していない

    [追記]

    (3) とりあえずRX65Nのハードウェアマニュアルを見るとLOCOでカウントする仕組みになってますね

    [メモ]

    すみません、自分用のメモです。置かせて下さい。

    ルネサスFAQ検索: MOOVF
    ja-support.renesas.com/search/MOOVF
    検索結果なし

    ルネサスFAQ検索: main
    ja-support.renesas.com/search/main
    検索結果あるものの該当しそうなものはなし(例えば、main関数に来ない、などを期待)

  • NoMAYさん、こんにちは。Muraです。

    返信遅くなり申し訳ございません。

    投稿してからルルツに何故かログインできない症状が発生し、ルルツ管理人さんに対応頂いておりました。

    ルネサス技術サポートにも同内容問合せしており、ログイン出来ない期間に技術サポートから回答頂きました。

    有難うございました。

  • NoMAYさん、こんにちは。Muraです。

    すみません。ルルツでのログインに手間取っている間に制御基板の所有権が移ってしまいました。

    ↑で返信頂きました以下(1)~(3)一式をアップさせて頂きます。

    (1) ○○○.scfgファイル (ぜひ)
    (2) src/smc_gen/r_config/r_bsp_config.h (ぜひ)
    (3) .projectファイルと.cprojectファイル (出来れば。なお、個人情報もしくはマル秘情報が含まれていれば"XXX"等で伏字にして下さい。)

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

    ZIPファイルありがとうごさいました。RX72M R5F572MNDxBDだったのですね。(ハードウェアマニュアルを確認すると発振安定時間をLOCOでカウントして確保する仕組みですね。LOCOでカウントするのでカウンタが進まないということがあるのだろうか、という点で私が間違ったことを言ってしまった可能性もありそうです。)

    それで、頂いたZIPファイルですが、ソース一式も入ってしまっていますけれども、某社さんのソースと思しきソースも含まれていて、うっかり手違いで含めてしまった、ということはないでしょうか?(ライセンス的に大丈夫でしょうか?)

  • NoMAYさん、こんにちは。Muraです。

    発信安定時間に関し、制御基板が手元に来ましたらご教示頂いてる内容参考に確認してご報告しようと思っています。

    zipファイルに関してご忠告有難うございます。大丈夫なのですが一応削除させていただきました。

  • NoMAYさん、ご無沙汰しております。Muraです。

    当件の無限ループに関して、一応解決を見ましたのでご報告させて頂きます。

    外部発信入力で動作させる弊社制御ボード環境では、ベースのmcu_clocks.cの設定では、

    clock_source_select()関数のメインクロック発信器強制発信ビットが0(強制発信なし)

    SYSTEM.MOFCR.BIT.MOFXIN = 0;

    となっておりますが、こちらを1(強制発信)にしたら、無限ループに陥る事なく正常に

    起動できましたのでご報告いたします。

    多々ご教示頂きまして有難うございました。

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

    FITのBSPモジュールを変更したら何とか動作するようになった、ということですね。こちらでハードウェアマニュアルを見直してみたのですが、実はSYSTEM.MOFCR.BIT.MOFXINをそのようにすれば状況が改善されることに関係しそうな記載に辿り着くことが出来ませんでした。もし、Muraさんの方でそのような記載を見つけておられましたら、それを知りたいと思いました。

    もちろん、ハードウェアマニュアルで目に入ったSYSTEM.MOFCR.BIT.MOFXINを闇雲に(というと語感が悪いですが)試してみたら動作するようになったので、という話であれば、そういったリプライで構わないです。



    他方、今回ハードウェアマニュアルを見直してみて気になった箇所があったのですが、手元に、RX72Mボードも無いし、外部クロック入力の何かしらのボードも無いし、で、どう調べようか、しばし思案中だったりします。(ひょっとしたら、マイコンのアンドキュメンテッドな仕様とBSPモジュールのソースが矛盾していたりするのかも?)

    RX72Mグループ ユーザーズマニュアル ハードウェア編
    R01UH0804JJ0111 Rev.1.11 Pages 3399 2021.02.26
    366P

    9.2.17 メインクロック発振器ウェイトコントロールレジスタ(MOSCWTCR)

    発振安定待ち回路は、待機時間を計測し、MCU 内部へのクロック供給を制御します。MOSCCR.MOSTPビットの設定によりメインクロック発振器が発振を開始すると、発振安定待ち回路はLOCO クロックで待機時間をカウントし始めます。カウントが完了するまでの間、MCU 内部へのクロック供給は行われません。カウント完了後、MCU 内部へのクロック供給が開始され、OSCOVFSR.MOOVF フラグがセットされます。

    メインクロック発振器に外部クロックを入力している場合、待機時間は必要ありません。MSTS[7:0] ビットには“00h” を設定してください。(補足: MSTS[7:0]は8ビットレジスタMOSCWTCRの全体です by NoMaY)



    気になったのは、以下の点です。

    MOSCWTCR=0とした場合のOSCOVFSR.MOOVFフラグの振る舞いはどうなるのだろう?(FITのBSPモジュールはRXスマートコンフィグレータGUI上で外部クロック入力選択時はMOSCWTCR=0としている。)

    MOSCCR.MOSTP=1⇒0と書き換えた瞬間にOSCOVFSR.MOOVF=0⇒1へと変化するのかなぁ?

    でも、MOSCWTCR=0という特殊な設定(最終値が0のダウンカウンタに初期値として0を設定)での振舞いは、変なことが起きても不思議は無いような、、、(感覚的に、初期値1でも気掛かりで、初期値2以上であれば自然に振舞ってくれると思うのだけれども、といった気がしたのです、、、)

    つまり、可能性の1つは、以下のようなことです。

    マイコンの回路設計上、MOSCWTCR=0とした場合はOSCOVFSR.MOOVFフラグは永久に立たないかも知れない?
    (MOSCWTCR=0とした場合はOSCOVFSR.MOOVFフラグが立つのを待つようにループさせるのは禁則事項とか?)

    「メインクロック発振器に外部クロックを入力している場合、待機時間は必要ありません。MSTS[7:0] ビットには“00h” を設定してください。」

    待機時間は必要ありません。= OSCOVFSR.MOOVFフラグをチェックする必要はありません。

    (実は)MSTS[7:0]=0設定時はOSCOVFSR.MOOVFフラグは立ちません。

    (よってアンドキュメンテッドだけれども)OSCOVFSR.MOOVFフラグをチェックしてはいけません。

    他方、マイコンの回路設計上、MOFCR.MOFXIN=1に設定すると常にOSCOVFSR.MOOVF=1が読める回路とか?
    (ハードウェアマニュアル上はアンドキュメンテッド?)

    だったりとか?というのが気になったのです。

  • ノーマイさん、こんばんは。ムラです。

    おっしゃる通り、MOFCRレジスタの強制発信子レジスタの操作で動作するようになった点は私もしっくりきておりません。

    以下、MOSCWTCR=0で実行させた際のデバッグ状況について下記します。

    1)記載のOSCOVFSR.MOOVFをループ監視しているところで無限ループしますが、以降でも他OSCOVFSR.の他のPLOVF、PPLOVFを見ているループで無限ループするので、合計3箇所無限ループする箇所があります。

    2)上記無限ループする3箇所をコメント化しても、次はSCKCR3レジスタにPLL回路を選択する値をセットする箇所でデバッガが制御不能になります。

    対処方法としまして、clock_source_select関数の頭で、SYSTEM.外務省.ビット。MOFXIN = 1;をセットして、ソースセレクトの関数の終わりでSYSTEM.MOFCR.BIT.MOFXIN = 0;に戻すと上記1)の処理はコメント無しで、想定のレジスタが全て設定出来、プログラムが起動しタスクの先頭まで走るようになりました。

    ※但し、この対応が影響しているからか外部バスを使用しているのですが、レジスタの設定は間違い無いのに外部バスのクロックが想定通りに出ていないことが判明し、現在そちらでも頭を悩ませています。

    当件、ルネサスのサポートに問合せをさせて頂こうと考えています。

    多々お力添え頂き、感謝いたします。

    また、何か分かりましたら連絡させて頂きます。

  • ノーマイさん、こんばんは。ムラです。

    立て続けにすみません。

    一部、文字化けしました。

    失礼しました。

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

    情報ありがとうございました。ルネサスさんへの問い合わせに対してルネサスさんから回答がありましたら、また教えて下さい。MOOVFフラグ以降もあちらこちらの立つべきフラグが立たない状況になってしまうのですね。漠然とした予感で、クロック系統上の外部クロック入力端子に近い側でクロック伝達が遮断されてしまっている、っぽいですね。その部分がMOFCR.MOFXIN=1とすることで遮断されずにクロックが伝達して色々とフラグが立って、一旦フラグが立ってしまえば、MOFCR.MOFXIN=0としても動作し続けてくれている、みたいな感じでしょうかね。

    ルネサスさんへの問い合わせに対してルネサスさんから回答がありましたら、また教えて下さい。もしも、最終的な話がハードウェアマニュアルの誤記(マイコンの回路と実は合致していなかった)ということでしたら、FITのBSPモジュールのソースをルネサスさんに直して頂く話を挙げないといけないかも知れない気がしましたので。

  • NoMaYさん、こんにちは。ムラです。

    私もなんとなくそんな感じがしています。

    色々とご教示ありがとうございます。

    ルネサスから何らかの回答頂き次第ご連絡差し上げるようにいたします。

  • NoMaYさん。こんにちはムラです。

    当内容の原因が判明し、問題解決しましたのでご連絡いたします。

    原因は、クロック設定GUIのメインクロックの発信源の選択が2つあるのですが、「外部発信入力」の選択にしていた為でした。今回の回路では「発信子」にしないとクロックが入ってきませんでした。

    大変お騒がせして申し訳ございません。

    色々ご教示頂きありがとうございました。

Reply
  • NoMaYさん。こんにちはムラです。

    当内容の原因が判明し、問題解決しましたのでご連絡いたします。

    原因は、クロック設定GUIのメインクロックの発信源の選択が2つあるのですが、「外部発信入力」の選択にしていた為でした。今回の回路では「発信子」にしないとクロックが入ってきませんでした。

    大変お騒がせして申し訳ございません。

    色々ご教示頂きありがとうございました。

Children
  • Muraさん、こんにちは。NoMaYです。

    念の為、確認させて下さい。

    Q) Muraさんの回路は以下の(A)だったのですか?もともと(B)では無かったということですか?

    (A) 発振子を繋いでいた
    (B) マイコン外部にクロック生成回路/クロック生成器があってそのクロック生成回路/クロック生成器からクロックを入れていた

    思うに、(B)であったのにRXスマートコンフィグレータ上で発振子を選択しなければならない、のであれば、それも変な話には違いないのでは?、と気になったのです。ただ、Muraさんの回路が(A)であったのにRXスマートコンフィグレータ上で外部クロック入力を選択していた、のであれば、それは駄目ですよね、ということで良いのだと思ったのです。

  • NoMaYさん。こんにちはムラです。

    (A)になります。

    お手数お掛けいたしました。

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

    > (A) 発振子を繋いでいた
    > (B) マイコン外部にクロック生成回路/クロック生成器があってそのクロック生成回路/クロック生成器からクロックを入れていた

    > Muraさんの回路が(A)であったのにRXスマートコンフィグレータ上で外部クロック入力を選択していた、のであれば、

    > (A)になります。

    こちらの方だったわけですね。どうもリプライありがとうございました。