3

現在、STM32F407 ターゲットで FreeRTOS を実行しているときに、構成エラーによるスタック破損と思われる問題が発生しています。

gcc を使用して STM32F4でのFreeRTOS スタックの破損を確認しましたが、解決策はありませんでした。

アプリケーションは 2 つのタスクを実行し、1 つの CAN 割り込みに依存します。ワークフローは次のとおりです。

  1. 2 つのタスク network_task と app_task が、2 つのキュー raw_msg_queue と app_msg_queue と共に作成されます。CAN 割り込みも設定されています。
  2. network_task は最高の優先度を持ち、raw_msg_queue で無期限に待機を開始します。
  3. 次に app_task があり、app_msg_queue で待機を開始します。
  4. その後、CAN メッセージが raw_msg_queue に追加され、外部イベントによって CAN 割り込みがトリガーされます。
  5. network_task が起動し、メッセージを処理し、処理されたメッセージを app_msg_queue に追加してから、raw_msg_queue で待機を続けます。
  6. app_task が起動し、ハード フォールトが発生します。

問題は、エンド ユーザーの利便性と移植性のために、app_task が xQueueReceive に対して行う呼び出しを 2 つのステップでラップしたことです。app_task の合計関数チェーンは、network_receive(..) -> os_queue_receive(..) -> xQueueReceive(..) を呼び出すことです。これはうまく機能しますが、xQueueReceive(..) から戻ると、一見ランダムなメモリ位置に戻る前に os_queue_receive(..) に戻るだけで、ハード フォールトが発生します。

スタック サイズは適切である必要があり、両方とも 2048 に設定されています。すべての大きなデータ構造はポインターとして渡されます。

2 つの STM32F407 でコードを実行しています。FreeRTOS は、執筆時点で最新のバージョン 7.4.2 です。

誰かがここで私を助けてくれることを本当に願っています!

4

2 に答える 2

1

この質問はかなり古いことは知っていますが、おそらくこれは、他の人が同様の問題に直面するのに役立つ可能性があります. FreeRTOS では、

void vApplicationStackOverflowHook(xTaskHandle xTask, signed char *pcTaskName)

スタックオーバーフローを検出し、問題のあるタスクに関する関連情報を取得する関数。オーバーフローが原因でデータが破損する可能性がありますが、少なくともオーバーフローが発生したという事実に対処することはできます (システムのリセット、エラー フラグ/LED の設定など)。

この特定の質問については、スレッドの初期化コードと割り込みルーチンを見てみたいと思います。問題が実際にオーバーフローである場合、問題がなくなるまでこれらのパラメーターを調整するのはかなり簡単だと思います。あなたは、スレッドごとに 2048 バイトで十分であると述べています。本当にそうであれば、問題がオーバーフローであるとは思えません。その時点で、古いメモリ アドレスへのダングリング ポインターを逆参照している可能性が高くなります。

于 2017-05-26T15:25:38.893 に答える