こんにちは、
これは、以前に提起された質問に対するフォローアップです。リンクは前回の問い合わせに添付されており、そのリンクには要求された必要な詳細情報が含まれています。ご返信いただき、この問題の早期解決にご協力をお願いいたします。
よろしくお願いいたします。
スバスリ
こんにちは、 @Subhasri_S さん。
あなたが共有してくれた測定結果では、POR_Bが解放される前にプルアップ電圧が供給されていますか?
あなたのアプリケーションでは、MCUが低消費電力状態に入るポイントはありますか?
問題が発生する前に、何らかの不具合やエラーは発生していますか?
よろしくお願いします、
パブロ
こんにちは、 @Pablo_Ramos さん、ご返信ありがとうございます。
POR_Bが解放されるまでは、プルアップ電圧は供給されません。プルアップのシグナル。POR_Bの動作については、以下に添付します。
私たちのアプリケーションでは、MCUが低消費電力モードに入ることはありません。
また、この問題が発生する前に、不具合やエラーは発生していません。
また、この問題が発生した際にソフトウェアでボードを復元する方法があるのかも知りたいです。
よろしくお願いいたします。
スバスリ
こんにちは、 @Pablo_Ramos さん。
これは、その件に関するちょっとしたフォローアップです。
ありがとうございます。
敬具
スバスリ
ハイ
この現象が発生すると、デバイスのフラッシュやデバッグができなくなるとおっしゃっていましたね。デバッガーを接続しようとしたら、それはできますか?
デバッガーを接続できる場合、最後に実行された命令は何ですか?
考えられる説明の一つは、以下のナレッジベース記事に記載されています。
ナレッジベース:デバッガー接続の問題に対するRTボードの復旧
「フラッシュに異常なアプリケーション(例えば、存在しないメモリへのアクセス、メモリ破損、クロックの誤設定など)が含まれている場合、基板は未知の状態に入り、デバッガがコアの制御を奪えなくなります。しかし、デバイスがシリアルダウンローダーモードになると、コアは既知の状態に強制的に移行され、デバッガーが制御できるようになります。
したがって、RTボードでデバッガー接続の問題が発生した場合は、デバイスがシリアルダウンローダーモードになっている状態で、外部フラッシュの一括消去を実行してみてください。これにより、デバッガーの正常な動作が回復するはずです。
この問題はカスタムボードとEVKの両方で発生するとのことでしたね。標準的なSDKの例を実行したときも同じ問題が起きますか?
この現象が確認されているEVKにおいて、ハードウェアの変更は行われていますか?
よろしくお願いいたします。
パブロ
こんにちは、ご返信ありがとうございます。
いいえ、デバッガー(PE Micro)を使用してデバイスにファームウェアを書き込むことはできません。
最後に実行された命令を示すスクリーンショットを以下に添付しました。何らかのコードによってハードフォルト/バスフォルトが発生した場合、ビルド後、ボードにアクセスできなくなります。ボードがこの状態に入ると、NXPのサンプルコードを含む他のコードをフラッシュすることができなくなります。また、内部起動モードでフラッシュを消去できず、ハードウェア上で手動で起動モードをシリアルダウンロードに変えてフラッシュを消去しない限り、ボードにアクセスできません。
EVKでも同様の挙動が観察されました。EVKでは物理的なスイッチで起動モードを変更するため、リカバリーは比較的簡単でした。しかし、当社のカスタム基板にはこれらのスイッチがないため、基板の復旧にはかなり手間のかかる作業が必要です。
そのため、ファームウェアの故障によりボードがアクセス不能になり、実用的でない手動復旧手順が必要になる可能性があるため、本番生産を進めるのはリスクが高まります。
この状態でデバッガーやPEmicroを使って、シリアルダウンロードモードに切り替えずにボードを復元する方法はありますか?また、問題はハードウェアによるものなのかソフトウェアなのか、どちらが原因でしょうか?
MCUがこの回復不可能な状態に陥り、私たちが意識的に回避できる状態に陥っている原因は何でしょうか?
よろしくお願いいたします。
スバスリ