デバッグと診断¶
SF32のデバッグはシリアルログから始めます。チップ、SDKリリース、プロジェクト設定によっては、クラッシュダンプ、トレース取得、RT-Threadシェルも利用できます。対象向けに文書化された手順だけを使用してください。
最初に行う確認¶
シリアルコンソールから次の情報を取得します。
- 起動ログ。
- アプリケーションの出力。
- RT-Threadシェルの出力（プロジェクトで有効な場合）。
- 異常メッセージ。
- ダウンロードとリセットの動作。
ログには、ボードリビジョン、SDKブランチ、ビルドコマンド、書き込みコマンド、シリアル設定を添えて保管してください。
デバッグの順序¶
- 同じファームウェアで現象を再現します。
- リセット後に再現するか確認します。
- ファームウェア全体を書き込み直した後に再現するか確認します。
- 最も近いSDKサンプルで再現するか確認します。
- 製品固有の変更を1つずつ戻して追加します。
この順序により、ハードウェア、ボードサポート、ミドルウェア、アプリケーションの問題を切り分けやすくなります。
知っておきたいツール¶
表: 知っておきたいツール
| ツール | 用途 |
|---|---|
sftool |
対応するチップ／ストレージに対するFlashの読み書き・消去やリセットを行うシリアルCLI。オプションはチップとストレージの種類によって異なります。 |
SiFli_Trace |
対象でサポートされる手順に従ってボードのログを取得・確認します。 |
UsartServer |
SF32LB52XとSF32LB56Xで内蔵Debug IPをUART経由でデバッグする際に必要な補助ツールです。他の対象にも適用できるとは限りません。 |
AssertDumpとクラッシュダンプツール |
対象チップとSDKリリースで提供される場合のみ使用し、その版の取得・解析手順に従います。 |
| RT-Threadシェル | プロジェクト設定で有効な場合に限り、実行時の確認やコマンド実行に使用できます。 |
最初に確認する項目¶
表: 最初に確認する項目
| 症状 | 最初に確認する項目 |
|---|---|
| HardFaultまたはアサーション | スタックサイズ、nullポインター、DMAバッファー、キャッシュのメンテナンス。 |
| 周辺機器が応答しない | ピン多重化、クロック、電源レール、ボード名、ドライバーの有効化。 |
| Bluetoothが不安定 | RFクロック、アンテナ経路、Bluetoothスタックの設定、接続パラメーター。 |
| ディスプレイに表示乱れがある | パネルのタイミング、バッファー形式、キャッシュ／DMA同期。 |
| ランダムにリセットする | ウォッチドッグ、電源レール、電圧低下（ブラウンアウト）、スタックオーバーフロー。 |
クラッシュレポートのチェックリスト¶
クラッシュを報告する際は、次の情報を含めてください。
- ボードとリビジョン。
- チップのバリアント。
- SDKブランチまたはコミット。
- 対象のサンプルまたはプロジェクト。
- ビルドコマンドとボード名。
- Flash書き込みコマンド。
- リセット直後からのシリアル起動ログ。
- クラッシュダンプまたはアサーション出力。
- 変更していないSDKサンプルでも問題を再現するかどうか。
最終更新: