Debugging and Diagnostics¶
Start SF32 debugging with serial logs. Depending on the chip, SDK release, and project configuration, you may also have crash-dump tools, trace capture, and an RT-Thread shell; use only workflows documented for the target.
First-Line Debugging¶
Use the serial console to collect:
- Boot logs.
- Application prints.
- RT-Thread shell output, if enabled in the project.
- Fault messages.
- Download and reset behavior.
Keep logs with board revision, SDK branch, build command, flash command, and serial settings.
Debugging Order¶
- Reproduce with the same firmware.
- Reproduce after reset.
- Reproduce after full reflash.
- Reproduce from the closest SDK example.
- Add product changes back one at a time.
This helps separate hardware, board-support, middleware, and application issues.
Tools to Know¶
Table: Tools to Know
| Tool | Use |
|---|---|
sftool |
Serial command-line utility for supported flash read/write/erase and reset operations; options depend on chip and storage. |
SiFli_Trace |
Capture and inspect target-board log output using the workflow supported by the selected target. |
UsartServer |
Required companion for the documented UART-debug workflow through the built-in Debug IP on SF32LB52X and SF32LB56X; do not assume it applies to every target. |
AssertDump and crash-dump tools |
Use only when provided for the chip and SDK release; follow that release's documented capture and analysis procedure. |
| RT-Thread shell | Runtime inspection and commands only when the project configuration enables the shell. |
What to Inspect First¶
Table: What to Inspect First
| Symptom | First checks |
|---|---|
| Hard fault or assert | Stack size, null pointers, DMA buffers, cache maintenance. |
| Peripheral unresponsive | Pin mux, clock, power rail, board name, driver enable. |
| Bluetooth unstable | RF clock, antenna path, Bluetooth stack configuration, connection parameters. |
| Display artifacts | Panel timing, buffer format, cache/DMA synchronization. |
| Random reset | Watchdog, power rail, brownout, stack overflow. |
Crash Report Checklist¶
When reporting a crash, include:
- Board and revision.
- Chip variant.
- SDK branch or commit.
- Exact example or project.
- Build command and board name.
- Flash command.
- Serial boot log from reset.
- Crash dump or assert output.
- Whether the issue reproduces on a clean SDK example.
Last updated: