プログラムロジックエラー：DMA+アイドル割り込みの「偽割り込み」問題

問題：USART1 と USART3 の DMA 受信機能は、電源投入直後は動作せず、手動でリセットボタンを押して初めて正常に動作する。

分析：これは「DMA+アイドル割り込み」方式における典型的な「競合状態」の問題です。原因は以下の通りです。

• STM32 は電源投入と同時に、RX ピンが PC のシリアルツールからの「アイドル」ハイレベルを受信した状態になっています。
• 初期化コードが「アイドル割り込み」を有効にした瞬間、USART ペリフェラルは既に存在するこのアイドル状態を検出し、「偽の」アイドル割り込みを 1 回発生させます。
• この割り込みは誤って処理されます（DMA はまだデータを受信していないため）、システムが最初のフレームの実際のデータへの応答を見逃す原因となります。
• 手動リセット時はタイミングがわずかに異なり、この問題を回避します。

解決策：DMA 受信を開始し、アイドル割り込みを有効にする前に、USART のアイドルフラグビットを強制的に 1 回クリアします。コードは以下の通りです。

コード構造の最適化——初期化とビジネスロジックの分離

問題分析：フラグをクリアするコードを追加しても、Init 関数内に配置すると効果は依然として理想的ではありません。その深い原因は以下の通りです。

• main 関数内で、MX_USART1_UART_Init の実行が完了した後、プログラムは他のペリフェラルの初期化 (MX_I2C2_Init, MX_USART3_UART_Init など) を継続して実行します。
• 不安定で動的な初期化シーケンスの途中で、継続的に実行する必要があるバックグラウンドタスク（UART DMA など）を事前に開始すると、後続の他のペリフェラルの初期化動作（DMA チャンネルの再設定、クロックの変更、割り込み優先度の修正など）によって干渉を受けやすく、失敗する原因となります。

解決策：

1. MX_..._Init() 関数から、ビジネス起動に関連するすべてのコード（HAL_UARTEx_ReceiveToIdle_DMA など）を削除し、純粋なハードウェアパラメータ設定のみを担当させます。
2. ビジネス起動コードを修正案とともに、main 関数の /* USER CODE BEGIN 2 */ 領域に統合して移動します。

結果：すべてのハードウェアペリフェラルの設定が完了し、システムが安定状態に入った後に、UART DMA 受信などのアプリケーション層タスクを開始することを保証します。プログラムの動作は信頼性が高く、期待通りになります。

更新: 2 つのシリアルペリフェラルの初期化の前に HAL_Delay(500); 遅延関数を 1 行追加する必要があります。そうしないと、USART3 の DMA 受信も無効になる可能性があります。

まとめ

1. タイミングと競合状態に警戒する：割り込みや DMA などの非同期操作は、タイミングの問題が非常に発生しやすいです。「電源投入時は異常、リセット時は正常」は典型的なシグナルです。
2. ハードウェア設定とビジネス起動を分離する：これが最も重要な原則です。
   • 設定：MX_..._Init 関数には 1 つのことだけをさせます——CubeMX の設定に基づいてハードウェアレジスタを設定し、ハードウェアを「待機」状態にします。
   • 起動：main 関数内で、すべてのハードウェア設定が完了したのを待ってから、ビジネスロジックの順序に従ってそれらを起動します（DMA の有効化、タイマー PWM の開始など）。

2 番目の原則に従うことで、調査が困難な組み込みシステムの初期化問題の 90% 以上を回避でき、コードがプロフェッショナルで堅牢になるための必須の道となります。