こんにちは、 @Mohamadabdelmoteleb
HSEファームウェアリファレンスマニュアル改訂版の表99。2.7は、すべての属性の型を示しています。
上記で挙げた属性はすべてOTP-ATTRです。
つまり、属性はUTESTのメモリに保存されるということです。しかし、UTESTのメモリはフラッシュブロック0と同じ読み出しパーティションにあります。つまり、UTESTのプログラミング中はフラッシュブロック0にアクセスすることはできません。おそらく、あなたのコードはフラッシュメモリのブロック0から実行されているのでしょう？
解決策は、(HSE hseSetAttrSrv_t サービスをトリガーする) コードを RAM または別のフラッシュブロックから実行することです。これは、前述のマニュアルの「14.6.5」の項に記載されています。「HSEとアプリケーションコア間のフラッシュ読み取り/書き込みアクセスの同期」、表151。
よろしくお願いいたします。
ルーカス
こんにちは、 @lukaszadrapa さん、
ご説明いただきありがとうございます。
現在、hseSetAttrSrv_t リクエストを呼び出すために Hse_Ip_ServiceRequest を使用しています。皆様からのフィードバックとセクション14.6.5（表151）の要件に基づき、標準的な実装方法を確認したいと思います。
Hse_Ipドライバの使用：これらのOTP属性サービスに対して、標準のRTD Hse_Ipドライバ（Hse_Ip_ServiceRequest）を引き続き使用するのが標準的な方法でしょうか？ドライバは通常、デフォルトでフラッシュメモリ（CRYPTO_43_HSE_SEC_CODE）にリンクされているため、このセクションCRYPTO_43_HSE_SEC_CODEをSRAMまたは別のフラッシュブロックに手動で移動するのが標準的な方法なのでしょうか？
再配置戦略：RAMの再配置が標準的な方法である場合、Hse_Ip_ServiceRequest呼び出しチェーンと同期ループのみをSRAMに再配置するだけで十分でしょうか、それとも予期しない割り込み中にブロック0からのフェッチを防ぐために、割り込みベクタテーブル全体もRAMに移動する必要がありますか？
同期方法：表151の同期要件を満たすために、HSE GPRレジスタ3（0x4039C028）のビット24と25をポーリングして、フラッシュメモリからの実行再開が安全かどうかを判断するのが標準的な方法でしょうか？
シングルブロックハードウェア：フラッシュブロックが1つしかないS32K3バリアント（「別のフラッシュブロック」がオプションでない場合）では、SRAM実行がOTP属性を設定する標準的な方法ですか？