iMXRT1011 プロセッサをベースにしたシンプルなカスタム ボードを持っています。MCUXpresso IDE v24.12とSegger J-Link Ultra+を使用しています。iMXRT開発全般の経験があり、別のプロジェクトではJ-Linkが問題なく動作しました。
すべて順調に始まりましたが、ある時点でプロジェクトをデバッグできなくなりました。シリアル ブート ローダー (Secure Provisioning ツール経由) を使用してインストールするとコードは正常に実行されますが、デバッガーからフラッシュすると実行されません。
main() の前のどこかでクラッシュしているようです。ResetISR() にブレークポイントを設定してステップ実行できる場合もあります。このような場合、シングルステップ実行を続けると問題なく動作しますが、そのまま実行するとクラッシュします。場合によっては、0xdeadbeee に直接遷移してしまい、デバッガーで対処できないこともあります。
ご想像のとおり、これは非常にイライラする事態です。ご提案があれば、ぜひお聞かせください。
今朝さらに奇妙な行動に気づきました。
SystemInitHook() の呼び出し前にブレークポイントを設定しました。添付画像でその関数の逆アセンブリをCAN確認できます。
呼び出し前、SP は 0x20207ff8 にありますが、これはコードを実行すると予想される値です。SystemInitHook()の呼び出しは
bl 0x6001220c
C言語でこの関数にステップインすると、デバッガーは0x60012210で停止しますが、SPは0x20207ff8のままです。関数が戻るときもSPは0x20207ff8で、これは予想通りです。
代わりに命令ステップ モードで関数にステップインすると、0x6001220c の push 命令が実行され、SP が 0x20207ff4 に減ります。SO、関数が終了し、後続のコードがクラッシュすると、SP が間違ってしまいます。
この動作の違いの原因は何だと思いますか?そして、SystemInitHook() は正しいですか?押すと音はするが、弾けない？
アプリケーションを SEC でフラッシュすると、正常に実行されます。J-Linkコマンダーで接続すると正常に停止・起動CAN。
IDEsでは、 ResetISR()にブレークポイントを設定できます。SystemInit()をステップオーバーするとクラッシュします。SystemInit()にステップインし、関数をステップ実行してからSystemInitHook()をステップオーバーするとクラッシュします。同じようにSystemInitHook()にステップインするとクラッシュしません。デバッガーがコード内をステップオーバーしているかステップインしているかによって動作が異なるというのは、まさにこのためです。
SO、0x0 にジャンプしているように見えますが、これはコードが自由に実行されているときのみであり、デバッガーでステップ実行しているときではありません。0x0 にはコードがありません - ITC は使用されていません。
繰り返しますが、これは main() の前、つまり RTOS などが呼び出されるずっと前です。初期起動コードでクラッシュします。
こんにちは、 @expertsleepers
ご説明ありがとうございます！
先ほども触れましたが、 0xdeadbeee に直接遷移し、デバッガーで何もCANない場合もあります。
私の理解が正しければ、このデッドビー問題はデバッガーでのみ発生し、デバッガーなしで最新のソフトウェアを起動すると正常に動作するのでしょうか?
IDE を別にして、Segger の J-Link コマンダーを使用して最新のアプリをデバッグすると、何か問題が発生しますか?go の使用を参照し、デバッガーがコネクテッドされると操作を停止します。
最新の SW バージョンの変更点についてアイデアをお聞かせいただけますか?プログラム カウンターを監視しながら、ステップ バイ ステップのデバッグを実行し、SRAM をヒープします。RTOS を使用しているかどうかはわかりません。フラッシュから SRAM へ、またはその逆など、無効なアドレスへのジャンプがないか確認します。
よろしくお願いします、
ディエゴ
>プロジェクトの前の段階にコミットすると、デバッグがよりうまく機能し始めるということですか?
はい。ただし、古いバージョンに戻した後は、デバッグが再び信頼できるものになる前に、Secure Provisioning ツールを使用してボードを 1 回フラッシュする必要があります。それ以降は、通常どおり IDE からフラッシュできます。
その後、最新のコードに戻ると、一度は正常にデバッグCANますが、その後の試行は失敗します。
>プロジェクトを他のワークスペースまたは PC にインポートしても、この問題は繰り返されますか?
以前にインストールしたことのない新規マシンに IDEs v25.6 をインストールし、プロジェクトをコピーしてビルドし、デバッグを試みましたが、結果は同じでした。
こんにちは、 @expertsleepers
ご辛抱いただき、さらに情報を提供していただきありがとうございます。
プロジェクトの前の段階にコミットし直すと、デバッグがよりうまく機能し始めるということですか?
この問題を自分の側で再現するにはどうすればいいのでしょうか。プロジェクトを他のワークスペースまたは PC にインポートしても、この問題は繰り返されますか?
ではごきげんよう、
ディエゴ
おそらく、プロジェクトが特定のサイズに達するまではすべて正常に動作し、デバッガーで問題なく実行されたことを明確に説明していなかったのでしょう。デバッガーが突然失敗し始めるまで、私はこれに数日間とても楽しく取り組んでいました。
IDE 自体は他のプロジェクトでは引き続き正常に動作する。IDEs 自体については心配していません。
こんにちは、 @expertsleepers
ご説明ありがとうございます。はい、私はそれらのファイルを FCB と呼んでいました。
問題が現在のアプリケーション設定にある場合はどうなりますか?この問題がフラッシュ設定、アプリケーション設定、または IDEs のいずれにあるのかを区別したいと思います。
hello world デモを実行しようとすると、結果はどうなりますか?すでに動作している同じ FCB を使用します。
プロジェクトについてさらに詳しく教えていただけますか?
よろしくお願いします、
ディエゴ
フラッシュの設定には添付ファイルを使用しています。これらは SDK の例からコピーされたものであり、作業中のプロジェクト上のファイルと同一であることを確認しました。
フラッシュ IC は両方のボードで同じで、Winbond W25Q64JVXGIQ です。
これらのファイルはあなたが言及している「FCB」を定義していますか?
こんにちは、 @expertsleepers
お問い合わせいただきありがとうございます！
おそらくそれは IDEs 側の FCB です。それを確認しましたか?説明させてください。
SEC ツールを使用する場合、SEC ツールはイメージを書き込むのではなく、「最小限の」 FCB を書き込みます。IDEs を使用する場合、イメージには FCB (私の記憶では qspi_config) が含まれます。FCB/qspi_config がイメージと一致していることを確認しましたか?
よろしくお願いします、
ディエゴ
カスタム ボードの問題を排除するために、MIMXRT1010 EVK を入手しました。EVK ボードでも動作は同じです。
こんにちは@expertsleepers 、
コードを変更した後に問題が発生したと理解しています。より適切にサポートするために、元のプロジェクトと比較して適用した具体的な変更点を共有していただけますか?
特に、次のようなブート プロセスに関連する変更に興味があります。
FCB のアップデート。
メモリ領域の調整。
XIP モードと非 XIP モードをスイッチしたかどうか。
BR
ハビブ
FCB は変更せず、常に XIP を使用してきました。
メモリ領域を変更しました。ResetISR()でこれを実行します
#定義 IOMUXC_GPR_GPR16 (*(符号なし整数*)0x400AC040)
#定義 IOMUXC_GPR_GPR17 (*(符号なし整数*)0x400AC044)
void ResetISR(void) {
// 割り込みを無効にする
__asm volatile ("cpsid i");
__アセンブリ volatile ("MSR MSP、%0" : : "r" (&_vStackTop) : );
// フレックスラムを再構成する
IOMUXC_GPR_GPR17 = 0xE9;
IOMUXC_GPR_GPR16 = IOMUXC_GPR_GPR16 | 0x4;
こんにちは、 @expertsleepersさん、
BR
ハビブ
私のプロジェクトでは、両方のプリプロセッサ シンボルが 1 に設定されています。
こんにちは、 @expertsleepersさん、
アプリケーションをデバッグする前に、シリアル ダウンローダー構成を使用して MCUXpresso 経由で一括消去を実行できますか?
これは、フラッシュされたアプリケーションがデバッガーと MCU 間の通信を妨害していないことを確認するためです。
BR
ハビブ
アプリノートについては承知しております。私の投稿からわかるように、アプリケーション ノートで推奨されているように、リセット ハンドラーの開始時に FlexRAM 構成を変更しています。私の他のプロジェクトもまったく同じことを行っていますが、1年以上問題なく動作しています。
その間に、私は FlexRAM を再割り当てする命令を削除することで、自分自身をブロック解除しました (上記の投稿で言及しました)。
FlexRAM をデフォルトの割り当てのままにしておけば、問題なくデバッグできます。
FlexRAM の再割り当て方法に何か問題がありますか?別のプロジェクトでもまったく同じ方法で実行していますが、常に問題なく動作しています。
こんにちは、 @expertsleepersさん、
問題は、実行中に FlexRAM 構成が操作され、予期しないエラーが発生する可能性があることです。したがって、FlexRAM を正しく使用するには、i.MX RT で FlexRAM を使用する方法を説明したこのアプリケーション ノートを確認することを強くお勧めします。
一方、他のプロジェクトでは FlexRAM を使用していない可能性があり、正しく構成されている場合は、問題は発生しません。
最後に、問題の解決に役立つ可能性のある次のコミュニティ投稿を確認することをお勧めします。
MCUXpresso IDEを使用したコードとデータの再配置 - NXPコミュニティ
デバッガー接続問題に対するRTボードのリカバリ - NXPコミュニティ
BR
ハビブ
こんにちは、 @expertsleepersさん、
私が提供したアプリケーション ノートに基づいて IOMUXC_GPR_GPR17 の構成を確認すると、次の構成になっていることがわかります。
ただし、次の点に注意してください。
アプリケーションの要件に適合し、ノートの条件に準拠する別の構成を試していただけますか?
BR
ハビブ
それを試してみます。
しかし、ROM 要件がなぜ関係するのかを説明していただけますか?FlexRAM を変更するときにアプリケーションがすでに実行されているので、その時点ではどの ROM コードが実行されるのでしょうか?
ヒューズ内の FlexRAM が変更された場合、これがブートローダーに影響することは理解できます。しかし、私はヒューズを変更しているのではなく、ソフトウェアで FlexRAM を変更しているのです。
こんにちは、 @expertsleepersさん、
そのメモを考慮して、問題が解決するかどうか確認していただけますか?
一方、SDK（バージョン 25.06）には、「flex_ram_access」と呼ばれる FlexRAM を構成する例が用意されており、この例を分析してその動作を理解し、コードで再現することを強くお勧めします。
さらに、第2.1.1.2章に記載されている要件が満たされていることを確認してください。私が提供したアプリケーションノートの「ランタイム構成」という要件は満たされていますか?
BR
ハビブ