48ピンパッケージのMCXE316を使用したカスタム基板を開発中です。デバッガ（PE Micro）を接続した状態では、問題なくコードをダウンロードして実行できますが、MCUXpressoでデバッグセッション中にデバッガを接続しないと、プロセッサが動作していないようです。電源を入れ直すと基板が動作しなくなりますが、デバッガーを接続してデバッグセッションを開始すると基板は正常に動作します。私がテスト/検証した事項の一部：
1) Semihosting を有効にせずにプロジェクトをビルドし、Semihosting を無効にすると思われる Redlib の nohost -nf ライブラリを使用したことを確認しました。また、semihost_hardfault.c には、デバッガがない状態でハードフォルトを捕捉するコードが含まれているようです。
2) デバッガでリセットレジスタMC_RGM.FESとDESを確認したところ、電源投入リセットビットのみがアクティブになっています。デバッガを接続せずにPORを適用し（ハングアップ）、その後デバッガを物理的に接続して電源サイクルなしでデバッグセッションを開始しても、設定されているビットは電源投入のみです。
3) PTB13のボードにはLEDが1つ搭載されています。クロックなどの設定を変更することなく、無限ループでメイン関数の最初の操作としてLEDを点滅させるだけの、最もシンプルなLED点滅コードを作成しました。以下がテストコードです。
#include "fsl_siul2.h"
main( )
{
// PTB13を出力にする
SIUL2-> MSCR [45] = 0x200000;
（ １）
{
for ( volatile uint32_t s=0; s<100000; s++);
SIUL2_PortToggle(SIUL2, kSIUL2_PTB , 1u << 13U);
}
}
このコードはデバッガーが接続されているときは正常に動作しますが、スタンドアロンでは何も起こりません。SDK関数を使用して同じコードを作成してみましたが、結果は同じで、デバッガーセッションがアクティブな状態でのみ動作します。
コード内でSWTウォッチドッグを無効にしてみましたが、結果は同じでした。これはウォッチドッグリセットイベントではないと思います。
何かアイデアや、自分でできることはありますか？ありがとう！
こんにちは、セレステさん。
ご回答と確認事項をありがとうございます。デバッガーなしでは動作しないという問題が依然として発生しています。以下に、確認すべき個々の項目に対する回答を示します。
- オシロスコープを使用して電源投入時の RESET ピンを監視しましたが、POR リセット時には常に RESET ピンのレベルが +5V になります (つまり、リセット状態ではない）。部品が繰り返しリセットされるようなジャンプやその他の視覚的な現象は発生せず、ラインは論理ハイのままです。リセットラインを手動でローにしてから放すと（手動リセット）、信号はロジックハイになり、そのまま維持されます。
- 電源を維持したまま（確認済み）、手動でリセットラインをローにしてから放しましたが、それでも動作しません。これにより、電源投入速度に関する問題はすべて回避できると私は考えています。
- デバッガを接続せずにボードの電源を入れ（実行状態ではないが電源は供給されている）、その後デバッガケーブルを物理的に接続し（外部電源は中断なく供給されたまま）、デバッガでFESレジスタとDESレジスタを確認したところ、PORリセット理由のみが表示され、他の障害は発生していませんでした。PCはmain()エントリブレークポイントを指しています。デバッガはデバッグセッションの開始時にリセットを発行するため、コードはmainの開始時に実行され停止すると思われますが、ボードは電源を維持しているため、部品がハングアップした時点でDESとRESは元のPORから有効なままであるはずです。
- 私は時計の設定を一切行っていません。SDKプロジェクトによって提供されるリセット時のデフォルトの時計設定を使用しています。外部水晶発振器とPLLを使用するようにコードでクロックを設定しようと試みましたが、デバッガ上では正常に動作し、デバッガ上でも高いPLLクロックが問題なく取得できました。しかし、デバッガがないと、その部品は完全に動作しなくなります。コードに**ピー**を設定しても、起動時に内部クロックソースをデフォルトで使用するようにしても、状況は変わりません。
私が測定した限りでは、電源の立ち上がり時間は仕様の範囲内です。違いがあるかどうかを確認するために、外部電源を使って基板を起動してみます。しかし、いったん部品に電源が投入されると、その後外部リセットによって起動されるはずです。チップがハードラッチアップされた場合、基板への電源供給を維持してデバッガを再接続してもロック状態のままになりますが、デバッガは常に動作します。
他に確認や検証が必要な場合はお知らせください。アイデアが尽きてきた。ありがとう
こんにちは、 @brucebowling さん、
- プログラムカウンタ (PC)
- MC_RGM.FES および MC_RGM.DES レジスタ
これは、デバイスがフリーズしているのか、繰り返しリセットされているのかを特定するのに役立ちます。
プロジェクトで外部クロックソースまたはPLLを設定する場合：
コアクロックだけでなく、すべてのクロックドメインが正しく設定されていることを確認してください。
例えば、一部の派生クロック（HSEやその他のシステムクロックなど）は、コアクロックとの特定の関係に従う必要があります。
クロック設定が正しくないと、デバッグが正常に動作しているように見えても、起動初期段階で予期しないリセットや実行エラーが発生する可能性があります。
3. 電源の立ち上がり速度を確認する
詳細については、以下のスクリーンショットをご参照ください。
お役に立てば幸いです。
BR
セレステ
こんにちは、 @brucebowling さん、
ご回答ありがとうございます。以下のチェック項目を順番に実施してください。
1. フラッシュベースに有効なIVTが存在するかどうかを確認します。
- 読み取りアドレス
0x0040_0000、期待値:0x5AA5_5AA5 - チェック
0x0040_0004（ブート構成ワード）：CM7_0_ENABLEが1に設定されていることを確認します。 0x0040_000Cに有効なCM7_0アプリケーションエントリアドレスが含まれていることを確認します。
2. プロジェクト／リンカースクリプト／プログラミング方法が有効なMCXE31ブートイメージを生成することを確認する。
- 標準のELFまたはベクターテーブルのみをプログラミングしていないことを確認してください。
- 画像には、Secure BAF が認識できる IVT が含まれている必要があります。
- IVTは、MCXE316でサポートされているIVTアドレスのいずれかに配置する必要があります。
3. リセット後、できるだけ早くPOR関連のステータスを取得する
- PMC.LVSC: PORF / LVR フラグを確認する
- DCMの読み取り専用レジスタ：POR_WDG_ENとPOR_WDOG_TRIMを確認してください。
4. 真の独立したアプリケーション入力を確認するための最小限の実験を実施する
- LEDの点滅だけに頼るのは避けましょう。
- 代わりに、ResetISRまたは起動コードのごく初期段階で、予約済みのRAMフラグまたは専用のGPIO状態を設定します。
- 次に、デバッガのリセットをトリガーせずにアタッチモードを使用してステータスを読み取ります。これにより、デバッガによって引き起こされるリセットによる干渉を排除できます。
よろしくお願いいたします。
セレステ
はい、ご回答で説明いただいた手順を開始したところ、すぐに問題が発生しました。0x0040_0000番地のメモリをチェックしたところ、0xFFFFFFFFという値が得られ、それ以降のアドレスの内容もすべて同じ値でした。つまり、これらの領域はSDKのデフォルトプロジェクトによってプログラミングされていなかったということだ。
画像ベクトル表（31.5節）については、リファレンスマニュアルを確認してください。IVTにプログラムする必要があるマジックナンバーなどに関するセクションを確認しました。MCXE316デバイスのデフォルトのプロジェクト設定にはこのセクションの初期化が含まれているものと想定していましたが、それに関する記述は見当たりませんでした。
FRDM MCXE31Bボード（MCXE316の上位チップ）のLED_Blinkyなどのデモアプリケーションは、予想通り、デバッガーを接続しなくてもプログラムを正しく実行できることに気づきました。そして、LED_BlinkyをFRDM-MCXE31Bボードにロードした後、メモリアドレス位置0x0040_0000を確認したところ、期待どおり0x5AA5_5AA5でした。つまり、このプロジェクトには、私がMCXE316版で使用していたデフォルトのSDKプロジェクトに欠けていた設定が含まれているということですね。
LED_Blinkyのプロジェクトを少し調べてみると、「boot_header」フォルダの中に「boot_header.c」と「boot_header.h」というファイルがあることがわかります。boot_header.c を見てみるとソースによると、これはプロジェクトがIVTのマジックナンバーやその他の項目を初期化する場所のようです。ソースと.hファイルをコピーしましたLED_Blinkyプロジェクトのファイルを私のSDKプロジェクトにコピーします。コードをビルドに含めるためには、#define BOOT_HEADER_ENABLE 1U を設定する必要もありました。
これはうまくいった！私のカスタムテストボードでは、デバッガーハードウェアなしでもアプリケーションは正常に動作し続けています。どうやらこのファイルは、テスト2のセクションであなたが以前尋ねていたことを実行するようです。
NXPはMCXE316デバイス向けの次期SDKリリースにこれを含める必要がある。さもなければ、他のユーザーも同様の問題に直面するだろう。
この件についてご協力いただき、ありがとうございました！