添付されたCMMファイルは、FBLとアプリをS32K312 MCUに書き込み、その後SecureBoot、SecureDebug、Configuration Lockを起動するスクリプトです。
このCMMの実行時に発生するHardFaultの問題について、見直しと改善をお願いしたいと思います。
以前のスクリーンショットに示すように、JTAGクロックを5MHzに設定した状態で「Go」を実行した際に、FBLとアプリをインポートした後にハードフォルトが発生しました。
変更点として、アプリファイルをインポートした後、SYStem.JtagClockを1MHzに設定しました。この変更により、CMM実行時に「Go」ステップでハードフォールトが発生することは稀になったため、JTAGクロック速度を下げることが効果的な方法であると結論づけました。しかし、修正されたCMMを適用すると、FBLとアプリがインポートされた後、「Go」の段階で「stopped by vectbl」エラーが時折発生します。
CMM全体が安定して動作できるように見直し、また「vectblによって停止」エラーが全く出ないよう改善方法についてご質問いただきたいと思います。
オリジナルCMM：GN7_PE_MAIN_G_SECURE_260412.cmm
変更されたCMM（JTAGクロックを1MHzに変更）：GN7_PE_MAIN_G_SECURE_260412_0714RE.cmm
さらに、SecureBootを有効にした後で、別のFBLをインポートしたいと考えています。SecureBootが有効になっている状態で、別のFBLをインポートする方法はありますか？可能であれば、ガイドをご提供していただけるとありがたいです。
こんにちは、 @jeongwoo
私が思う主な問題はこうです:
つまり、ピンク色のファイルをロードして、デバイスをリセットするということです。このリセット後、SBAFはHSEファームウェアをインストールするはずです。しかし重要な点は、この操作は約1秒で完了するということです。しかし、0.1秒後にMCUをリセットすると、すぐにfblでピンクファイルを0x40_0000で再プログラムします。待ち時間を少なくとも1.3秒に増やしてください。そうしないと、SBAFがHSE FWをインストールしようとし、同時にfblの再プログラミングも試みることになります。
よろしくお願いいたします。
ルーカス
こんにちは、ご返信ありがとうございます。
HSEを追加してから遅延時間が0.1秒に設定されている部分については、時間が短く設定されてもコントローラに書き込まれるプログラム機能に問題はありません。遅延時間を1秒に延長することが本当に必要なのかどうかをお伺いしたいです。
HSEファームウェアがまだインストールされていないデバイスでテストしましたか？これはうまくいかないと思います。インストールには1秒強しかかかりません。0.1秒後にリセットしてインストールをカットし、その直後にピンクファイルを消去すると、SBAFはファームウェアをインストールできません。
こんにちは、
まず、既存の0.1秒設定でCMMを構成して書き込みを行った場合、Trace32にハードフォルトが発生するものの、ファームウェアの機能には影響がないことを確認しました。FBLとAPPは正常に実行されたようです。
SBAFやHSEが正常に動作しているかを確認するために使えるレジスタアドレス値はありますか?
さらに、あなたが言及したHSE申請期間を考慮したCMMについてですが、「vectblで停止」は実行時に表示されませんでした。しかし、APP Import 中に FLASH.ReProgram ALL の後に「wait 3s」を「wait 2s」に変更しても、「stopped by vectbl」がまだ表示されることを確認しました。APPインポートの時間を短縮することも影響を与えるでしょうか?
こんにちは、 @jeongwoo
スクリプトに潜在的な問題点を見つけたかもしれません。
fbl_m4をロードした後、Goコマンドを使用してブートローダーを起動します。スクリプトはその後ループに入り、定期的にブート構成ワードを読み取り、値0x9を待ちます。これは、スクリプトがブートローダーがセキュアブートを初期化し、ブート構成ワードのBOOT_SEQビットを更新するのを待っていることを意味します。しかし、この更新を実行するにはブートローダーがフラッシュセクター全体を消去・再プログラムする必要があり、かなりの時間がかかることがあります。
その期間中、デバッガは同じフラッシュメモリの位置を繰り返し読み取ります。これは、読み取り同時書き込みの競合を引き起こす可能性があります。フラッシュブロックが消去またはプログラムされている間は、通常同時に読み取ることはできません。その結果、デバッガはアクセスエラーに遭遇し、観察された挙動の説明がつくかもしれません。
よりスマートな解決策としては、フラッシュメモリに保存された値をポーリングする代わりに、RAMに格納されたステータス変数を使用することです。ブートローダーがすべてのセキュアブート設定ステップを完了したら、専用のRAM変数を更新できます。デバッガは定期的にこのRAM位置を読み取ることができました。RAMアクセスはフラッシュ消去やプログラム操作に干渉しないため、この方法は書き込み時の読み込み問題を回避します。
また、同じ方法がスクリプト全体で何度も使われているのに気づいたので、この特定のものだけでなく、すべての類似したステータスチェックを見直して更新することをおすすめします。
HSE（環境・安全・衛生）の状況に関して：
HSEファームウェアがインストールされているかどうかを確認するには、アドレス0x4039C028にあるHSE GPRレジスタのビット0を確認してください。このビットが1の場合、HSEファームウェアが存在します。
HSEファームウェアの初期化が完了し、要求を受け付ける準備が整っているかどうかを確認するには、MU0 FSRレジスタのHSE_STATUS_INIT_OKフラグ（ビット24）を確認します。このビットが設定されると、HSEの初期化が完了し、サービスが利用可能になります。
こんにちは、ルーカスさん。
ご返信よろしくお願いします。
私の理解では、ブートローダーが初期値(0x1)で一度アップロードされた後、再度消去・書き込みサイクルを行い、セキュアブート(0x1 → 0x9の変更)を適用します。この過程でポーリングメソッドがそのアドレス値を読み取ろうとした際にエラーが発生したようです。
ご指摘いただいたとおり、RAMに格納されているステータス変数を使用してみました。ただし、私たちはソフトウェアを16進形ファイルとして配布しています。この場合、.mapで定義されたアドレスを使うとファイル、RAMアドレスはプログラムごとに異なるため、書き込みスクリプトを統一することが困難です。その結果、スクリプト内でセキュアブート、セキュアデバッグ、および構成ロックの状態を確認するには、IVTで定義されている値を使用する必要があるという結論に至りました。
したがって、ご意見をもとに、HSEアップロード後に1.5秒の遅延を適用する代わりに、MU0 FSRレジスタのHSE_STATUS_INIT_OKフラグ(ビット24)をチェックする方法を適用しました。既存の固定待ち時間(例:1.5秒待機、3秒待機)を廃止し、リセット後はフラッシュ書き込み(FBL/APP読み込み)を進めるまでポーリングを行うスクリプトを修正しました。この方法はシステムリセットとSys.UPの後のすべての段階に追加しました。さらに、各ステータスの状態確認のためのポーリング間隔を0.5秒から1.5秒に変更する予定です。また、Go命令後の最初の読み取りの前に待機時間を追加しました。これらのタイミング設定が不十分かどうかについて、ご意見をいただければ幸いです。これまでのところ、このスクリプトでの書き込みは異常なく正常に完了し、書き込み後にGOを実行するとデバイスが正しく動作していることを確認しています。
（アドレス0x400004の値が0x1から0x9に変化するのにかかる時間は約800msであることを確認しました。）
以前ご指摘いただいた、HSEのアップロードから0.1秒後にFBLをロードした際にハードフォルトが発生した件について：ご指摘いただいたHSEステータス値を確認したところ、すべて正常と報告されていることを確認いたしました。プログラムの機能も正しく実行されているようです。このエラー（HardFault）は、HSE → FBL → APP を経由してすべてをロードし、GO を実行したときに発生します。この状況を踏まえ、ご提案の通り、GOを執筆後に実行するために遅延時間を延ばすのが望ましいかどうか、ご意見をいただけるとありがたいです。
よろしくお願いいたします。
はい、sys.up の実行後、他のプログラミング操作を開始する前に HSE_STATUS_INIT_OK を待つのは良い方法です。これにより、HSEとアプリケーションコア/プログラミングツール間で読み書きの競合がなくなります。
BOOT_SEQビットのチェックに使われるタイムアウトがプログラミング操作がすでに完了しているのに十分な長さであれば、この方法も有効です。しかし、RAMにフラグを使用する方がより簡潔な解決策となるだろう。
万能的な解決策が必要な場合、共通セクションに標準的なグローバル変数を配置するのは理想的ではありません。なぜなら、そのアドレスが異なるアプリケーション間で一定であることが保証されていないからです。代わりに、固定アドレスに専用RAMセクションを定義し、そこにフラグを配置するか、未使用のRAMを固定アドレスに予約してポインタから直接アクセスする方法があります。
どちらのアプローチも、アプリケーションのメモリレイアウトとは独立して共有可能な安定した場所を提供します。
よろしくお願いいたします。
ルーカス
こんにちは、ルーカス。
以前ご提供いただいたガイダンスに従って、イメージファイル（.elf）はvectblによって停止されることなく正常に実行されるようになりました（「実行中」）。しかし、アプリをアップロードした後、GOを実行すると、バイナリファイル（.hex）で依然として「stopped by vectbl」エラーが発生します。
これは、「アプリが実行フロー内で無効なアドレスにジャンプし、その場所にある命令を取得しようとした際に失敗する」という症状のようです。この問題を解決する方法はありますか？
vectblエラーが発生しても、通常の書き込みはPOR(Power-On Reset)時に元々意図した通り正しく完了しているように見えますが、このエラーが安全に無視できるものかどうか確認する必要があります。
引き続きご支援いただきありがとうございます。
よろしくお願いいたします。
