こんにちは、皆さん。
私は NXP S32Z270 を使用していますが、リセット時の RTU0 クロック周波数を確認し、Lauterbach デバッガーとの接続時に発生する MC_CGM アクセスの問題を明確にしたいと思います。
時計に関する質問
アプリケーション レベルのクロック初期化が実行される前に、リセット直後に RTU0 がどのクロック ソースと周波数で実行されているかを確認してください。RCONは0x30481804です
MC_CGM アクセスの問題
次のような動作を観察しています。
TRACE32 経由で RTU0 に接続する場合:
RTU0.MC_CGMを読み取れません
RTU1.MC_CGMを読み取ることができます
RTU1に接続すると:
CANでRTU0.MC_CGMを読み取ることができます
RTU1.MC_CGMを読み取れません
これは直感に反するように思えます。RTU0 はコネクテッドの場合、常に独自の MC_CGM ブロックにアクセスできるはずです。RTU0 が RTU0.MC_CGM にアクセスするのを防ぐことができるクロック、リセット、または保護メカニズムはありますか?
よろしくお願いいたします！
こんにちは@danieljcoliveira 、
お問い合わせいただきありがとうございます。より良いコミュニケーションのためには、一度に 1 つの質問に集中するほうがよいでしょう。リセット時のクロック周波数、およびリセット時のあらゆる構成に関するマターについては、リファレンス・マニュアルに添付されている Excel シート S32Z2_boot_settings.xlsx を確認してください。
文書を確認して、必要な情報が見つかった場合はお知らせください。
よろしくお願いします。
ファイルを見ると、私の構成では RTU0 周波数は 48MHz であると推測されます。
理由:
S32Z2_boot_settings.xlsx ファイルを見ると、重要な依存関係の1つが NO_PLL_BOOT_ENABLE 設定であることがわかります。前述の通り、私の RCON 設定は 0x30481804 なので、NO_PLL_BOOT_ENABLE=0 となります。
| ソースPLL | FIRC 参照クロック （MHz） | VCO （MHz） | フィ0 | ファイ1 | ファイ2 | ファイ3 | ファイ4 | ファイ5 | ファイ6 | DFS0 | DFS1 | DFS2 | DFS3 | DFS4 | DFS5 |
| コア | 51 | 2400 | 0 | N.A. | N.A. | N.A. | N.A. | N.A. | N.A. | 0 | 400 | 0 | 0 | 400 | 0 |
そのため、BootROM クロッキングの PLL DFS 周波数テーブルに従うと、PHI0 および DFS0 出力は 0 となり、FIRC クロックが RTU0 の唯一のクロック ソースになります。この分析は正しいですか@alejandro_e ?これは投稿を作成する前の私の最初の直感でしたが、依存関係が欠けている可能性があると疑っていました。
こんにちは@danieljcoliveira 、
はい、その通りです。FIRC はすべてのコアの想定クロック ソースです。ページ上部の注記にもそのことが記載されています。
「BootROM は、FIRC をクロック ソースとしてコア PLL とペリフェラル PLL をロックします...」
「モジュール クロッキング状態」シートでは次のようになります。
| モジュール | リセット解除時のデフォルトのクロック状態 | BootROM実行中 | BootROMパス制御 | 備考 | |
| HSE FW - セキュアブートの場合 (BOOT_SEQ=1) |
アプリケーション - 非セキュアブートの場合 (BOOT_SEQ=0) |
||||
| R52-RTU-0/SMU-M33 | ディセーブルされる | イネーブルされない | イネーブルされない | FIRC | アプリケーションコアは常にFIRCクロックで有効です |
FIRC の許容範囲については、「BootROM Clocking」シートの上部にある完全な注意事項を確認してください。
MC_CGM 読み取り時の問題について。以下の情報をご提供ください。
- 私たちの例の 1 つを実行して MC_CGM を読み取ろうとしましたか?それとも自分のアプリケーションだけで試しましたか?
- CANで読み取りを行う際に使用している具体的な手順を説明していただけますか?どのようなエラー/問題が発生しているのでしょうか?
よろしくお願いします。