UART文字化け・出力されない原因と対処法｜配線からボーレートまで

UARTが無出力・文字化けするときの切り分け順

最初に「信号そのものがない」のか、「信号はあるが端末で読めない」のかを分けます。ターゲットTXを測定器で観察し、起動時や操作時に波形が出るかを確認してください。波形がないなら、端子の選択、コンソール有効化、ブート段階の設定、ターゲット電源を調べます。波形があるなら、電圧レベル、ボーレート、データ形式、極性、接地、端末側の設定を調べます。この二分だけでも、ソフトウェア設定と配線を同時に疑う無駄を減らせます。

一度に複数の項目を変更すると、たまたま表示された場合に何が効いたのか分からなくなります。まずボードの公式マニュアルにあるコンソール設定を記録し、TX/RXの接続と電圧を確認します。次に端末のボーレート、データビット、パリティ、ストップビット、フロー制御をその設定へ合わせ、最後に測定したビット幅と照らし合わせます。変更は一項目ずつ行い、変更前後の値と結果をメモしましょう。

USB-UART変換器を交換して症状が変わっても、変換器だけが原因とは限りません。変換器のI/O電圧、ドライバー、ポート番号、端子順、ケーブル品質が同時に異なることがあります。別の変換器を使う場合も、型番と信号電圧を記録し、回路図で指定された接続と比較してください。

電圧・極性・接地を安全にチェックする

UARTという名称は通信方式を示しますが、物理電圧がすべて同じという意味ではありません。マイコンの3.3 VロジックUART、1.8 VロジックUART、RS-232トランシーバーを介した信号などを混同しないでください。RS-232はロジックUARTと電圧範囲や極性が異なるため、端子名だけを見て直接つなぐのは危険です。ボード回路図、コネクター仕様、変換器のデータシートで、各信号の電気特性を照合します。

GNDが共通でないと、受信側は信号の基準電位を正しく判断できないことがあります。一方で、別系統の電源や接地を安易に結ぶと、意図しない電流経路を作る場合があります。ホストとターゲットの電源構成を確認し、必要な信号GNDだけを所定の方法で接続してください。USB-UART変換器のVCCピンは電源出力の場合もあるため、ターゲットへの給電が設計上必要でないなら、接続しないでください。

電源を落として配線を行い、電源投入前にTX/RXとGNDの接続先をもう一度確認します。端子のTX/RX名は、その基板または接続相手の視点で付いていることがあり、名称だけでは信号方向が直感と逆になることがあります。回路図の送信側から受信側へ、信号の流れを追うと間違いを減らせます。

ボーレートとフレーム形式を波形から照合する

非同期UARTでは、送信側と受信側がそれぞれのクロックからビット時間を作ります。設定ボーレートをBとすると、理想的な1ビット幅はおよそ1/B秒です。たとえば115200 bit/sなら約8.68マイクロ秒が目安ですが、実際の値はクロック誤差や分周方式により変わります。オシロスコープやロジックアナライザーで複数ビットの幅を測り、単一エッジのノイズをビット時間と誤認しないようにします。

フレーム形式は、スタートビット、データビット数、パリティ、ストップビットの組み合わせです。例えば「8N1」はデータ8ビット、パリティなし、ストップ1ビットを表します。送受信の条件が違うと、文字化けだけでなく、受信側がフレーミングエラーを報告することがあります。RTS/CTSなどのハードウェアフロー制御を片側だけ有効にすると、送信が止まったように見える場合もあります。

クロック分周値の計算機は初期見積もりに役立ちますが、整数除算、オーバーサンプリング、分周器の範囲、クロック源の誤差を含めたターゲット固有の動作確認が必要です。計算結果の誤差率だけで合否を決めず、UARTコントローラーと相手デバイスの許容条件、実際の波形、長いデータ列での受信安定性を合わせて確認してください。

起動ログとアプリケーションの出力先を分けて調べる

起動中のログは一つのプログラムから連続して出ているとは限りません。SoCのブートROM、ブートローダー、カーネル、ユーザー空間のサービス、アプリケーションで、使用ポートやボーレートが異なる構成があります。電源投入直後だけ読める、カーネル起動後に途切れる、ログイン後だけ表示される、といった時間の境目を記録し、どの段階から出力が変わったかを切り分けます。

Linuxではカーネルコンソールの指定、デバイスツリーのシリアルポート設定、ユーザー空間のログインサービス、アプリケーションの標準出力がそれぞれ関係します。デバイスファイル名だけを推測して変更せず、対象イメージの起動引数、システム設定、ボードサポート資料で確認してください。製品イメージのログインサービスを変更する場合は、復旧方法とアクセス制御も考慮します。

端末のローカルエコーが有効だと、入力した文字がターゲットから戻ったように見える場合があります。まず受信だけの状態で既知の起動ログを確認し、次に入力時のローカルエコーとターゲット応答を分けて試します。エコーの有無は故障診断の証拠にならないことを意識してください。

よくある質問：ループバックとコンソール設定

USB-UART変換器のTXとRXを互いに接続するループバック試験は、変換器、ドライバー、端末ソフトの基本動作を確認する手段になります。ただしターゲット基板を接続したまま行うと、信号出力同士が競合するおそれがあります。必ずターゲットから切り離し、変換器の仕様と安全な試験方法を確認してから実施してください。ループバックが成功しても、ターゲット側の電圧やピン設定が正しいことまでは証明しません。

設定が分からない場合は、ネット上の一般的な値を順に試すより、基板メーカーのユーザーガイドや製品のビルド設定を確認します。ボードによってデバッグポート、ピン配置、起動ログの有効状態が異なります。資料が見つからない場合は、基板リビジョンとSoC型番を特定し、公式サポート情報を探すのが安全です。

UARTトラブルの試験結果を記録して比較する

UARTの記録では、端末の表示内容だけでなく、送信側と受信側の設定値を別々に残します。ボーレート、データビット、パリティ、ストップビット、フロー制御、ロジック電圧、ポート番号、変換器の型番を一覧にします。波形を測った場合は、測定点、電源電圧、ビット幅、アイドル時のレベル、起動から何秒後に観測したかを記録します。これにより「端末設定を変えたら直った」のか「電圧レベルを変えたのか」を区別できます。

同じ設定で再現試験をする場合は、ボードのリセット方法と起動タイミングもそろえます。ブートログは起動直後の短い時間だけ送られることがあり、端末を開くのが遅いとログを見逃します。自動リセットやポートオープン時の制御線操作がボードのリセットへ影響する構成もあるため、変換器の仕様と評価ボードの回路図を確認してください。

長いデータ列の受信確認では、短い起動メッセージが読めたことだけを根拠にしないようにします。送信元が提供する既知のテストパターンやチェックサムを使える場合は、文字表示と受信データの完全性を分けて検証します。文字コードの解釈が原因なら、波形のフレーム自体は正しくても日本語が正しく表示されないことがあります。バイト列の取得と文字コード変換を別に確認してください。

試験中に設定を変えた場合は、再現できる最小条件を残し、無関係なログや個人情報を含む出力は共有前に除去します。チーム内でよく使うボードなら、確認済みの端子図、端末条件、変換器の型番を開発手順書にまとめると、次回の初期調査を短縮できます。設定値はボードやファームウェアの版に結び付け、版が変わったときに再確認する運用にしてください。

文字化けと無出力をケース別に切り分ける

無出力でTX波形も見えない場合は、まずターゲットが起動しているか、選択した端子がデバッグUARTか、ブート段階でログ出力が有効かを確認します。TXに波形があるのに端末が空白なら、端末が正しいポートを開いているか、信号電圧と極性が適合するか、受信線がターゲットTXへつながっているかを見直します。起動時だけ見逃す場合は、リセット操作の前に端末を接続し、再起動後の出力を記録します。

一定の文字は出るが途中から文字化けする場合は、長いデータ列でクロック誤差が積算していないか、フロー制御により一部の送信が停止していないかを調べます。完全に異なる記号になる場合は、ボーレート、データ形式、信号の極性、電圧レベルの不一致を疑います。日本語だけが崩れる場合は、取得したバイト列を16進表示し、文字コード変換や端末の文字コード設定を別に確認します。表示の見た目だけで電気信号の異常と判断しないようにします。

受信データが欠落する場合は、受信側のバッファ、アプリケーションの読み出し周期、フロー制御線、割り込み処理、ドライバーのエラー統計も調査対象です。発生頻度が低い問題では、再現回数、データ長、システム負荷、温度、接続ケーブルを記録し、同じ試験条件で比較します。設定を一つ変更したら、短い起動ログだけでなく、問題を再現したデータ長と時間で再試験してください。長時間運転や繰り返しリセットを含めた確認は、断続的なノイズやタイミング依存の問題を見つける助けになります。試験結果には、再現しなかった条件も記録し、原因を断定する前に別の個体や構成で再確認します。

UARTで何も表示されないときの確認手順

端末画面が空白のときは、まず「ターゲットが送信していない」のか「信号は出ているがホストが受信できない」のかを分けます。ボードの指定端子に測定器を接続し、電源投入、リセット、操作の各タイミングでTXに波形が出るか確認します。測定時は信号電圧に対応した入力を使い、GNDを正しく共有してください。

波形が見えない場合は、対象ポートの選択、ブートモード、デバッグログの有効化、起動段階ごとの出力先を資料で調べます。別のUART端子を選んでいたり、アプリケーション起動後だけログが有効だったりすることがあります。端末を開いてからボードをリセットし、起動直後の短い出力を取りこぼしていないかも確認します。

TX波形があるのに端末が空白なら、信号の接続方向を送信側から受信側へ追います。ターゲットTXは変換器RXへ接続し、必要な信号GNDを所定の方法で共通にします。端末が正しいポートを開いているか、別のプログラムがポートを使用中でないか、USB-UART変換器のドライバーが認識されているかも確認してください。

端末で入力した文字が見えることを受信成功と誤認しないようにします。ローカルエコーは端末自身が入力を表示する機能で、ターゲットから応答が返った証拠ではありません。受信だけを観察する試験と、ターゲットへコマンドを送る試験を分け、既知の起動メッセージや応答パターンが届くか記録します。

UARTの文字化けを通信条件と文字コードに分ける

文字化けが起きたら、端末表示から通信速度を推測するのではなく、対象ファームウェアの設定値を調べます。ボーレート、データビット、パリティ、ストップビット、フロー制御を送信側と受信側で照合し、変更前の値を記録します。「115200 8N1」と資料にあっても、フロー制御の設定は別項目として確認してください。

波形を取得できる場合は、アイドル時の電圧と極性を確認してから、複数ビットにまたがる時間を測定します。理想的なビット時間はボーレートの逆数ですが、クロック源や分周器の誤差があるため、単一エッジだけで判断しません。測定したビット幅、端末設定、通信が崩れ始めるまでのデータ長を同じ記録に残します。

英数字は正しく見えるのに日本語だけが崩れる場合は、通信フレームと文字コード変換を分けて調べます。受信した生バイトを16進表記で保存し、送信アプリケーションが使う文字コードと端末の解釈を照合します。UARTの信号とフレームが正しくても、バイト列の文字コードが一致しなければ日本語表示は正しくなりません。

一定時間ごとに欠ける、長い送信だけが途中で止まる場合は、RTS/CTSなどのフロー制御線、受信バッファ、ホスト側の読み出し周期も確認します。フロー制御を無効にする場合はターゲット側も同じ条件で動くことを確かめ、端末設定だけを変更して終わらせないでください。取得できる場合は、受信エラー数や欠落位置も保存します。

USB-UART変換器とターゲットを安全に試験する

変換器を選ぶ前に、ボード端子がTTL/CMOSレベルのUARTか、RS-232など別の物理インターフェースかを特定します。名称が似ていても電圧範囲や極性は一致しません。基板の回路図と変換器のデータシートを照らし合わせ、ロジック電圧、入力許容範囲、信号方向を確認します。仕様が分からない端子へ試しに接続する方法は避けてください。

USB-UART変換器には、信号用のTX/RX/GNDのほかにVCC端子がある製品があります。VCCが給電出力なのか電圧選択用なのかを説明書で確認し、ボードの設計で必要とされない限り接続しないでください。異なる電源をつないだまま信号線を接続すると、電源同士の競合や、電源断中の端子からの逆流を生む可能性があります。

変換器のループバック試験はターゲットを完全に切り離して行います。変換器TXとRXを指定どおりに接続し、既知の設定で送ったデータが戻るか調べれば、端末、USB接続、変換器の基本経路を確認できます。ただし成功しても、ターゲットの端子配置、電圧適合性、ファームウェア設定まで正しいとは証明されません。

機器を交換して比較する場合は一度に一つだけ差し替え、変換器の型番、ドライバー、ポート名、電源条件を記録します。USBケーブルやアダプターも同時に変えると、改善した理由を特定しにくくなります。試験終了後は電源を切って配線を外し、ターゲットと変換器に予期しない電圧が残っていないか確認してください。

UARTトラブルの再現試験と記録方法

比較試験では同じボード、ファームウェア、起動操作、送信データを使います。電源投入から観測開始までの時間が異なると、ブートログの有無を比較できません。起動ログが対象なら端末を先に開いてからリセットする手順を固定し、何回試したうち何回で失敗したかも記録してください。

記録表にはボード版、変換器、端子、ロジック電圧、端末名、ボーレート、フレーム形式、フロー制御、日時を含めます。波形を保存する場合は測定点、時間軸、サンプル速度、信号レベルが分かるようにし、設定ファイルや実行コマンドも残します。個人情報や認証情報がシリアルログへ出る構成では共有前にマスキングしてください。

設定を変えるときは一項目ずつにします。例えばボーレートだけを変更し、同じ既知の出力を再取得して比較します。改善しなければ元の値へ戻して次の仮説を試すと、偶然表示された状態を恒久対策と誤認しにくくなります。変更履歴と失敗条件も残せば、別の担当者が同じ候補を繰り返し試さずに済みます。

修正後は短い起動メッセージだけでなく、問題が現れた長さと時間のデータを再送して確認します。連続稼働、複数回のリセット、ターゲットが対応する電源範囲など、用途に関係する条件も試験計画へ含めます。確認していない条件は未検証と明記し、一度表示できたことを製品全体の品質保証として扱わないようにします。

UARTボーレートを測定値と設定から照合する

ボーレートの不一致を調べるときは、送信元の設定値、受信端末の設定値、信号から測ったビット幅の三つを並べます。例えば115200 bit/sなら理想的な1ビット時間は約8.68マイクロ秒です。波形では連続した複数ビットを測定し、短いノイズやスタートビットのエッジを一ビット幅と取り違えないようにします。

実測値が設定とずれる場合は、UART周辺回路へ供給されるクロック、分周器、オーバーサンプリング設定を確認します。計算ツールの値だけを見てレジスター設定を決めず、対象マイコンのリファレンスマニュアルにあるクロック経路、丸め方法、許容誤差を照合してください。同じ公称ボーレートでも、クロック源が異なれば実際の誤差は変わることがあります。

送信側と受信側の許容誤差は、使用するUARTや相手デバイスの仕様で確認します。理論上の誤差率だけで通信可能と断定せず、実際の相手との接続、長いデータ列、想定する温度や電源の範囲で受信エラーを調べます。受信側が示すフレーミングエラーやオーバーランの情報があれば、端末表示と合わせて記録してください。

設定を変更したら同じデータパターンを使い、変更前後のビット幅と受信結果を比較します。ボーレートの調整と同時に配線、電圧、フロー制御を変えると効果を判別できません。改善が見られた条件が製品要件の速度を満たすか、別のボード個体でも再現するかを確認してから恒久設定へ反映します。