Use the Silicon Labs Configurator Command-Line Interface (SLC-CLI)#

slc --help provides details on usage and a list of available commands. slc \<command\> -h shows all options for the command.

SLC-CLI Configuration#

SLC-CLI can use default option values from a .slconf file, either through the --slconf option or automatic discovery. Use a .slconf file to define shared defaults. Command-line options take precedence over values in the file. For information about option precedence, file structure, and examples, see Using .slconf with SLC and Project Generation Examples.

If you are setting up an SDK and toolchain for the first time, see Set Up Your Development Environment and Troubleshoot Environment Issues.

You can also set defaults using slc configuration:


Operation	Example	Description
configuration	`slc configuration --sdk="C:\sdk\sdk.slcs"`	Sets the given SDK to be default available (unless explicitly overridden in other commands). Any command that requires an SDK parameter will no longer require it, and will instead use this configured default. This either points directly to an .slcs file, or it points to a folder containing an .slcs file. Supplying an empty string (--sdk="") clears this value. May be set to a relative value. If this value is set and an override path is provided in the generation operation, the override is used.
	`-e, --examine`	Prints the current configuration file and its location.
	`-gcc, --gcc_toolchain "C:\path\to\gcc"`	Sets the default GCC toolchain path for use with the Makefile generator. This should point to the directory that contains the bin and lib folders.

General Options#

These global options can be specified after an SLC command. Use --slconf <path-to-file.slconf> to select a configuration file for that invocation.


Option	Example	Description
`-v, --verbose`	`-v INFO`	Sets verbosity. Values: SILENT, ERROR, WARNING, INFO, DEBUG, TRACE.
`--slconf`	`--slconf project.slconf`	Overrides automatic `.slconf` discovery for this invocation.
`--no-daemon`	`--no-daemon`	Runs without connecting to or starting the beta daemon.

Project Operation Options#

All project-level operations listed in Project Operations below can accept the same basic arguments enumerated here.


Option	Required	Example	Description
`-p, --project-file`	yes, may be a positional parameter instead	-p blink.slcp	The actual project file that any project operations will be working against.
`--with`	no	--with brd3200c,micriumos --with pwm:led0:led1,brd2200a	Comma-separated list of components to include in the project in addition to components enumerated by the .slcp file itself and in addition to any auto-computed dependencies. If a component is instantiable, then the instance names must be supplied separated by ':', with the first of the ':' separated list being the actual id, and subsequent ones being instance names.

Project Operations#

Project operations always specify an SDK to load from as well as a project file <project_name>.slcp to draw from. You must specify an SDK (-s or --sdk) for every project operation unless you have configured a default SDK.


Operation	Example/Arguments	Description
generate	`generate -p="blink/blink.slcp" -d="blink/output/blink_project"`	Generates the project to the given destination. By default this links all sources. Destination is not required. If not specified, then the slcp directory is used.
	`-d, --destination=DESTINATION`	Location for generated project or workspace output. If not provided, the `.slcp` or `.slcw` location is used.
	`-name, --project-name`	Overrides the project name in the slcp. This determines some output file names and the generated binary names.
	`-o, --output-type=OUTPUT_TYPE`	The output of the generation, effectively what kinds of files should be generated and for what tools/IDEs.
	`--force`	Forces operation to continue in the presence of validation errors.
	`--configuration=CONFIGURATION_OVERRIDE_MAP`	Provides the same function as ‘configuration’ in the .slcp but command line options take precedence. Takes a comma-delimited list of changes in the format “configuration_name:value”. The same configuration cannot be referenced more than once on the command line.
	`-cp, --copy-sources`	Copies all files referenced by this project, selected components, and any other running tools (Pin Tool, etc.). By default, no files are copied.
	`-cpproj, --copy-proj-sources`	Copies all files referenced by the project and links any SDK sources. Can be combined with -cpsdk.
	`-cpsdk, --copy-sdk-sources`	Copies all files referenced by the selected components and links any project sources. Can be combined with -cpproj.
	`-nocp, --no-copy`	Causes all files to be linked into the generation location. Only generated files will exist in the generation location. Cannot be used with any other copy operation.
	`-np, --new-project`	Runs the new project creation layout. This runs a standard generation step and then copies over any project sources (slcp, config folder, etc.), fixing any paths in the slcp file to point to the new location of the files. This defaults to -cpproj.
	`--exporter-templates=EXPORT_TEMPLATES_FOLDER`	Location of custom exporter templates.
	`-tlcn, --toolchain`	Generates for the specified toolchain. The toolchains are not treated in the same way as components and so do not appear selected in the project. The current valid selections are gcc and iar.
	`-tools, --config-tools=<tools>`	Specifies the tools to be generated based on the file extension. If this is not provided, then all active tools will generate. You may list more than one tool extension separated by commas.
	`-lfewp, --list-files-ewp`	Forces the IAR EWP generator to define all SLC contributed sources in the .ewp file as well as the .ipcf file. This mimics the IAR Project Connection support in IAR Embedded Workbench and is useful for Linux builds of IAR, which do not support *.ipcf files.
	`--generator-timeout=TIMEOUT_SECONDS`	Overrides the default 30s timeout for each generation cycle. One call to generate may include multiple generation cycles, so this total generation time could be multiples of this timeout.
	`-s, --sdk=SDK_PATH`	Location of either the sdk folder containing the .slcs file, or the file itself. This is only required if no default sdk is set using 'slc configuration -s SDK_PATH'. If an sdk is supplied here and one is configured as default, this one takes precedence.
	`--with=COMPONENT_LIST`	Accepts a comma-separated list of component IDs to add. Use `:` after a component ID to specify instances, for example `pwm:led0:led1`. Qualify extension components with dot-separated vendor, package, and component IDs, for example `silabs.arc.pwm:led0:led1`. Shorter qualified forms are allowed when they identify one component unambiguously.
	`--without=COMPONENT_LIST`	Accepts a comma-separated list of component IDs to remove. Instance and extension component identifiers use the same syntax as `--with`. `--without` runs after `--with`; a component present in both lists is not added.
validate-project	`validate-project -p="blink/blink.slcp"`	Validates if a project would generate, essentially a dry run of generation. If the project is invalid, more information (such as a dependency tree) is output, indicating what and why it failed to auto-select all required dependencies, and what was missing. Python validation is not run by default.
validate-project	`--config-location <cfg_location>`	Tells the configuration validation scripts to run using the specified config folder for the project. Configuration files on that path will contribute their configuration values. The rule is that, if a configuration value appears in a config file on this path, it is considered the ultimate user configuration and overrides any default values.
summarise, summarize	`summarize --project blink.slcp`	Shows a summary of all components that make up a project, including both those explicitly set in the .slcp, and those implicitly brought in via dependency resolution.
	`--why`	Summary of implicit components will be replaced with a long list of implicit components that include why they were brought in (the component that needed them, and the API rule.) In many cases, the component name and API ID are identical, but essentially the left side of 'for' is the component ID, and the right side is the API(s).
	`--api`	An additional list is provided at the end of the summary showing every API that is provided by the project. In other words, every selected component put together will form a total set of available API.
graph	`graph --project blink.slcp` `graph --project blink.slcp` `--validate` `--focus "emlib_common, cmsis_core"`	Shows a dependency graph instead of the inverted dependency system that `summarise --why` shows. This dependency graph is represented as a tree, where the first occurrence of a component shows that component's dependencies as well, but subsequent occurrences show only a '^', indicating that a deeper dive has been done earlier in the tree. This is essentially a compromise solution, since dependency graphs can otherwise be very web-like. Color and non-color systems both support drawing attention in their own way to different things. Any component that provides an API other than itself will have that API listed after its name if that API is responsible for providing something another component in this project required. Any component that appears as a 'child' to itself will show a green '[Cycle]' phrase. Cycles do not prevent dependency management from working. This merely calls attention to them.
	`--validate`	Option to show validation issues in-line with the dependency graph. Validation issues are prefaced with an '!' and, if color is supported, are red.
	`--focus`	Draws attention to a specific component/component(s) via either color or text, wherever they appear in the tree.
clone	`clone --target emlib --destination project_sdk_extension --author neo_politan`	Clones SDK components for developers who wish to use a component in a slightly modified form. Takes care of ensuring all referenced files and other data is copied so that the cloned components are self-contained. To use the resulting clone, place it in a new SDK extension.
	`--destination`	The location that the component will be cloned into. The component's slcc and directly required files will be cloned to this location.
	`--target=TARGET_COMPONENT_ID`	The component to be cloned. Referenced files will be copied along with the .slcc, and the project search paths will be updated and saved. Clone data is automatically added based on the current system's date.
	`--author "Fozzy Bear"`	If the optional author option is specified, the cloned component's author field in the .slcc is updated.
upgrade	`upgrade "blink.slcp"`	Upgrades the given project in place. If no upgrade rules report verification is needed or an upgrade is impossible, this modifies the project and the config folder in the same folder as the project. Does nothing if no config folder exists or the upgrade cannot complete properly. .bak files are created as backups for all files affected by the upgrade.
	`--dry-run`	Runs the upgrade up to the point where the temporary configuration files that have been modified would be merged into the project, but stops short. It reports any issues upgrading, but even if there none, it will not actually modify the project.
	`--verified`	If any upgrade rules indicate that 'verification is required', passing this allows the upgrade to take place.
sbom	`--all-components=<allSdkComponents>[,<allSdkComponents>...]`	Add every component from a comma separated list of input SDK or extension path to the SBOM. This is a utility command that is fully equivalent to `--with=<every_component>`. This cannot be specified with the `-p` command.
	`--cyclone-json`	The CycloneDX JSON output format.
	`--cyclone-xml`	The CycloneDX XML output format.
	`--spdx-default`	The SPDX default (tag:value) output format.
	`--spdx-json`	The SPDX JSON.

Work with SDKs#

These commands provide information about the components (.slcc files) included in an SDK.

SDK Options#

These options are shared among all SDK commands.


Option	Example	Description
-s --sdk	`-s '/sdk/sisdk'`	Indicates the location of the primary SDK to use. This option overrides the global SDK configuration. If no SDK is configured (see above for Configuration) then this option becomes required. This either points directly to the .slcs file, or it points to a folder containing that file.

SDK Operations#


Operation	Example/Arguments	Description
where	`where micriumos`	Displays the location of a component based on the name. This is a subset of the information in examine.
examine	`examine micriumos`	Displays information about a component, such as where it is defined in the SDK, sources, provided APIs, and all additional metadata defined in the yaml itself.
validate	`validate sdk/platform/component/rtx.slcc`	Validates the .slcc file only, without validating anything else in the SDK. This ensures it is both proper yaml, and that it makes no semantic errors (such as missing required fields, misnamed fields, junk fields, or incorrect types).
show-available	`show-available toolchains [component option]`	Shows available toolchains and/or project types to use with generate or all distinct values for a component option (quality, provides, category, etc.).
prune	`prune --with brd2204a,EFM32GG11B820F2048GL192`	Returns a list of component IDs that are not conflicting with the given components. This is most effectively used to filter out components that would not work on certain hardware. Unlike slc choices, this is not intended to help fix validation errors, but rather to show everything that one could possibly add to a project given the current constraints. This uses the project-level `--with` commands. A project may still be specified, however, in which case the total components in the project are treated as the input to this command. Note: Using `--with` instead of an `.slcp` means including the components on the command line only. No dependencies are automatically resolved! If used directly with `.slcp` files, project dependencies are resolved as normal.
prune	`--trace`	After displaying all available components that could be added, shows a (typically very long) section afterwards of everything that was filtered out due to conflicts of dependencies, and then a list of APIs that are subsequently unavailable. The unavailable API list includes 1 to many OR-listings of requirements that would have had to have existed for the API to be acceptable for this project.

Daemon Mode#

The SLC CLI can be run as a daemon. In this mode, the application is launched and remains open to service further commands. This reduces the time to service any given command, especially those which require loading the sdk (which is most of them). To run a command in daemon mode, add --daemon to any command, after the slc but before the command itself. For example, slc --daemon generate neo_politan.slcp -d gen_destination. If the daemon is not currently running, it will start. If it is, it will merely connect.

The daemon mode was built to scale with Continuous Integration and Continuous Development (CI/CD) systems that may be running many operations at once. As such, it is enough to just add --daemon to any command, and SLC CLI will automatically handle what it needs to ensure that if multiple calls are all attempting to start the daemon, only one will win and service every call.

Daemon Mode Considerations#

The SDK that is loaded when the daemon first launches, as configured by slc configuration, is the assumed default for all future commands until the daemon is shut down.
When using the daemon for CI/CD flows:
- It is recommended that every command references the --sdk directly and does not rely on any configuration.
- Run all slc signature trust commands with the --daemon option.

Shut Down#

The daemon will automatically shut down in two scenarios (outside of crashes):

If a bug occurs where a daemon is launched but not connected to, the daemon process will end after 30 seconds.
After the daemon has serviced at least one command, and it has been more than 30 minutes since the last command. This timeout can be adjusted.

The daemon can be manually shut down by issuing the following command:

slc --daemon daemon-shutdownslc --daemon daemon-shutdown

Daemon Options Reference#

The following are supported daemon-specific options that apply to the daemon connections themselves. As with --daemon they should be used before the slc command.


Option	Example	Description
--do-not-launch-daemon		Will attempt to connect to an existing daemon, but will fail if none is present (in other words, it will not attempt to start up a daemon if one is not available).
--daemon-timeout=TIMEOUT		How long, in minutes, the daemon will stay alive after servicing a request before it automatically shuts down.
--daemon-only		If set, the daemon will not attempt to use a direct call to fallback. Under normal circumstances, if something goes wrong attempting to connect to a daemon, then SLC CLI is launched directly to service whatever command it was given. This fallback may be considered more of a problem than a solution in some cases, such as system testing. If this is set, the launcher will never attempt to do a direct launch of SLC CLI, and fail immediately if anything goes wrong attempting to either start, or connect to, a Daemon.
--reload-sdk		Reload the SDK from the input location from disk. Users should call this if the SDK has changed on disk and SLC is currently running in Daemon mode.

Workarounds#

When SLC CLI has issues with daemon mode, it will try to fall back to servicing the command as if daemon mode was not requested. In the event of instability, try the following:

Check the user directory's .uc/cli folder for data directories (cli ones should be cli_pdata.) Delete all of the data directories. Normally, the launcher should delete .running files that are stale (empty and never getting filled in) or refer to dead process ids, but if a daemon has hung in an unexpected way and simply cannot respond, this is the easiest way to remove it from consideration.
Check if there are any stray .lock files in any data directories, and delete them if they exist.