新しいS32K388を持っていて、最初から作ったファームウェアでフラッシュしようとしています(これはAUTOSARでもRTDでもありません)。IVTの設定ではcore0のみを起動するようにしており、hse_fw_header_start_addressはゼロに設定しています。
しかし、この構成ではリセットが発生し、MC_RGM DES が以下のように報告しているようです。
0x00000041 と MC_RGM FES が報告する 0x00010000 は、S32K3XXRM に関する私の読み方に基づくと、HSE ウォッチドッグのタイムアウトがエスカレーションに基づく破壊的なリセットにつながっていることを示唆しています。
興味深いのは、この挙動はj-linkに接続すると消えるように見えることですが、ファームウェアからSWTを無効化したりメンテナンスしたりする方法が見つかりません。S32K388用の標準HSEファームウェアをダウンロード/インストールする必要がありますか?
S32K388ではこれが必須なのに、S32K344では必須ではない理由は何ですか?
さらにテストを進めてみると、FES/DES MC_RGMのフラグをすべて読み終えて(ブート間で固定されないように)すると、ブートループが戻り始めます:FES: 0x00010000、時々DES: 0x00000040(ただしほとんどの場合はDES: 0x00000000)
元の投稿を明確にするために、IVTのブート構成ワードを0x00000001に設定しています。私の解釈では、これはCM7_0_ENABLEのみが設定されており、HSE/SWT_0の設定は一切必要ないことを意味するように思えます。
そして、もし他のコメントが解決策でなかった場合のために:
この投稿に基づいています: https://community.nxp.com/t5/S32K/What-does-it-mean-HSE-SWT-RST-on-S32K311/mp/1955147
そして、S32K3XXRM の旧バージョンからの S32K3xx_DCF_clients.xlxs の画像はこちらです: https://community.nxp.com/t5/S32K/S32K388-HSE-No-Response-Error/mp/2090937/highlight/true?lightbox-m...
UTESTメモリセクタに0x40000101 0x00100006から0x1B000770まで書き込むことで(HSE_CLK_MODE_AND_GSKT_CTRLに「2」を入れることで)、問題が解決したようです。
S32K3xx_DCF_clients.xlxs の最新版では、HSE_CLK_MODE_AND_GSKT_CTRL の説明は以下のとおりです。
しかしS32K3XXRMでは、ガスケット構成で何を設定すべきかの参照が見つかりません(最も近いのは「HSE_B」のように見えますが、表は不可能な1:1構成を示しています):
これは単なるドキュメント更新の失敗でしょうか?オプションA++クロック(CORE_CLKが160MHz、AIPS_SLOW_CLKが40MHz)を使用している場合、HSE_CLK_MODE_AND_GSKT_CTRLの比率を1:4にする必要がありますか?
訂正させてください。上記のコメントの最後の文は、「HSE_CLK は 160MHz、AIPS_SLOW_CLK は 40MHz」と書くつもりでした。
以下の情報を提供していただけますか:
使用されているS32K388の正確な部品番号とチップのリビジョン。
このデバイスにHSEファームウェアが過去にインストールされたことがあるかどうか(または、完全に初期状態のデバイスであるかどうか)を確認します。
IVT構成、特にhseFwHeaderStartAddr、appBootAddr、およびその他のHSE関連のIVTフィールドの値。
リセット後のリセットステータスレジスタの完全なダンプ(MC_RGM_DES、MC_RGM_FES、およびその他の関連するリセットレジスタ)。
問題が複数のデバイスで発生するのか、それとも単一の基板でのみ発生するのか。
問題を再現する最小限のプロジェクトやアプリケーション、あるいはリセット前に実行されたスタートアップコードのシーケンスを再現するもの。
現時点でリセットがHSE/SBAFによるものなのか、アプリケーションの問題なのか、デバイス設定の問題なのかは明らかではありませんが、上記の情報が根本原因を特定するのに役立ちます。
私たちの知る限り、これで問題は解決しました。オプションA++がこのガスケットの変更を必要とすることをドキュメントに反映してほしい@davidtosenovjan