メインコンテンツまでスキップ

Seeed Jetson クロスプラットフォーム デバッグガイド

🔧Jetson クロスプラットフォーム デバッグガイド

Seeed Studio の Jetson キャリアボード全シリーズ向けに設計されており、Windows / Linux / macOS プラットフォームをカバーします。
シリアルデバッグからシステムモニタリングまで、ブート失敗、カーネルクラッシュ、フラッシュ問題に対するワンストップソリューションを提供します。

🎯 ドキュメント概要​

このガイドは、Seeed Jetson 全シリーズキャリアボード向けに特別に設計されており、NVIDIA 公式のデバッグ仕様と Seeed ハードウェアの特長を統合して、統一されたクロスプラットフォームデバッグソリューションを提供します。

対象範囲：シリアルデバッグ · ブートログ解析 · システムモニタリング · ハードウェアレベルのトレース · フラッシュ & リカバリ

対応ハードウェア

reComputer Super / Classic / Mini / Robotics · reComputer Industrial · reServer Industrial · J501 シリーズ

📚 公式コアリファレンスリソース​

No.リソース名リンクコアバリュー
1Jetson Linux Developer GuideNVIDIA Officialシステムアーキテクチャ、ブートプロセス、UART 設定
2Jetson ハードウェア仕様 / 回路図NVIDIA Download Centerデバッグインターフェースのピン定義、電圧規格
3Seeed Studio WikiSeeed OfficialSeeed キャリアボードのデバッグポート位置、インターフェース説明
4NVIDIA SDK ManagerNVIDIA Officialグラフィカルなフラッシュ、環境構築
5CoreSight ハードウェアデバッグドキュメントJetson Linux Debug 章Arm ハードウェアトレース、クラッシュ解析

🛠️ デバッグ前提条件​

ハードウェア準備​

  • Seeed Jetson 開発ボード（正常に給電されていること）
  • USB データケーブル（キャリアボードのモデルに応じて USB-C または Micro-B を選択） / 3.3V USB-UART モジュール
  • ホストコンピュータ（Windows / Linux / macOS いずれか）

ソフトウェアツール（クロスプラットフォーム）​

システム推奨ツール
WindowsPuTTY / MobaXterm / Device Manager
Linuxscreen / minicom / picocom
macOSscreen / minicom

🔌 UART シリアルデバッグ（コア）​

UART シリアルポートは Jetson デバッグのローレベル入口であり、完全な Bootloader とカーネルブートログを確認でき、ブラックスクリーン、起動失敗、シリアルポート占有などのコアな問題を解決できます。

電圧に関する警告

すべての Seeed Jetson デバッグポートは 3.3V レベルです。5V モジュールの使用は厳禁であり、使用するとデバイスが永久的に破損します！

各シリーズのデバッグポート接続方法​

お使いのデバイスシリーズを選択して、対応するデバッグポート位置と接続方法を確認してください：

対応モデル：reComputer Super J4012 / J4011 / J3011 / J3010

デバッグポート種別：オンボード USB-C デバッグポート

接続方法：

  1. USB Type-C データケーブルを使用して、キャリアボードのデバッグポートとホストの USB ポートを直接接続します
  2. 追加の UART モジュールは不要で、接続するだけで使用できます
reComputer Super
デバッグポート位置

Super シリーズのデバッグポートは、USB-C コネクタのある筐体側面に位置し、DEBUG または UART と表示されています。接続後、ホスト側ではシリアルデバイスとして認識されます。

クロスプラットフォームでのポート識別​

デバッグケーブルを接続した後、ホスト側でシリアルデバイスを特定します：

Device Manager を開き → Ports (COM & LPT) を展開 → 対応する USB Serial Port の COM 番号（例：COM3）を確認します。

ModemManager によるシリアルポート占有の修正（Linux）​

Linux 固有の問題

Linux ホスト上の ModemManager サービスが Jetson のデバッグシリアルポートを誤って占有し、接続失敗を引き起こすことがあります。

# Troubleshoot port occupation
sudo lsof /dev/ttyACM0

# Temporarily stop service (recommended)
sudo systemctl stop ModemManager

# Permanently disable (when 4G/5G module is not needed)
sudo systemctl disable ModemManager

udev ルールを設定する（sudo 不要でシリアルポートへアクセス）:

sudo vim /etc/udev/rules.d/99-tegra-serial.rules

次の内容を追加します:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0955", MODE="0660", GROUP="plugdev", TAG+="uaccess"
sudo udevadm control --reload-rules && sudo udevadm trigger

シリアル接続（ボーレート: 115200）​

PuTTY を使用する場合:

  1. 接続タイプとして Serial を選択
  2. COM 番号を入力（例: COM3）
  3. ボーレートを 115200 に設定
  4. Open をクリック

または MobaXterm を使用: New Serial Session → COM ポートを選択 → ボーレートを 115200 に設定

🚀 システム起動とカーネルデバッグ​

UART シリアルポートを通して、Jetson の起動ログを完全に取得し、起動ハング、カーネルクラッシュなどの問題を特定できます。

起動の 3 段階​

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Bootloader     │ →  │  Kernel Boot     │ →  │  System Init     │
│  CBoot/U-Boot   │    │  Linux Load Drivers│   │  systemd Service│
│  Serial Only    │    │  Core Debug Info  │    │  User Mode      │
└─────────────────┘    └──────────────────┘    └─────────────────┘

完全な起動ログを有効化​

デフォルトでは、quiet パラメータにより多くのログが非表示になります。次の手順で有効化できます:

  1. 起動設定ファイルを編集します:
sudo vim /boot/extlinux/extlinux.conf
  1. APPEND 行を見つけ、quiet を削除し、ignore_loglevel を追加します
  2. 再起動後、シリアルポート経由で完全なカーネルログを確認できます
リモート環境

SSH で接続できる場合は、カーネルログを直接確認することもできます:

dmesg --follow
journalctl -k -f

📊 システムモニタリングと高度なハードウェアデバッグ​

tegrastats — リアルタイムシステムモニタリング​

tegrastats は、CPU/GPU 使用率、温度、周波数などを確認できる、NVIDIA 公式の Jetson システムモニタリングツールです:

# Real-time monitoring
tegrastats

# Customized output (1 second refresh, total 10 times)
tegrastats --interval 1000 --stop 10

jtop — 強化されたビジュアルモニタリング​

jtop は対話的な TUI インターフェースを提供します。インストール方法:

sudo pip3 install -U jetson-stats
sudo systemctl restart jtop.service
jtop

CoreSight ハードウェアレベルデバッグ（上級）​

再現が難しいクラッシュやパフォーマンスボトルネックの解析に使用され、OpenCSD + perf ツールに基づいています:

# Record instruction execution flow
perf record -e cs_etm/@<trace-id>/u ls

# Analyze logs
perf report --stdio --dump
備考

CoreSight は STM（System Trace Macrocell）をサポートしており、printk によるソフトウェアデバッグを効率的に置き換えることができます。詳細な設定については、NVIDIA 公式デバッグドキュメント を参照してください。

🔄 フラッシュ & リカバリ​

システムがクラッシュしたり起動しなくなった場合は、公式ツールを使用して再フラッシュできます。

クイックフラッシュガイド

詳細なフラッシュ手順については、Flashing Jetson Linux ページを参照してください。ここでは、以下を含むデバイス別の完全なフラッシュガイドを提供しています:

  • BSP のダウンロードと検証
  • 環境の準備
  • デバイス別のフラッシュ手順
  • よくある問題のトラブルシューティング

リカバリモードの確認​

フラッシュ前に、デバイスがリカバリモードに入っていることを確認してください。Ubuntu ホスト上で実行します:

lsusb

出力に次のいずれかの ID が含まれていれば、デバイスはリカバリモードに入っています:

モジュールUSB ID
Orin NX 16GB0955:7323
Orin NX 8GB0955:7423
Orin Nano 8GB0955:7523
Orin Nano 4GB0955:7623
AGX Orin 32GB0955:7223
AGX Orin 64GB0955:7023
Xavier NX0955:7e19
リカバリモードへの移行

デバイスごとにリカバリモードへ入る方法は異なります。対応するデバイスの詳細な手順については、Flashing Jetson Linux ページを参照してください。

フラッシュ時のデバッグログ​

フラッシュに失敗した場合は、トラブルシューティングのために必ず次の 2 種類のログを収集してください:

  1. ホスト側: フラッシュを実行したターミナルの完全な出力ログ
  2. ターゲット側: UART シリアルポートで取得した Jetson の起動ログ（コアとなる解析の基礎）
デバッグのコツ
  • フラッシュに失敗した場合は、まず UART シリアルポートのログを確認してください。多くの場合、ここに根本原因が現れます
  • よくある問題には、BSP バージョンの不一致、USB 接続の問題、ホスト環境の設定不備などがあります
  • サポートが必要な場合は、完全なログを収集してからテクニカルサポートへお問い合わせください

❓ よくある問題のトラブルシューティング​

問題トラブルシューティングの方向性
シリアル接続に失敗するModemManager サービス、USB ケーブル、ポート番号、電圧規格（3.3V）を確認
起動ログが出力されないデバッグポートが正しく接続されているか確認；カーネルの quiet 起動パラメータを削除
フラッシュに失敗するUART シリアルポートのログを優先的に確認；キャリアボードのモデルと JetPack バージョンが一致しているか検証
シリアルポートの権限が不足しているudev ルールを設定；sudo usermod -aG plugdev $USER
デバイスがリカバリモードに入れないジャンパ/ボタンの設定が正しいか確認；USB ケーブルやポートを変更して試す

📎 付録: 公式リソース​

📖 Developer Guide

NVIDIA Jetson Linux 公式開発者ガイド。システムアーキテクチャ、起動プロセス、デバッグ設定などを解説しています。

Jetson Linux Guide

🌱 Seeed Wiki

Seeed Studio 公式 Wiki。全キャリアボードシリーズのハードウェアインターフェース説明と使用チュートリアルを収録しています。

Seeed Studio Wiki

🔧 SDK Manager

NVIDIA 公式のグラフィカルなフラッシュおよび SDK 環境構築ツールです。

NVIDIA SDK Manager

🤝 テクニカルサポートと製品ディスカッション​

弊社製品をお選びいただきありがとうございます。ご利用中の体験がスムーズになるよう、さまざまなサポートを提供いたします。

Loading Comments...