APPがブートローダにジャンプするときにIOを高レベルに保つ必要があるため、ソフトウェアリセットによってブートローダに入ることは現実的ではありません。
ブートローダーからAPPを初めて入力するのは正常です.ブートローダーに入る前にPIT、SPIなどのすべての周辺機器を初期化解除し、ブートローダーは再度APPに入ります。MCUがブートローダーからAPPを2回目に入力すると、初期化時にスタックします。IDEが提供するライブラリ関数を使用しました。これらの写真は、私が問題を見つける方法を示しています。
1.ここで立ち往生しているのを見つけます。
2.次に、写真1の機能でここに貼り付けます
3.次に、写真2の機能でここに立ち往生しました
4.次に、写真3の機能でここに立ち往生します
5.そしてついにここを見つけました。サイクルはタイムアウトまでレジスタステータスを待っているようです。
6.次に、このレジスタのアドレスを確認し、サイクルが何のためにあるのかを調べました。
しかし、なぜこのビットが「モード遷移が進行中です」で止まっているのかわかりません。また、図5のTIMEOUT値を小さくしようとしましたが、プロジェクトはPITまたはSPI、またはその他の周辺機器の初期化でスタックします。
アプリケーション(APP)からブートローダへの移行中にIOを高レベルに保つという要件に対処する場合、ペリフェラルの状態と初期化シーケンスを慎重に管理することが重要です。ブートローダーからAPPへの2回目のエントリ中にMCUがスタックする問題に対処するためのいくつかの手順と考慮事項を次に示します。
ペリフェラルの初期化解除:
メモリとスタックの管理:
ブートローダとアプリケーションの分離:
ハードウェアの初期化:
デバッグ:
ライブラリ関数:
詳細なトラブルシューティングについては、同様の問題に関するコミュニティのディスカッションを参照してください。たとえば、NXPコミュニティのユーザーは、ブートローダーからAPPを2回目に入力するときに、初期化中にMCUがスタックするという同様の問題に直面しました(ソース)。
ペリフェラルの状態、メモリ、初期化シーケンスを慎重に管理することで、IO を高レベルに保つ必要がある場合でも、ブートローダーとアプリケーション間のスムーズな移行を確保できます。
Hello,
OK、つまり、CANやPWMなどのクロックをソースしているペリフェラルがまだアクティブであると思います。
それらに対するゲートクロックは、通常、周辺機器は制御レジスタのフリーズビットに似ているので、
よろしくお願いいたします。
ピーター
Hi
おっしゃる通り、やってみました。モード遷移を要求する前にMC_RUN_PC_n、MC_LP_PC_n、およびME_PCTL_nをリセットしましたが、モード遷移がまだスタックしています。
下の図のようにMC_ME_DMTSと呼ばれるレジスタは、現在どのような状態にあるかを確認できます。値は、スタックが発生した場合の画像です。しかし、立ち往生の原因をどのように見つけるかは私には明らかではありません。分析を手伝ってもらえますか?
Hello,
PLLによって供給されるいくつかの周辺がアクティブであるため、モード遷移が停止します。
IRCクロックにモードを移行してから、アプリケーション設定に切り替えてみてください。
モード遷移を要求するときは、すべての周辺機器がアプリケーションのクロックによってクロックされていないことを確認してください。
よろしくお願いいたします。
ピーター