こんにちは、
私たちのプロジェクトでは、ABブロックを備えたHSE Bファームウェアを搭載したS32K358を使用しています。
属性原因リセットを取得するためにHSE APIを実行した際に問題が発生しました。
デバッグ中、APIを実行する前はFSRは正常です
Mu_Ip_SetTxRegisterを実行してMU0 TR[1]レジスタを設定した後、2つのレジスタがエラーを報告しました。
| FSRステータスが0F600002であれば、チャネル#1の実行が進行中であることを意味します |  image (6).png画像（6）.png |
| GSRステータスは67030001で、HSE_ERR_GENERALを意味します。 |  image 8.png画像8.png |
HSE APIが正常に動作する他のプログラムを確認したところ、MU0 TR[1]レジスタを設定するためにMu_Ip_SetTxRegisterを実行した後、2つのレジスタは正常でした。
- FSRステータスは0F600000です
- GSRステータスは00000000です
この問題を解決するにはどうすればよいでしょうか？
こんにちは、
その件について何か進展はありますか?
私も同じ問題に直面しています。MCU S32K324はHSEファームウェアでライフサイクルを進めてから1秒でリセットされたOEM_PROD?
前もって感謝します
アユーブ。
新しいケースは地域のFAEチームに割り当てられているので、重複を避けるために次のステップや調査は彼らに任せることをお勧めします。
HSE LCの開発を進める頃には、私はTrace32を使用していた。測定時間が正確でない可能性があります。申し訳ありませんでした。
デバッグポートのロック解除を何度か試みた後、Trace32はECUが継続的にリセットされていると報告する。基板の電源をオン/オフしても、ECUはリセット状態のままです。
どのような種類のリセット（破壊的リセット／機能的リセット）が発生しているかを把握し、根本原因を特定するにはどうすればよいですか？
デバッグポートはLC IN_FIELDで保護されています。この問題のせいでデバッグスクリプトでデバッグポートをアンロックできません。
もし1秒遅れて起きたら、何でもあり得ます。そして、ライフサイクルの進行とは無関係の場合もあります。問題についてもっと詳しい情報が必要です。
リセット直後、HSEのライフサイクルがIN_FIELDに変更されたため、HSEはデバッグポートを保護しました。
リセット直後にRGMのFESおよびDESレジスタは読み取れません。
リセットの原因は何だったかご存知ですか？リセット後にRGM、FES、DESレジスタを確認しましたか？
HSEファームウェアがインストールされている場合、LCコンフィギュレーションワードを使用してライフサイクルを進めることはできません。どんな数値でも構いませんが、HSEファームウェアをインストールすると無視されます。この場合、ライフサイクルはHSEサービスを通じてのみ進めることができます。
よろしくお願いいたします。
ルーカス
こんにちは、
私はこれらのコマンドを同期モードで実行しました。
奇妙なことに、プログラム ADPK に属性を設定してデバッグ認証モードを設定すると、ECU は正常に実行されます。
HSE LifeCycleを変更するために属性設定を呼び出したときだけ、APIはエラーを返さないが、1秒後にプログラムが突然リセットされる。
HSEライフサイクルを進める前に、アドレスLC構成ワードを設定する必要がありますか？
HaiHoangSoftware_0-1751869464437.pngHaiHoangSoftware_0-1751869464437.pngLC構成ワードの値が0x00000000だった場合、どうなりますか？
こんにちは、
私はこれらのコマンドを同期モードで実行しました。
奇妙なことに、プログラム ADPK に属性を設定してデバッグ認証モードを設定すると、ECU は正常に実行されます。
HSE LifeCycleを変更するために属性設定を呼び出したときだけ、APIはエラーを返さないが、1秒後にプログラムが突然リセットされる。
HSEライフサイクルを進める前に、アドレスLC構成ワードを設定する必要がありますか？
LC構成ワードの値が0x00000000の場合はどうなりますか？
割り込みによる問題を回避するため、コマンドは同期的に実行することをお勧めします。
コマンドは関数 Hse_Ip_ServiceRequest によってトリガーされます。非同期方法には以下のシーケンスがあります:
Mu_Ip...機能はインライン化されているので問題ありません。しかし、BaseNXPモジュールのOsIf関数はインラインではないので、それらも移動する必要があります。
よろしくお願いいたします。
ルーカス
こんにちは、
これらのAPIは、ブロック1の0x0060FB3Eから配置されています。
それは処刑を行うのに十分安全な状態でしょうか？
ECUリセットを引き起こす理由は何かありますか？
さて、一つ抜けている文があります。UTESTフラッシュは、ライフサイクルが進む際にHSEによってプログラムされます。
このデバイスは自動的にリセットされることはありません。これはおそらく、書き込み中の読み取りエラーが原因です。フラッシュブロック間での読み取り同時書き込みがサポートされています。ただし、フラッシュブロック0とUTESTは同じパーティション内にあることに注意してください。
それは「表102」に示されています。「フラッシュブロック構成」とS32K3リファレンスマニュアルの「21.3 UTest NVMセクター」に記載されています。
また、「14.6.5」の項もHSE-Bファームウェアリファレンスマニュアルにある「HSEとアプリケーションコア間のフラッシュ読み書きアクセスの同期」は、さらなる開発に重要となる場合があります。
解決策は、RAMまたは別のフラッシュメモリからコードを実行することです。
よろしくお願いいたします。
ルーカス
こんにちは、
この問題を解決するために、属性設定APIの入力パラメータをグローバルな揮発性変数として配置しました。
しかし、ライフサイクルを変更するAPIを正常に実行した後、ECUは自動的にリセットされます。
変更ライフサイクルをUDSサービスとして実装する予定ですが、HSEファームウェアがECUを自動リセットすると実現できないようです。
交換サイクル後、ECUを正常に動作させるために何か特別な操作が必要ですか？
こんにちは、
NXPのデモアプリに倣って、Set_Attrサービスを使用してLCを進める機能を実装しました。これには3つのステップが含まれます。
- プログラムADKP
- デバッグ認証モードをパスワードに変更します
- Advance HSE LC
ステップ1,2は通常 Mu0 インスタンスと 1 つのフリーチャネルで実行されました。
ステップ3では常にFSR=0x0f600002とGSR=67030001が報告されます。
以下の手順は必要ですか？
- バックアップIVT
- アドレスLC構成ワード
LCを進めるために何か見落としていることはありますか？
HaiHoangSoftware_0-1751280488672.pngHaiHoangSoftware_0-1751280488672.pngこんにちは、 @HaiHoangSoftware さん
HSE_ERR_GENERALが発生する最も一般的な原因は、HSEサービスへのパラメータとして指定されたアドレスが無効であることです。それは、未実装メモリ空間を指す完全に無効なアドレスか、XRDC設定のためにHSEがそのメモリにアクセスできないか、あるいはメモリにマルチビットECCエラーがあるかのどちらかです。
データキャッシュが原因である可能性もあります。データキャッシュを無効にするか、HSEとの通信に使用されるすべてのメモリリソースをキャッシュ不可能なメモリに強制的に割り当てるようにしてください。
HSE_SRV_ID_GET_ATTR サービスの使用中にこのようなエラーが発生した場合は、pAttr アドレスを確認し、テスト目的でデータキャッシュを無効にしてください。
よろしくお願いいたします。
ルーカス