組み込み実践編 ②：シリアルコンソール編
はじめに
前回（A-1）で整理したレイヤーのうち、一番手軽に確認でき、かつ一番最初に手が伸びる道具が「シリアルコンソール」です。
本記事では、TeraTermを使ったシリアルコンソールの活用と、ブートログの読み方の基本を扱います。
なぜ最初にシリアルコンソールなのか
- 追加のハードウェア知識がほぼ不要（USB-UART変換とTeraTermがあればすぐ始められる）
- 「機器が何か喋っているかどうか」だけで、電源・クロックレイヤーと信号・通信レイヤーの生存確認になる
- ブートローダやカーネルの初期化メッセージがそのまま流れてくるので、ブート・ファームウェアレイヤーの切り分けにも直結する
接続の基本
手持ちのUSB-UART変換（例：FT232RL）を使い、対象機器のUART（TX/RX/GND）に接続します。
- 配線の基本：機器のTX→変換器のRX、機器のRX→変換器のTX、GND同士を接続（クロス接続に注意）
- 電圧レベル：3.3V系か5V系かを確認してから接続する（レベルが合わないと通信できない、または機器を壊す可能性がある）
- ボーレート：まずは対象機器のデータシートやこれまでの実績値（多くの組み込みLinuxボードは115200bps）を確認
なお、ここまではUSB-UART変換を使う前提で説明しましたが、PC側に今どきのUSBではなく昔ながらのRS-232（DB9）ポートしか無いケースもあります。その場合はUSB-UART変換の代わりに、以下のようなMAX3232系のレベル変換モジュールを挟んで、TTLレベルに変換してからマイコン側に繋ぎます。
考え方を図にすると以下の通りです。RS-232はTTL系UARTよりかなり大きい両極性電圧を使う規格なので、そのままマイコンのUARTピンに繋ぐと壊れる可能性がある、というのがポイントです。
TeraTermでのログ取得の作法
現場で地味に差がつくのが「ログの残し方」です。以下を徹底しておくと、後から見返す・共有するときに困りません。
- ログファイルの自動保存を有効化：接続開始時に毎回ログファイルを残す設定にしておく（「ファイル」→「ログ」）
- タイムスタンプ付きログ：TeraTermのログ設定でタイムスタンプを付与しておくと、後から「いつ何が起きたか」を時系列で追える
-
ファイル名にログ取得日時を含める：
202607xx_hhmmss_対象機器名.logのように命名しておくと後で探しやすい - マクロは極力使わない：手打ちのコマンド操作を安易にマクロ化すると、想定外の入力タイミングやエラー処理漏れで再現性が落ちることがある（この方針は後のA-5で「では繰り返し操作をどう楽にするか」という形で回収する）
ブートログの読み方（基本編）
組み込みLinuxのブートログは情報量が多いですが、まず見るべきポイントを絞ると追いやすくなります。
- ブートローダのバナー・バージョン表示：ここが出ない＝電源/クロック/信号レイヤーの疑いが濃い
- メモリ初期化・DRAM訓練のログ：ここで止まる＝ハードウェアの初期化に問題がある可能性
-
カーネルの起動開始メッセージ（
Starting kernel...等）：ここまで来ればブートローダは正常に仕事を終えている - カーネルパニック・Oops の有無：出ていれば具体的なドライバ名・アドレスが手がかりになる
- rootfsのマウント成功可否：ここで止まる場合はストレージ・パーティション・rootfsイメージ側を疑う
よくあるトラブルと切り分け
| 症状 | 疑うポイント |
|---|---|
| 何も表示されない | ボーレート不一致、TX/RXの配線が逆、電圧レベル不一致、GND未接続 |
| 文字化けする | ボーレート不一致、クロック精度不良、ケーブル品質・ノイズ |
| 途中まで出て止まる | ブート・ファームウェアレイヤーの初期化異常（メモリ、ストレージ等） |
| 出力はあるが入力を受け付けない | ハードウェアフロー制御の設定不一致、RX配線不良 |
まとめ
- シリアルコンソールは「追加投資ゼロに近い」最初の生存確認手段
- ログの自動保存・タイムスタンプ付与を徹底しておくと後で必ず役に立つ
- ブートログは「どこまで出て、どこで止まったか」を追うだけで、レイヤーの当たりがかなり絞れる
次回（A-3）は、シリアルだけでは追えない「ブートローダより前」「実行中のCPUの中身」を覗くための道具、JTAG/デバッガを扱います。