ログの取得とクラッシュ解析¶
SDKのdebug_loggingとcrash_analysisのガイドは相互に補完します。ログからは2つのコアが何をしていたかが分かり、取得したメモリーイメージを使うとデバッガーで障害時のコンテキストを復元できます。各取得データには、対応するELF、マップ/シンボルファイル、SDKリビジョン、チップ型番、設定、ボードリビジョンを必ず添付してください。
デバッグ接続を選ぶ¶
表: SF32ファミリー別のデバッグ/ログ接続
| ファミリー | デバッグとログの方法 |
|---|---|
| SF32LB52x、SF32LB56x、SF32LB58x | SiFliのガイドでは、UARTでの取得、SifliUsartServer/AssertDumpUart、J-Link/Trace32による実行コンテキストの復元方法が説明されています。選択したスリープ状態でも利用できる転送手段を選んでください。 |
| SF32LB55x | $SDK_ROOT/tools/segger/jlink_hcpu_a0.batとjlink_lcpu_a0.batでSWD接続先をHCPU/LCPU間で切り替えられます。LCPUのROMコンソールはUART3、1,000,000 baudです。HCPUではUART1/2またはSWDを使えます。SWDはPB IOを使うため、接続中はLPSYSをアクティブまたはLight Sleep状態に保ってください。 |
LPSYSがスタンバイから復帰すると、SWDはHCPUに戻ります。J-Linkのリセット操作だけでは、選択コアは切り替わりません。非同期ログを有効にしているとアサーションダンプが途中で切れることがあります。障害時には同期取得、またはデータを保持できる取得方式を使ってください。
実行中の障害情報または事後解析用データを取得する¶
現行SDKリリースでは、sdk.pyを使ってUARTまたはJ-Link経由で取得します。
コマンド例の適用範囲
以下のコマンドはSF32LB52/LB525の例です。コマンド構成はそのままにし、チップ/モデル、コア、転送手段、ELFを対象ファミリーとSDKリリースに合う値へ置き換えてください。
sdk.py crash-dump capture-live --transport uart --probe /dev/ttyUSB0 \
--chip SF32LB52 --chip-model LB525 \
--output /tmp/live-crash --elf build_hcpu/main.elf
対象がPSRAMを使う場合は--include-psram --psram-size 8MBを追加します。J-Linkプローブでは--transport jlink --jlink-ip 127.0.0.1:19025を使えます。--core hcpuまたは--core lcpuで対象コアを選択します。出力ディレクトリには、取得したバイナリー、対象コアのELF/AXF、log.txt、manifest.json、sdk_manifest.jsonが含まれているはずです。
古いSDKでは、各ファミリーのガイドに記載された方法を使ってください。
- UART: コンソールを使える状態であれば、
SifliUsartServerまたはAssertDumpUartでアサーションデータを出力できます。 - J-Link/SWD: J-Linkを
PATHに追加し、対象ファミリー用のスクリプトを実行します。たとえばSF32LB55xでは$SDK_ROOT/tools/crash_dump_analyser/script/save_ram_55x.batを使います。対応するスクリプトでRAM、EPICレジスター、PSRAMを保存できます。 - ヒープリークを調べる場合は、
RTOS → RT-Thread Kernel → Memory Management → Enable memory traceを有効にします。
スクリプトで取得する場合は、.jlinkファイルを対象ファミリー、PSRAM構成、接続方式に合わせてください。SifliUsartServer経由のIP接続ではIP用スクリプトを、J-LinkをUSBで直接接続する場合はUSB用スクリプトを使います。接続方式とスクリプトが一致しないと取得に失敗することがあります。

UARTで取得する場合、シリアルユーティリティ、サーバーアドレス、対象コアを一致させる必要があります。次の画面例は接続確認に役立ちます。



実行コンテキストを復元して解析する¶
取得したパッケージをデバッガーで読み込めるコアファイルに変換し、対応するELFで解析します。
sdk.py crash-dump readcore --package /tmp/live-crash \
--elf build_hcpu/main.elf --output /tmp/live-crash/coredump.elf
sdk.py crash-dump analyze --core /tmp/live-crash/coredump.elf \
--elf build_hcpu/main.elf
従来のTrace32手順では、HCPUアサーションデータをHCPU assertion (HA) ボタンとrun_next_stepで読み込みます。LCPUダンプにはLCPUのコンテキスト復元用設定を使います。例外スタックが表示されない場合、レジスターを解釈する前にコア選択、ELF、メモリー範囲を確認してください。


起動初期や競合の疑いがある箇所で停止する¶
初期化をデバッグするには、対応するReset_Handlerの先頭命令のコメントを外してB .にします。
次のスタートアップファイルのパスはSF32LB55xのガイドに記載されたものです。他のファミリーでは対応するスタートアップファイルを使ってください。
- HCPU:
$SDK_ROOT/drivers/cmsis/sf32lb55x/Templates/arm/startup_bf0_hcpu.S - LCPU:
$SDK_ROOT/drivers/cmsis/sf32lb55x/Templates/arm/startup_bf0_lcpu.S
J-Linkを接続し、実行を再開するにはPCを2バイト進めます。Cでは_asm("B .");で同じ意図的な停止を作れます。while (1);に置き換えないでください。ループ以降のコードがコンパイラーにより最適化で取り除かれる場合があります。
取得データを読む¶
アサーションダンプには通常、アサーション関数と行番号、スレッド表、メールボックスとメッセージキューの状態、ミューテックス、セマフォ、ヒープ使用量、CPUレジスターが含まれます。障害時のPCを正確なELFと照合したうえで、スタックの余裕、待機対象となっているリソースの所有者、キュー項目、障害直前のログを確認します。シンボル化する前に、未加工のダンプを保存してください。
対話的に調査する場合は、OzoneにHCPU/LCPUのELFと、$SDK_ROOT/tools/svd_externalにあるFPU搭載Cortex-M33用のSVDを読み込みます。対象コアの状態によってSWD接続できない場合は、UARTまたはSifliUsartServerを使ってください。ULOGはUARTで出力できます。Segger RTTを使うには、RTTサポートを有効にしたうえでRT-Threadのログデバイスにseggerを選びます。
バス/メモリー障害を計測する¶
SDKのバスモニターで、バスフォルトにつながるアクセスを取得できます。dbg_busmon_reg_callbackでコールバックを登録し、ガイドの例にあるdbg_busmon_readとdbg_busmon_writeを使って対象アドレス範囲を調査します。ヒープトレースとクラッシュデータを組み合わせてください。シンボルやメモリーコンテキストのないレジスターダンプだけでは、ほとんどの場合、十分な情報が得られません。

公式ファミリー別資料: SF32LB52xのクラッシュ解析、SF32LB55x、SF32LB56x、SF32LB58x、および対応するデバッグ/ログガイド。
最終更新: