NXPテクニカルサポートチームの皆様、こんにちは。
S32K328のFIRCクロック設定について質問があります。
STM2モジュールのFIRCクロックソースを3MHz(DIV 16)にシングルコアセットアップで設定しました。シングルコア構成では、FIRCクロックソースが正しく3MHzで出力されていることを確認しました。
しかし、マルチコアを有効にすると、分周器が16に設定されているにもかかわらず、FIRCクロックソースの出力が3MHzではなく48MHzになります。
現在のアーキテクチャでは、MCUの開始モードとセットモードはCore 0上でしか実行できません。私の質問は、Core 1からMCUクロックにもアクセス(または再設定)できるのか、そしてこれが問題の原因になるのかということです。
私の環境設定に関する補足情報：
- 私はAUTOSAR環境で作業しており、マルチコアサポートのためにRM(Resource Manager)モジュールを追加しました。
- Domain0 マスター: コア 0、Domain1 マスター: コア 1。各ドメインに対してすべてのメモリおよびペリフェラルアクセス権限が付与されています。
ツール環境:
- MCAL RTD 3.0.0
- EB Tresos 27.1.0
私自身の分析からの発見:
実行時にCONFIG_REG_GPRレジスタのFIRC_DIV_SELフィールドを読み取ると、値は3となり、これはドライバーコードに基づき48MHzに対応します(DividerValueマッピング:48MHz→3、24MHz→1、3MHz→2)。また、クロックドライバーのディバイダー書き込みパスにはAPP_CORE_ACC権限チェックと、Secure BAF(CORE2)がWFIに入るまでの待ち時間(ポーリングPRTN0_CORE2_STAT)が含まれていることに気づきました。マルチコア構成では、除算器への書き込みがスキップされる可能性があると推測されます。
以下の点についてアドバイスいただけますか:
- マルチコアが有効になっている場合、FIRC分周器の設定（DIV 16）が適用されず、3MHzではなく48MHzの出力になるのはなぜですか？
- このシナリオでは、Core 1からのMCUクロックへのアクセスや再設定がサポートされているか、または必須かは不明です。
- マルチコア構成におけるAPP_CORE_ACC権限チェックやSecure BAF WFIタイムアウトによって、ディバイダー書き込みをスキップできるかどうか、そしてディバイダーが正しく適用されているかを確実にする方法についてです。
サポートありがとうございます。ご回答をお待ちしております。
よろしくお願いします、
AWSライブラリS32K3
こんにちは、
根本原因 は 自分の側にある。 該当するドライバー機能は 以下の(Clock_Ip_SetFircDivSelHSEb in \Mcu_TS_T40D34M30I0R0\src\Clock_Ip_IntOsc.c をご覧ください
/* Application can write this divider */ if ( ((IP_CONFIGURATION_GPR->CONFIG_REG_GPR & CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_MASK) >> CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_SHIFT) == CLOCK_IP_APP_CAN_WRITE) { ... /* FIRC_DIV_SEL write happens here */ } else { /* HSE firmware doesn't allow to write FIRC post divider. */ Clock_Ip_ReportClockErrors(CLOCK_IP_REPORT_WRITE_PROTECTION_ERROR, Config->Name); }
問題は 、 私のマルチコア構成では 、 フルスピードで動作しているときにコードが(APP_CORE_ACC == CLOCK_IP_APP_CAN_WRITE)ブロックに入らないことです。 ブロック 内に while(1)を入れて確認 しました が、その時間は一度も到達しません 。その結果、 FIRC_DIV_SEL書き込みがスキップされ、 レジスタは設定された2(3MHz)ではなくリセット値3(48MHz) のままになります 。これにより、私のSTMティックは意図した16倍速く動作 します。
しかし、デバッグモード（ステップ実行／ブレークポイント設定）で実行すると、同じブロックが正しく実行され、FIRC_DIV_SELも適切に2（3MHz）に設定されます。このフルスピード実行とデバッグ実行の違いが、問題の重要な症状です。
So the APP_CORE_ACC bit in CONFIG_REG_GPR is not set to CLOCK_IP_APP_CAN_WRITE at the moment Mcu_InitClock reads it during a full-speed multicore boot, but it does become writable when I slow execution down with the debugger.
私の環境設定に関する補足情報：
- Mcu_InitClockとMcu_SetModeはコア0でのみ呼び出されます。Core 1(CM7_1)はMCUクロックAPIを呼び出しません。
- コア1は、 MC_ME （PRTN0_CORE1_*） を介してコア0から起動されます 。
- HSEアプリケーションのファームウェア は 一切読み込んで いません。
- 同じ構成 は シングルコア(FIRC_DIV_SEL = 2 / 3MHz)でも正しく 動作します。
- ツール環境：MCAL RTD 3.0.0、EB Tresos 27.1.0。
以下の点を理解する手助け をしてもらえます か?
- CONFIG_REG_GPRのAPP_CORE_ACCビット を制御するものは何 でしょうか?SBAFはどのような条件下で アプリケーションコアの書き込みアクセス をFIRC_DIV_SELに付与 しますか?
- なぜこのビットはシングルコアでは正しく設定されるのに、マルチコア構成では(フルスピードで)設定されないのでしょうか?CM7_1を起動したりマルチコアブートフローを追加したりすると、SBAFがこのアクセスを許可するタイミングや変更は変わりますか?
- ブロックは デバッガ下では正しく 実行 されますが、フルスピードではないため、 SBAFが 書き込みアクセスを許可し、Core 0 がMcu_InitClockを呼び出す場合のタイミングや順序の問題 が強く示 唆 されます。 Core 0がクロック 初期化を行う 前に SBAFがAPP_CORE_ACC = APP_CAN_WRITEを付与していることを確認する 推奨方法は 何でしょうか?
- マルチコア環境 で アプリケーションコアが このアクセス権を付与 される かどうかを決定する 特定の ブート構成(IVT、 ライフサイクル、またはSBAF関連 の設定)はありますか?
Thank you for your サポート. I look forward to your guidance.
よろしくお願いします、
こんにちは、
そちら側でのテストと 詳細なご回答、 ありがとうございました 。
私の実装に関する ご質問にお答えします 。
1. FIRC_DIV_SELの設定方法:
私のClock_Ip_IrcoscConfigurations_0 構造 では 、FIRCクロック は IRCOSCの範囲をCLOCK_IP_SUPPORTS_3MHZ_FREQUENCYに設定 しています 。つまり 、意図された構成は3MHzで、 あなたのテストと同じです。
2. 2番目のコアの初期化方法 / もう一方のコアでクロック初期化を呼び出すかどうか:
Mcu_InitClock とMcu_SetModeはどちらも Core 0でのみ呼び出されます。 Core 1では、MCU クロック関連のAPI は一切呼び出していません 。
とはいえ、 コア1で意図しない クロック再構成が発生していないことを 確認するため、私の側でさらにデバッグを 行い 、この動作を再確認します 。
その他の観察事項：
- シングルコアでは、FIRC_DIV_SEL 2 (3MHz)として読み取られ、正しく動作します。
- マルチコアでは、FIRC_DIV_SELが3(48MHz)と読み取られ、STMティックは予想の16倍速くなります。
ご指摘いただいたとおり、最新のRTDリリース への移行についても検討いたします 。
デバッグ結果 はまた お知らせ します。その間に、 クロック初期化がCore 0の3MHz 構成 でのみ行われ ているにもかかわらず、 FIRC_DIV_SELが3( 48MHz)になる原因について何か アドバイス をいた だけるとありがたいです。
よろしくお願いします、
こんにちは、 @dpsdprtmvl
まず、使われているソフトウェアのバージョンは現在のバージョンより数リリース遅れているので、最新のソフトウェアリリースへの移行をお勧めします。
FIRC_DIV_SELに関して、S32K3 IPCF v4.3.0のIPCF_Example_S32K358を使用して、S32K3X8EVB-Q289ボード上で簡単なテストを実施しました。このテストでは、IRCOSC構成構造（Clock_Ip_IrcoscConfigurations_0）を変更し、IRCOSCの範囲をCLOCK_IP_SUPPORTS_48MHZ_FREQUENCYからCLOCK_IP_SUPPORTS_3MHZ_FREQUENCYに変更しました。
アプリケーションを実行し、コア間のピンポン通信が完了するのを確認した後、CONFIG_REG_GPR[FIRC_DIV_SEL]が下の画像のように期待値(10b)に正しく設定されていることを確認しました。
実装についてもう少し詳しく教えていただけますか?FIRC_DIV_SELはどのように設定していますか？2つ目のコアはどのように初期化していますか？他のコアでもクロック初期化を呼び出していますか？
BR、VaneB