質問の意味がわかりません
ソースコードはここにあります
まだ何を聞きたいのかよく分からないです。
投稿者様、ご質問ありがとうございます。補助電源モジュールを少し変更したところ、問題が発生しました。DCDC降圧モジュールをNDP2355KCモジュールに差し替え、パワーインダクタにはPSPMAA0605H-100M-ANPを使用しました。入力電圧を16Vなどで設定し、出力電圧を10V程度に設定すると、システムが再起動（Cポート電源時）または過電流になり、最大電流での出力（定電圧電源供給時）になってしまうのです。直流電源で給電すると電源側がCCモードに入り、出力電圧が約6Vになります。また、基板のMOSトランジスタが著しく発熱しています。原因を分析していただけますでしょうか？よろしくお願いいたします。
出力端がショートしていないか確認してください
PCBのレイアウトを確認してください
出力にも短絡はありません
抵抗がうっかり回転してしまったようです。PCBには問題はありません。電流サンプリングでケルビン接続が必要なことに気づいておらず、ご指摘ありがとうございました。
このHRTIMでPWM周期の中央でADCサンプリングをトリガーするにはどう設定すればいいですか？設定してみたのですが、トリガーのタイミングがどうも合わず、設定したよりもずっと遅れてしまいます。どこに問題があるのか、どうやって調べればよいでしょうか？
どう設定しているかスクショを見せて。
Cのみ使用しており、Dは将来の拡張用です
テストしてみたところ、PC15ピンの反転タイミングが設定した時刻より常に2.5uS遅れることが分かりました。以下がテスト用の関数です
// コールバック関数
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc)
{
// ADC1_2_IRQHandler();
if (hadc->Instance == ADC2)
{
GPIOC->ODR ^= GPIO_PIN_15;
Control_Loop_Update(); // 高周波制御ループ
// GPIOC->ODR ^= GPIO_PIN_15;
}
else if (hadc->Instance == ADC1)
{
// GPIOC->ODR ^= GPIO_PIN_13;
// flag_adc1 = 1;
PID_V();
GPIOC->ODR ^= GPIO_PIN_13;
}
// HAL_GPIO_WritePin(GPIOB, GPIO_PIN_15, GPIO_PIN_RESET); // Lowにする
}
このスクリーンショット、なぜか順番がおかしくなってます 
兄弟、そのテスト方法自体に問題があるよ。HAL_ADC_ConvCpltCallbackの中でIOをトグルしてるけど、それで測れるのは「トリガー時間」なんかじゃなくて、「ADCサンプリング時間 + 変換時間 + 割り込み応答遅延 + HALライブラリの膨大な判定オーバーヘッド」だよ。
HAL_ADC_IRQHandlerの中に入ってソースコードを見てみればわかるけど、STのHALライブラリはこのコールバックを呼ぶ前にレジスタのステータスをいろいろチェックしてて、その間に1〜2us消えてしまうのは全く普通のことだ。それに、スクリーンショットの設定ではサンプリング時間が6.5サイクルで、変換にさらに12.5サイクルかかってるだろ。これらは全部確実にかかる時間なんだ。
本当のトリガーポイントを測りたいなら、タイマーのコンペア出力ピンを直接設定して、オシロスコープでPWM波とそのコンペア出力を観測するといい。どうしても割り込みの中で測りたいなら、HALライブラリは捨てて、スタートアップファイルからADCの割り込みエントリを直接見つけて、入って一番最初にGPIOをトグルするようにすれば、遅延が一気にずっと小さくなるのがわかるはずだよ。
「いいね！」 1
CubeMXのスクリーンショットを見てみましたが、いくつか気になる点を確認してみてください：
- ADCのトリガーソースが
Timer C Compare 3に設定されていますが、Timer Cの設定でCompare 3を46080 / 4にしていますね。PWM周期が46080なら、中心点は/2ではないでしょうか？（センターアライメントモードを使っている場合を除きますが、その場合は具体的に計算する必要があります）。 - ADCのトリガーエッジに
Trigger detection on the falling edge（立ち下がりエッジトリガ）を選択していますが、HRTIMが生成するトリガーイベントは、想定しているタイミングで立ち下がりエッジになっていますか？通常はデフォルトで立ち上がりエッジに設定することが多いです。 - 上の方も言っているように、2.5uSは間違いなくソフトウェアのオーバーヘッドです。G474の動作周波数が170MHzの場合、2.5uSで約400命令強が実行できる計算になり、そのすべてが割り込み入り時のスタック処理とHALライブラリのif判定に費やされています。DMAを使用することをお勧めします。ADCの変換完了で直接DMA転送をトリガーするようにし、CPUの割り込みで待機するのはやめましょう。
「いいね！」 1
はい、その後またテストしてみたところ、ADC1_2_IRQHandler関数に入れたら遅延がほぼなくなりました。
皆さん、現在テスト中なのですが、最初は正常に動作していました（出力の「リプル」が大きく、スイッチング周波数と同じですが、増幅されて周波数が非常に高くなっています。下図参照）。その後、出力コンデンサをいくつか追加して再度電源を入れたところ、32のADCがすべて壊れてしまったようです。現在、ADCピンから読み取るデータは、外部入力がどれだけ変わっても常に同じ値になってしまいます。考えられる原因は何でしょうか？入力電圧は40V、出力は30Vに設定、負荷は20Ωです。お聞きしたいのですが、テストモジュールの後に32のピンを保護する素子を追加する必要はあるのでしょうか？追加する場合、何かおすすめはありますか？よろしくお願いします！
何言ってるのかさっぱりわからないんだけど、これって私がオープンソースにしたボード？
トポロジは同じですが、これは自分で描いたものです
質問は以下の通りです
-
出力の交流成分を測定した波形で、なぜこのような高いスパイクが発生するのですか？1つのスイッチング周期の中で4回発生していますが、この影響を取り除くにはどうすればよいでしょうか？
-
基板のテスト中に、STM32のADC部分がすべて壊れてしまいました。なぜADC部分が壊れたのか分かりません。ADCピンの前にRCローパスフィルタを入れているのに、結局ADCピンが壊れてしまいました。考えられる原因は何でしょうか？以前の質問ではADCピンの故障を疑っていましたが、現在は本当に壊れたことがほぼ確定しています。（上図の交流成分のスパイクが高すぎたせいでSTM32のADCピンが破損したのではないかと推測していますが、この推測が正しいかどうかは分かりません）すでに2つのマイコンを壊しており、どちらもADCピンの破損が原因ですが、原因が見つかりません
-
もしSTM32のADCピンに追加の保護を設けて、ADC入力を0〜3.3Vの間に制限したい場合、何か良い方法やデバイスはありますか？
-
レイアウトの際、入力から出力までのループ全体を最小にする（青い線）べきでしょうか？それとも、2つのホットループ（赤い線）を最小にすればよく、大きなループは気にしなくてよいのでしょうか？
図の通り
