SiFli-SDK¶
SiFli-SDK is SiFli's official development SDK for SF32 firmware. It provides an RT-Thread-based development environment and, on supported targets, No-OS examples, along with SiFli-maintained board support and middleware for areas such as Bluetooth, graphics, audio, power management, storage, and production workflows. Availability depends on the chip, board, and SDK release.
SiFli-Solution
SiFli-Solution is a separate SiFli software package and is outside the scope of this page. This page and the linked Develop material document SiFli-SDK only. For SiFli-Solution's scope, supported devices, and access requirements, consult the official SiFli Solution Documentation and contact SiFli directly.
Use the SiFli-SDK Getting Started page for first installation and hello_world. This page explains how to think about the SDK once the toolchain already works.
Primary references:
When to Use SiFli-SDK¶
Choose SiFli-SDK when you need:
- A documented development path with SiFli-maintained board support and examples for your target chip and SDK release.
- Examples and middleware for Bluetooth, display, audio, power, storage, USB, and OTA where supported by the selected target and release.
- RT-Thread integration and shell tooling.
- Board-level configuration through SDK board names such as
sf32lb52-lcd_n16r8. - Access to SiFli-specific middleware, tools, partition layouts, and production flows.
Development Model¶
The SiFli-SDK Getting Started page establishes the toolchain and a hello_world baseline. After that, keep the SDK revision, selected board, example/project directory, configuration, and corresponding build/download artifacts together in a reproducible build record. When the board name omits a core suffix, the HCPU output commonly follows build_<board_name>_hcpu/; for example, sf32lb52-lcd_n16r8 produces build_sf32lb52-lcd_n16r8_hcpu/. Use the actual directory generated for the resolved board/core target rather than constructing its name manually.
For repeatable development, pin an SDK branch, record the board name, keep local board changes separate from vendor files, and make configuration changes in small, reviewable steps. The detailed build, download, and monitoring workflow is in Build, Flash, Monitor.
Board Names¶
SiFli-SDK board names are SDK-specific and may not match Zephyr board names, Arduino FQBNs, or marketing board names. Always copy the board name from the SDK supported-boards list or from the example documentation.
For SF32LB52 DevKit LCD boards, a common SDK board name used in quick-start examples is:
Project Structure¶
Most SDK examples follow the pattern:
For example:
When building product firmware, start from the closest working SDK example and change one subsystem at a time. That keeps board configuration, middleware dependencies, partition assumptions, and driver setup intact.
Configuration¶
For an example project, use the SDK's menuconfig command to change its feature configuration for a selected board:
Common reasons to enter configuration:
- Enable or disable middleware.
- Change Bluetooth roles or profiles.
- Adjust display, filesystem, or audio support.
- Tune power management.
- Select logging or shell options.
Production Readiness Questions¶
Before committing to SiFli-SDK for a product branch, answer:
- Which SDK release branch is frozen for the product?
- Which board support files are product-owned vs. vendor-owned?
- Which examples prove the critical features?
- Which partition table is used for manufacturing and OTA?
- Which tools are approved for factory flashing?
- Which logs are enabled in release builds?
- Which recovery image is kept for lab use?
Practical Next Pages¶
- Build, Flash, Monitor
- Board Configuration
- Components and
sf-pkg - Examples — choose the closest known-good baseline before adapting a subsystem.
- CodeKit — use the VS Code workflow when useful, while keeping the SDK board name and build records consistent with the rest of the project.
- SDK Application Notes
- Partition Tables
- Debugging and Diagnostics
Last updated: