投稿日:
2026年10月30日
読了時間:
10分
組み込みエンジニアなら誰もが経験したことがあるでしょう。
顧客から、開発中には一度も発生しなかった不具合が報告されることがある。通信スタックが予期せずタイムアウトしたり、特定の負荷プロファイル下でモーターコントローラが不安定になったりすることもある。やがてチームは実験室でその問題を再現し、デバッガを接続して、疑わしいコードパスをステップ実行し始める。
すると、そのバグは消えてしまう。
すべてが正常に見える。変数には期待通りの値が格納されている。実行も意図したパスに沿っている。しかし、デバッガを切断してから数時間後、その不具合は静かに再発する。
ソースコードには何の変更もありません。ハードウェアにも何の変更もありません。唯一変わったのは、タイミングだけでした。
多くの組み込みシステムの障害は、そもそもコードの誤りによるものではありません。それらは、並行して実行されるタスク、割り込み、ドライバ、ミドルウェア間の相互作用に起因しています。つまり、レースコンディション、割り込みのレイテンシ、スケジューリング順序、そしてマイクロ秒単位で測定されるタイミングウィンドウなどが原因なのです。エンジニアたちは、この種の問題を「ハイゼンバグ」と呼んでいます。
Linux、コンテナ、CI/CDプラットフォームでの開発が増えているチームにとって、高度な可視化ツールが別のオペレーティングシステムやデバッグ環境を必要とする場合、こうしたデバッグの課題はさらに困難なものとなります。
なぜ一部の組み込みバグはデバッガの下では消えてしまうのか？
ブレークポイントはCPUを停止させますが、周囲の世界を止めるわけではありません。コアが停止している間も、周辺機器、DMA転送、外部信号は動作し続ける可能性があります。割り込みはキューに蓄積され、実行が再開されると異なる順序で発生します。コードをステップ実行するだけでも、数マイクロ秒が数秒に引き延ばされます。
タイミングに依存するバグの場合、これだけで問題が消えてしまうことがあります。システムを観察するという行為自体がタイミングを変えてしまうため、障害の原因となったレース条件が発生する「レースウィンドウ」が開かなくなってしまうのです。最適化レベルを低く設定したデバッグビルドでは、タイミングがさらにずれることもあります。
その結果、苛立たしい悪循環に陥ります。つまり、誰も見ていない時にはバグが現れ、誰かが注目した瞬間に消えてしまうのです。
ブレークポイントでは把握できないことを、タイムラインはどのように示すのか？
ブレークポイントは、コードを理解するための優れたツールです。しかし、動作中のシステムを理解するためのツールとしては、往々にして不向きです。
RTOSタスク、割り込みハンドラ、ドライバ、ミドルウェアが共有リソースを奪い合うシステムにおいて、エンジニアが単一の誤った行を探し出すことはめったにありません。彼らは、障害が発生する直前の数ミリ秒間に何が起きたのかを理解しようとしているのです。ブレークポイントは静止したスナップショットしか提供しません。複雑な障害の解析にはタイムラインが必要です。
リアルタイム可視化ツールは、アプリケーションがフルスピードで動作し続ける中でシステムの活動を記録することで、そのタイムラインを提供します。IAR C-SPYを使用すれば、エンジニアは以下のことが可能になります：
- RTOSタスクのスケジューリングやコンテキストスイッチが実際に発生している様子を確認し、実行が遅れているタスク、予期せずブロックしているタスク、あるいは互いにリソースを奪い合っているタスクを特定する
- 割り込みのアクティビティとレイテンシを測定し、実行時間が長すぎるハンドラや、不適切なタイミングで発生するハンドラを特定する
- 実行時間をプロファイリングし、実際の負荷下でCPUがどこでサイクルを消費しているかを確認
RTOSの可視化により、システムは生のメモリではなく、タスク、キュー、セマフォという観点から把握できます。
各技術に何が必要か、またシステムにどの程度の影響を与えるかを明確にしておく価値があります：
- ETM命令トレースは、 アプリケーションに一切干渉することなく実行を記録します。これには、多くのCortex-M3以降のデバイスに搭載されているETMと、I-jet Traceなどのトレース対応プローブが必要です。
- SWO ベースのトレースおよびサンプリングは、 ほとんどの Cortex-M3 およびそれ以上のデバイスにおいて、標準的なデバッグプローブを使用して動作します。ハードウェアサンプリングは非侵入的に近い一方、ソフトウェアインスツルメンテーションは、予測可能なわずかなオーバーヘッドを伴います。
- Cortex-M0およびM0+デバイス にはETMやSWOは搭載されていませんが、多くのCortex-M0+デバイスでは、Arm CoreSight Micro Trace Buffer（MTB）を介したシンプルな命令トレース機能が依然として提供されています。 トレースデータはオンチップRAM内のユーザー設定可能な循環バッファに格納されるため、キャプチャ深度はそれに割り当てられたRAM容量によって制限されます。
図 1. ETM と SWO のトレースを統合して可視化したもので、関数の実行、割り込みアクティビティ、および実行時イベントを共通のタイムライン上で関連付け、詳細なタイミングおよび実行解析を可能にしています。
ArmのCoreSightドキュメントでは、その基礎となるメカニズムについてさらに詳しく解説しています。
トレースはどのようにしてタイミングバグを見つけるのか？ モーターコントローラの話に戻る
冒頭で紹介した不安定なモーターコントローラを例に挙げましょう。問題のある負荷プロファイルの下でシステムがフルスピードで動作している場合、タイムラインによってそのパターンが即座に明らかになります。エンジニアは、ブレークポイントで取得したスナップショットに頼る代わりに、時間経過に伴う割り込み、トレースイベント、およびアプリケーションの挙動を観察できるため、タイミング関連の障害の診断がはるかに容易になります。
高優先度の制御タスクは、低優先度の通信タスクが一時的に保持している共有バッファを必要とします。通常、このバッファはマイクロ秒単位で解放されます。しかし、ピーク負荷下では、中優先度の診断タスクが、通信タスクがまだバッファを保持している間にそのタスクをプリエンプトしてしまいます。その結果、制御タスクは待機を余儀なくされ、デッドラインを逃し、制御ループが不安定になります。 これは典型的な優先順位反転であり、3つのタスクすべてが、まさに適切な負荷条件下で同時に実行される場合にのみ発生します。
タイムラインは、実行状況をシステムレベルで可視化し、ソースコードだけでは再現が困難なソフトウェアとハードウェア間の相互作用を明らかにします。調査がLinuxワークステーション、Windowsデスクトップ、あるいはトレースプローブを介して接続された実験用マシンで行われるかに関わらず、エンジニアは同じデバッグ機能と可視性にアクセスできる必要があります。
図2. IARのクロスプラットフォームIDEにおけるC-SPYタイムライン解析は、割り込みの挙動、トレースイベント、データログ、電力測定値を単一のタイムラインに統合し、システムアクティビティのリアルタイムなビューを提供します。実行中のシステムを観察することで、エンジニアはブレークポイントで実行を停止した際には消失してしまう可能性のある、タイミングに関連する問題を特定できます。
ブレークポイントでは、このような現象は決して検出できなかったでしょう。システムを停止させて調査すると、問題の原因となっているタイミングそのものが失われてしまうからです。タイムラインによって問題が可視化されれば、修正は簡単です。優先順位継承機能を持つミューテックスを使用すればよいのです。修正の検証には、同じ負荷条件下での2回目のトレースキャプチャが必要です。
Linux上でネイティブに高度な組み込みデバッグは可能か？
多くのチームにとって、Linuxはすでに開発、コンテナ、CI/CDの基盤となっています。しかし、高度なデバッグは、多くの場合、別のWindowsマシンや、デバッガ専用に用意された仮想マシンに依存してきました。
IARのクロスプラットフォームIDEは、別途Windows環境を必要とせずに、Linux上で高度な組み込みデバッグワークフローを実現します。エンジニアは、LinuxとWindowsの両方で、同じC-SPYによるデバッグ体験、RTOS対応機能、タイムライン分析、プロファイリング、電力監視、およびトレース機能を利用できます。 これにより、個別のツールチェーンやOS固有のプロセスを維持することなく、開発者のワークステーション、コンテナ、ラボ環境、CI/CDインフラストラクチャ全体でデバッグワークフローを標準化することが容易になります。
エンジニアは、別々のツールを切り替えることなく、単一のデバッグ環境内でRTOSの動作、割り込み、プロファイリング情報、およびアプリケーションの挙動を関連付けて分析できます。
図3. C-SPYにおけるRTOS対応デバッグでは、スレッドスケジューリング、プロファイリング、割り込みアクティビティ、同期オブジェクト、タイムライン分析が単一のワークスペースに統合されています。LinuxとWindowsの両方で同じデバッグ環境が利用可能であるため、開発チームはデスクトップ、コンテナ、CI/CD環境全体でワークフローを標準化できます。
エンジニアリングリーダーにとって、これには実用的なコスト面でのメリットがあります。デバッグのために稼働させ続けるWindowsマシンや仮想マシンの数が減れば、ラボやCIインフラストラクチャが簡素化され、ライセンス管理、パッチ適用、メンテナンスの負担が軽減されます。また、現場からの報告から根本原因の特定に至るまでのプロセスも短縮されます。 これは、リリース数日前にタイミングの問題が表面化した場合や、顧客から報告された障害が、ラボで発見された場合よりもはるかに大きなコストを招いている場合に、特に重要になります。
Linux上でデバッグされたプロジェクトは、開発者のワークステーションやCIパイプラインにおいて、単一のCMake定義からビルドすることができます。CMakeブログでは、このワークフローについてさらに詳しく解説しています。
「Embedded Systems in Motion」を参照
ブレークポイントは、その時点の静的なスナップショットを提供します。複雑な障害の解析には、タイムラインが必要です。
インタラクティブな IAR Embedded Development Platform デモで、トレース、RTOS 対応、タイムライン分析がどのように連携するかをぜひご確認ください。
