こんにちは、 @HQZ
パッシブパーティションに有効なイメージが存在することを確認しましたか?電源投入後にリセットせずに実行中のターゲットにデバッガーを接続すると、どのような現象が観察されますか?デバイスはJTAGリカバリーモードに入りましたか?あるいは、デバッガでデバイスをリセットしてから、アプリケーションのエントリーポイントに到達したかを確認することもできます。
デバイスがアドレス0x2040012Cで無限ループに陥っている場合、JTAGリカバリモードに入ったことを示しています。これはIVTの設定やIVTの整合性に問題がある可能性もあります。
また、パッシブパーティション内のイメージは、アクティブパーティションのアドレス空間(つまり、0x00400000から始まるアドレス空間)から実行されるようにリンクされていますか?
最後に、セキュアブートを使用していますか?
よろしくお願いいたします。
ルーカス
こんにちは@lukaszadrapa
プラットフォーム:S32K344、AB-Swapアーキテクチャ。独立したファームウェアイメージはアクティブブロックとパッシブブロックに別々に保存されます。HSEのセキュアブートは無効になっています。問題の説明:アクティブ/パッシブパーティションスイッチを完了するためにHSE_ActivatePassiveBlock()を呼んだ後、電源を入れ直してリセットした後、デバイスはターゲットファームウェアを自動で起動できません。しかし、J-Linkデバッガがチップにコネクテッドされていて、デバッガソフトウェア内で「アプリケーション開始」をクリックすると、交換したファームウェアは通常通り動作します。追加の背景:ファームウェアはパーティションAとパーティションBの両方に存在します。両画像の違いはLEDの点滅周波数だけです。パーティションAのファームウェアは0x400000からリンクされ、パーティションBのファームウェアは0x600000からリンクされています。HSE_ActivatePassiveBlock()を呼び出してリセットした後、J-Linkでフラッシュの内容をダンプしました。パーティションAとパーティションBの内容が物理的に入れ替わっており、HSE_ActivatePassiveBlock()が有効であることが確認されています。質問:1. この行動の根本原因は何でしょうか?なぜコールド電源起動はデバッガーでトリガーされる「アプリケーションの開始」と異なる挙動をするのでしょうか?2. ABパーティションスワップ後の自動起動失敗を解決できる現実的な解決策は何ですか?ご支援ありがとうございます。
[[ ## completed ##]]
こんにちは、 @HQZ
「パーティション B のファームウェアが 0x600000 からリンクされている」 - これが問題です。アクティブなパーティションアドレス(0x400000)を使用するには、両方のイメージがリンクされている必要があります。アプリケーションは常にアクティブパーティションから動作しており、パッシブパーティションからではありません。
解決策:両方のプロジェクトで同じリンカーファイルを使用する。
これはデバッガと連携して動作します。なぜなら、デバッガはプログラムカウンタをELFファイル内のエントリポイントアドレスに「手動で」設定するからです。
よろしくお願いいたします。
ルーカス
こんにちは、 @lukaszadrapa
以前の提案に従ってABパーティションのスワップを試してみましたが、問題は依然として解決していません。
使用されているHSEファームウェアのバージョンはs32k344_hse_fw_1.5.0_2.40です。
ABスワップ検証のためのテスト設定:
アプリケーションベースの自己更新機能を備えた単一のリンカースクリプト。アプリケーションは新しいファームウェアイメージをパッシブパーティションにプログラムする責任を負います。
リンカースクリプト: リンカースクリプトは1つだけ使用され、ファームウェアの開始アドレスは常に0x00400000に設定されます。
ワークフロー:
1.パーティションA(論理アドレス0x00400000)で動作するアプリケーションは、CANを通じて新しいファームウェアを受け取ります。パーティションAとパーティションBのファームウェアの唯一の違いは、LEDの点滅頻度です。
2. アプリケーションは新しいファームウェアをパッシブパーティション(0x00600000)の物理アドレスに直接プログラムします。
3.プログラミングが完了すると、HSE_ActivatePassiveBlock() サービスが呼び出されます。
4.その後、チップがリセットされます。
観察:
ファームウェアがリセット後に起動しない。しかし、J-Linkが接続され、デバッガから「アプリケーション開始」がトリガーされると、パーティションBのファームウェアは正しく動作します。
パーティションスワップの失敗を引き起こす他の根本原因や、対応する解決策は何でしょうか?
よろしくお願いいたします
返信が遅くなり申し訳ありません。
以下に、よくある問題点をいくつか挙げます。
HSE_ActivatePassiveBlock() を実行してデバイスをリセットすると、HSE が新しいサービス要求を受け入れる準備が整うまでに約 1 秒かかります。それは、HSEがHSEファームウェアのバックアップをパッシブパーティションに保存するためです。操作が完了すると、FSRレジスタのHSE_STATUS_INIT_OKフラグが設定されます。そのため、HSEが完成するまでは利用できません。時として、これがトラブルの原因となる。
これはファームウェアバージョン0.2.55.0以降で最適化されており、ファームウェアは更新された場合にのみパッシブパーティションにコピーされます。もし状況が変わらなければ、HSEはこの作業を省略し、交換作業ははるかに迅速に行われます。
それならHSEファームウェアのリファレンスマニュアルの説明を読むことをお勧めします。2.7節:
「14.6.5HSEとアプリケーションコア間のフラッシュ読み書きアクセスの同期」:
https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7
表149、150、151には典型的なシナリオの詳細が記載されています。
あなたの場合、HSEがパッシブパーティションにバックアップを取ると、HSEがそのブロックに対してフラッシュ操作を行うため、フラッシュブロック3にアクセスできません。
また、ブロック1ではHSEファームウェアがこのブロックから動作しているため、フラッシュ操作はできません。
もう一つ注意すべき点は、HSEが実行されている場合、HSE_CLKを変更できないということです。リセット後約1秒でHSEが稼働している場合、これは交換後に問題になることがあります。
HSE_CLOCKを変更する際は、HSEがアイドル状態である必要があります。HSEの実行中は時計を変更できません。これが予測不能な行動につながることがあります。これはS32K3リファレンスマニュアルに明確に記載されています。
「HSE_CLKを設定する前に、HSE CPUのコアステータスレジスタ(PRTN0_CORE2_STAT)を読み取って、SBAFがWFI状態に入るまで待つ必要があります。」
これは古いバージョンのRTDドライバを使う場合に問題になる可能性があり、ドライバがステータスレジスタを確認しなかったためです。
このチェック機能は、RTDバージョン5.0.0以降で実装されました。古いバージョンの場合は、クロック初期化前にWFIをポーリングするのはユーザーが行います。ですから、これが失敗の原因かもしれません。
こんにちは、兄弟
私も同じ問題に遭遇しました。どうやって解決したのか教えていただけますか?