こんにちは、
LPSPI EDMA転送APIを使うとき、SDKからコールバックを呼び出すとき(EDMAが完了したとき)、LPSPI SRレジスタを見ると、約5〜10回の確率でREFビット(エラーフラグ/オーバーフローを読み取る)が設定されています。私のSPIクロックは500kHzで動作しています。SPIクロックはDMAが追いつけなくなるほど速くはないので、なぜSPI RXオーバーフローが発生するのかよくわかりません。この問題を解決する方法はありますか?また、同じ問題を経験した方はいらっしゃいますか?オーバーフローを受け取ってもデータは常に正しく見えます(転送ごとにバッファをゼロにしているので、古い古いデータではないとわかります)。転送APIを使用して同時TX/RXを行い、4msごとに転送を実行しています。タイミングに関しては問題はないはずです。
ありがとうございます
-m
こんにちは、 @nxp16 さん。
私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。
SR[REF]は受信FIFOオーバーフローを示します。転送中にこのフラグが実際に設定された場合、推奨される復旧方法は、転送を停止し、RX FIFOを空にし、REFをクリアして、転送を再開することです。
しかし、500 kHzでは、これは通常のDMA帯域幅の問題とは思えません。これは、RX EDMAチャネルがSPIクロック開始前にすでに準備・有効化されていると仮定した場合です。受信データは依然として正しいので、まずREFフラグが古いフラグなのか、それとも転送開始/停止シーケンスによって設定されているのかを確認することをお勧めします。
トラブルシューティングについては、以下をお試しください。
1. 新しい転送を開始する前に、SR[REF]をクリアしてください。
2. TXがクロックの生成を開始する前に、RX DMAが有効になっていることを確認してください。
3. 転送間でLPSPIが無効化/有効化されているかどうかを確認します。無効化/有効化されている場合は、該当するエラータの回避策を適用します。LPSPIを有効にした後でREFをクリアするか、LPSPIを再度有効にする前にリセットします。
お役に立てれば幸いです。
よろしくお願いいたします。
5月
訂正表には2つの回避策が記載されており、SRのビットをクリアすることとペリフェラルをリセットすることだ。残念ながら、最初のエラッタについてはSDKがすでに対応しているため、問題を回避できていないようです。残念ながら、私の場合、ペリフェラルをリセットすることは選択肢にありません。なぜなら、その後すべてを再設定しなければならないからです(すべてのレジスタがクリアされます)。今のところ、DMAが正常に完了したにもかかわらずREFエラーが発生した場合は、それは誤ったエラーであるとみなし、無視することにします。
ありがとうございます
-m
残念ながら、SDKは転送間にLPSPI周辺機器を無効化・有効化しており、私はそれをコントロールできません。
ありがとうございます
-m
こんにちは、@Mike_M3 さん。
転送の合間にLPSPIが無効化され、再度有効化されているかどうかを確認してください。もしそうであれば、この手順を避ける方が望ましい。無効化／有効化が必要な場合は、記載されている回避策に従ってください。
REFをクリアした後、次の転送を開始する前にRX FIFOの状態と受信データを確認し、デバッグのためにこの状態をログに記録/カウントしてください。
よろしくお願いいたします。
5月
最新情報ありがとうございます。
SDKは内部でLPSPIを無効化・再有効化できますが、アプリケーションは次の転送を開始する前に、前回のLPSPIバス転送が完了していることを必ず確認すべきです。
EDMAコールバックは、DMAの完了のみを示します。次の転送が、SR[MBF]が設定されているか、SR[TCF]が設定されていない状態でEDMAコールバックから即座に開始された場合、SDKはLPSPIが完全にアイドルでない状態で次の転送セットアップに入ることがあります。
次のLPSPI EDMA転送を送信する前に、SR[TCF]=1またはSR[MBF]=0になるまでお待ちください。