2387043_ja-JP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2387043_ja-JP

2387043_ja-JP

PDB ADC プリトリガーシーケンスエラー回復

こんにちは、NXPコミュニティの皆さん、

S32K144では、ランタイムフラッシュ消去/プログラム操作後にADC0/ADC1割り込みが停止します。

前回の質問の続きとして、S32K144におけるPDB ADCのプリトリガーシーケンスエラーから適切に復旧する方法について、いくつか説明が必要です。

以下の3つの方法を試しましたが、そのうち1つだけが正しく動作しました。

方法1(動作中):


  • フラッシュ消去/書き込み操作を実行する前に、PDB0とPDB1を停止してください。
  • フラッシュ処理が完了したら、両方のPDBを再起動し、対応するISRを再度有効にします。

この方法を用いると、PDB配列のエラーは発生しない。


方法2:

フラッシュメモリの消去/書き込み操作が完了した後、PDB0とPDB1を停止して再起動しました。しかし、PDBプレトリガーシーケンスエラーが発生しました。そこで、PDBモジュールを停止して再起動することで復旧を試みましたが、シーケンスエラーは解消されませんでした。

方法3:

方法3(効果なし):

フラッシュ消去/書き込み操作中、PDB0とPDB1を停止または再起動しませんでした。その代わりに、操作が完了した後、保留中のPDB ISRとADC ISRがそれぞれ1つずつトリガーされました。

PDB ISR内で、以下の方法でシーケンスエラーフラグをクリアしようと試みました。

PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK);

対応するADC割り込みサービスルーチンが実行され、ADC結果レジスタを読み取ることでCOCOフラグがクリアされた。これでさらなるプリトリガーシーケンスエラーを防ぐつもりでしたが、問題は依然として解決せず、この方法はうまくいきませんでした。

私の質問は、PDBプリトリガーシーケンスエラーが発生した場合、システムをリセットせずにPDB/ADCの動作を回復し、通常のトリガー動作を再開することは可能かということです。それとも、回復不能な状態に陥るのを避けるために、PDBを事前に停止して再起動する必要があるのでしょうか?
Re: PDB ADC pre trigger sequence error recovery

こんにちは、

PDB_S_ERRをクリアするだけでは、ADC/PDBシーケンスが既に同期していない可能性があるため、プリトリガーシーケンスエラーからの回復には通常不十分です。テスト結果に基づくと、フラッシュ処理の前にPDBを停止し、処理後に再起動することで、この問題を回避するのが最も確実な方法であると思われます。

エラー発生後に復旧を試みる場合は、PDBとADCの両方の状態が完全に再同期されていることを確認することをお勧めします。これには、PDB の無効化、保留中の PDB ステータス フラグのクリア、保留中のすべての ADC 変換結果が読み取られていることの確認 (COCO がクリアされていること)、PDB の再有効化、および再開をトリガーする前に必要に応じて構成の再読み込みが含まれる場合があります。

RMによると、プレトリガーロックは対応するCOCOフラグが設定されたとき、プリトリガーが無効化されたとき、またはPDBが無効化されたときに解除されるため、完全なPDB無効化・有効シーケンスも検討する価値があるかもしれません。

BR、ペトル

Re: PDB ADC pre trigger sequence error recoveryこんにちは、PetrSさん。

私は以下の方法を試してみました。

PDB停止なしでフラッシュ消去操作を行った後、マイクロコントローラは保留中のADC ISRコールバックを1つ受け取りました。そのコールバック関数内で、ADC結果レジスタを読み取った後、以下の関数を呼び出してPDBシーケンスエラーをチェックし、エラーから回復します。

「`c」
void PDB1_check_seq_err(void)
ヤージュ
((PDB1->CH[0].S & PDB_S_ERR_MASK) != 0) の場合
ヤージュ
PDB1->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK);
PDB1->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK);
PDB1->SC |= (uint32_t)PDB_SC_PDBEN_MASK;
PDB1->SC |= (uint32_t)PDB_SC_SWTRIG_MASK;

}
}

void PDB0_check_seq_err(void)
ヤージュ
((PDB0->CH[0].S & PDB_S_ERR_MASK) != 0) の場合
ヤージュ
PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK);
PDB0->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK);
PDB0->SC |= (uint32_t)PDB_SC_PDBEN_MASK;
PDB0->SC |= (uint32_t)PDB_SC_SWTRIG_MASK;
}
}
「`」

私が使用した復旧手順は以下のとおりです。

1. `ERR`フラグをクリアします。
2. PDBを停止します。
3. PDBを再度有効化して再起動します。

この停止と開始のシーケンスにより、すべてが再び正常に動作するようになります。後続のプリトリガーが発生し、ADC ISRコールバックが正常に呼び出されます。

しかし、なぜこれが必要なのか、私にはまだ完全には理解できていません。リファレンスマニュアルには、「ERR」条件をクリアし、ADC結果レジスタ(「COCO」をクリア)を読み取ることでロックが解除されると述べられています。私のCASEでは、それだけでは十分ではなく、回復にはPDBのストップ/ストップシーケンスが必要です。

また、`PDBn->SC |= PDB_SC_SWTRIG_MASK` は厳密には必須ではないことも確認しました。ソフトウェアトリガーを発行しなくても、ロックは解除され、PDB再起動後にADC ISRの実行が再び始まります。

RMでは「ERR」と「COCO」をクリアすればロックが解除されるはずだと示されているにもかかわらず、なぜPDBを停止して再起動する必要があるのか、説明していただけますか?
Tags (1)
No ratings
Version history
Last update:
2 hours ago
Updated by: