皆様へ
isAttachフラグがtrueに設定されている場合、接続時にハードウェアリセットがサポートされているかどうかご存知の方はいらっしゃいますか？SOなら、どうCANのでしょうか?
IMXRT1176 EVKBにおいて、実行中のコアに接続した後、リセットボタンでボードをリセットしても、一部の割り込みがアクティブなままになるという奇妙な動作が発生しています。
もしそれを防ぐ他の方法があれば、何かヒントをいただけるととてもありがたいです。
よろしくお願いします、
ヤクブ
こんにちは、 @jslota13245。
問題を理解し再現するために、以下の情報を教えていただけますか?
問題が発生した場合、どのような手順を踏んでいますか？
-リセットが起きてもどの中断が有効なままですか?
-この動作をSDKの例で再現できますか?もしそうなら、どの学校ですか?
-デバッグ中にボードをリセットする目的は何ですか?
BR
ハビブ
ハビブ様、
ご回答ありがとうございます。
←問題発生時にどのような手順を踏んでいますか？
-> 申請書に無効LPUART2_IRQHandler(無効)を定義しています。起動ファイルから弱い定義を上書きします。デバッグシンボル付きのバイナリをフラッシュしてから、実行中のコアに接続します。簡単にするために、LPUART2を介して接続されたもう一台の基板がデータを書き込んでいると仮定します。これはほぼ常に起こっているとしましょう。いつ送ってくるか予測できないからです。取り付けた後、kLPUART_RxDataRegFullFlagがトリガーされているのが見えます。この割り込みを有効にしたため、これは想定内の動作です。
デバッグにはVS Codeの拡張機能を使用しています。リセット用のボタンが2つ用意されています。私の理解では、デバッグセッションをリセットしCPUをリセットすることは可能です。私たちは2番目を使います。リセットボタンを押した後、予想通りメイン関数の開始位置にあるブレークポイントに到達しました。次にコアを実行すると、この割り込みを有効にするコードに到達する前に、kLPUART_RxDataRegFullFlag を持つ LPUART2_IRQHandler に到達します。これは問題のある部分だ。
←リセットが発生したときにアクティブなままになる割り込みはどれですか？
-> kLPUART_RxDataRegFullFlag
< 私たちのSDKの例でこの動作を再現できますか?もしそうなら、どの学校ですか?
->まだ試してない。非同期UART受信の例があり、通信の相手側が常にUARTポートに書き込みを行っていることを確認できれば、再現可能だと思います。アタッチが重要な手がかりかもしれません。私たちは「起動」を行っていないので、アタッチセッションの開始時にハードウェアがリセットされていないのかもしれません。
<-デバッグ中に基板をリセットする目的は何ですか?
-> ボードをリセットすると言ったのは、デバッグセッションをリセットするか、メイン関数の先頭にジャンプするという意味です。少なくとも起動設定中はそういう仕組みで、メインのスタートに戻って再接続せずにデバッグできます。これはかなり一般的な操作だと思いますが、何か異常な点があればお知らせください。
もし追加情報を提供できるなら、ぜひ教えてください
よろしくお願いします、
ヤクブ
こんにちは、 @jslota13245 さん、
私自身もテストを行い、RDRF（受信データレジスタ満杯）フラグが正しくクリアされることを確認しました。観察している行動をよりよく理解するために、以下の情報を教えていただけますか?
この問題が発生した際、リセットがトリガーされる前にRDRFフラグが設定されているのが確認できますか？
リセットをクリックし、メインで停止している(アプリケーションコードが実行される前)とき、LPUART2 STATレジスタの値は何になりますか?
周辺機器ビューを使用している場合は、表示情報が最新かどうかを確認するためにレジスタ値を確認する前にリフレッシュボタンをクリックしてください。
リセットが発生した時点で、UART受信トランザクションは進行中ですか？
基板にハードウェアの変更を加えましたか？
-現在、VS Code拡張機能用のMCUxpressoのどのバージョンを使っていますか?
-どのバージョンのSDKを使っていますか?
BR
ハビブ