Usage#

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 operations are based on the context of a specific SLC-compatible SDK. It is recommended to first configure SLC-CLI to use a specific SDK by default.

1. Configure SLC-CLI to a specific GSDK location, for example:

   slc configuration --sdk users\<NAME>\SimplicityStudio\SDKs\gecko_sdk

   Then all commands that use an SDK will use this configured location. If you do not do this, you must specify the SDK path with the - -sdk option each time you issue a command, such as generate discussed below.

2. If using GNU toolchain from the command line (for example, with a GNU Make build system), first configure your GCC location.

   slc configuration -gcc=\path\to\your\GNU\ARM\embedded\toolchain

   Note: If you do not already have a GNU toolchain installed, you can download the proper version (aligned with what your SDK supports) from here: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads. See the release notes for your SDK version for compatible compilers.

Example - SLC-CLI configuration on MacOS for GNU toolchain with default GSDK installation directory:

slc configuration --sdk=~/SimplicityStudio/SDKs/gecko_sdk --gcc-toolchain=/Applications/ARM

General Options#

These options can be specified for any action and must appear after the command. For instance, slc configuration --cli-config file.cfg –sdk=/sdk/path is correct.

Working with Projects#

This section assumes you have configured the GSDK location as described above.

slc generate *\<path\|to\|example.slcp\>* generates a project from an existing .slcp file, such as an SDK example. The path to the example is either the fully defined path, or the path relative to the calling location.

Key options are:

-d <destination> (optional) specifies the destination for the generated project. If not specified, the project is generated to the source.slcp location.

-np generates a new project by copying the .slcp file and all files defined in it into the destination location. All file references in the .slcp are updated to point to the destination location. Any sources that should be highlighted are shown in the SLC-CLI output.

-name=<generated-name> specifies a different generated project name. Otherwise the name of the source .slcp file is used.

--with <device|board> customizes the generated project for the target specified by the full part number or board ID, for example “EFR32BG22C224F512IM40” or “brd4184b”.

To generate a new project with a new name for all supported toolchains:

slc generate \path\to\example.slcp -np -d <project destination> -name=<new name> --with <board or device_that_supports_project>

A number of files are generated that can be used with different tools. For example, to build the project with Make (if Make is in your path):

make -f <project>.Makefile

Examples:

Windows: Generate for all toolchains, for EFR32MG12P232F512GM68 device:

slc generate C:\Users\<user>\SimplicityStudio\SDKs\gecko_sdk\app\bluetooth\example\soc_empty\soc_empty.slcp -np -d c:\test-soc-empty\ -name=test-soc-empty --with EFR32MG12P232F512GM68

MacOS: Generate, build (GNU Make/GCC), and flash (Simplicity Commander) project to Thunderboard Sense 2 (BRD4166A):

$ GSDK=~/SimplicityStudio/SDKs/gecko_sdk
$ slc configuration --sdk=$GSDK --gcc-toolchain=/Applications/ARM
$ slc generate $GSDK/app/common/example/blink_baremetal -np -d blinky -name=blinky -o makefile
   --with brd4166a
$ cd blinky
$ make -f blinky.Makefile
$ commander flash build/debug/blinky.hex

Project Operation Options#

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

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.

Working with SDKs and Extensions#

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

SDK Options#

These options are shared among all SDK commands.

SDK Operations#

Creating SDK Extensions#

This section discusses what constitutes an SDK extension and how to create one, as well as collating any information from the primary specification that pertains to SDK extensions. Note that this document is updated separately from the specification. In the event that the specification and this document do not align, the specification supersedes this document.

What Makes Up an SDK Extension?#

To be used as an SDK extension, all you need initially is an .slce file and a folder that contains it. This becomes the container for the SDK extension.

Additionally, if you intend to install an SDK extension into an SDK manually (as opposed to letting the Simplicity Studio UI handle it), make sure the folder containing the .slce file is in a folder called extension inside of the SDK you intend to install it into.

Creating the Empty SDK Extension#

First you will create an empty SDK extension for the sole purpose of testing that the integration of the SDK extension into the SDK is successful. So you can test as you go, you will create an SDK extension such that you do not need to go to the Simplicity Studio UI to install it.

1. Name your base folder anything you like.

2. Ensure your base folder is in the extension directory of the SDK. If the folder does not exist, create it. By default, it is likely you will not have it if you have yet to install extensions into a particular SDK.

   1. Because you will be using the slc cli later to verify your SDK extension is installed properly, make sure you are creating your SDK extension in the same SDK that is configured with slc configuration –-sdk.

   2. If you are performing these steps with an sdk you downloaded using the Simplicity Studio installation, you will typically find the sdk in your user home folder. Navigate to SimplicityStudio → SDKs → gecko_sdk to find your installed sdk. You can also see where you installed the sdk from Simplicity Studio by checking the installation manager. Go to Launcher View, select Install at the top, and select the SDKs tab. Then, find the Gecko SDK - 32-bit and Wireless MCUs installation card and check the path indicated there.

   This is an example folder structure:

   + - SimplicityStudio
           |
           + - SDKs
                |
                + - gecko_sdk
                    |
                    + - extension
                        |
                        + - your_extension

   Note: This is extension singular, not extensions plural.

3. Create an .slce file at the base folder you wish to use. If starting from scratch completely, your folder may be empty.

4. Substituting <text> where appropriate, enter the following into the .slce file.

   .slce minimum working data

   id: "<your_extension_id>"
   label: "<your_extension_label>"
   version: <your_extension_version>
   sdk:
     id: "gecko_sdk"
   version: "4.1.0"
   component_path:
     - path: <your_component_path>

   • <your_extension_id> is a unique id for this SDK extension and how SLC internally recognizes it as distinct from another vendor. The SLC specification for id indicates which characters are allowed. Generally, this means no spaces, all lowercase, and _ (underscore character) are permitted.

   • <your_extension_label> a human-readable name for the SDK extension. This may contain spaces.

   • <your_extension_version> the starting version. This must follow semantic versioning rules – for example, 1.0.0, 0.0.1.

   • <your_component_path> is the folder at the same level as the .slce file where the SDK extension can find your .slcc files. If you do not know, the .slcc file defines an installable component into an SLC project. You may define multiple paths here as well. This procedure assumes the path is . , as in

   component_path:
     - path: .

   • The sdk definition is typically gecko_sdk because that is the only SLC aware Silicon Labs sdk at this time. You may need to change the version number if you have a later version of the GSDK.

     • If you want to learn your gecko_sdk version without opening Simplicity Studio, open the gecko_sdk.slcs file inside the sdk folder and check the sdk_version metadata.

5. You now have a valid .slce file. If you already have some .slcc files and they are targeted by component_path, skip to step 6. Otherwise:

   1. Make a new .slcc file in the same directory as the .slce (or in one of the directories pointed to by component_path).

   2. Add a bare minimum amount of text for the .slcc to be considered valid.

      For example:

      id: neopolitan_icecream
      label: Neopolitan Icecream
      package: "ext-comp"
      description: Neopolitan Icecream
      category: Melting|Icecream
      quality: alpha

      The above is an absolute minimum set of required keys for an .slcc file to be considered a valid component.

6. Ensure that your slc command line is installed and available.

7. Ensure that slc configuration is set to use the sdk you are installing the SDK extension for.

8. Run slc signature trust -extpath <path_to_your_extension_sdk> so it is trusted. Otherwise, none of its contents will be parsed, and will therefore not be found in later steps. This should be the path to the folder containing the .slce , not to the .slce itself.

   Note: This is different from slc signature trust -extid <your_extension_id>:<your_extension_version> which installs trust for your SDK extension based on its id and version regardless of where it ends up moving. The former method will trust the SDK extension location allowing you to rename or reversion it without losing trust. If you are following this procedure and manually installed the SDK extension in with your GSDK, you will likely vastly prefer the -extpath option.

9. Run slc signature trust --sdk <path_to_the_gecko_sdk> if you have not yet trusted your SDK.

10. Run slc examine <your_slcc_component_id> -ext <your_extension_id>:<your_extension_version> where the id is either the dummy id you created for the test component (in the above example, that would be neopolitan_icecream), or the id of some component that should exist in your SDK extension. The -ext part tells examine to look in a specific SDK extension and you must supply both the id and version so it knows where to look (since the same id could be used in different places).

11. The SLC command line will report the component is found and the information about it will be displayed on the console. If it does not appear, recheck the above steps. Otherwise, you have installed your SDK extension.

Note: The most common error here is not trusting the SDK extension. If it is not trusted, you will not receive any notification, it will just not load and not find the component.

Making a Project Use an SDK Extension (Command Line)#

Normally, you can add an SDK extension to a project using the Component Selector in the Simplicity Studio User Experience (UX). Without that, you must do this manually. You add an SDK extension to a project by modifying its .slcp file to refer to the SDK extension. Components within that SDK extension are included using a special syntax.

1. Make a new project. This is beyond the scope of this document, but you can take an existing Simplicity Studio project you have or use slc generate -np on an example project in the SDK to create a new one to work with if you do not have one already. Refer to the relevant slc documentation on how to find and generate an example.

2. Inside the .slcp file, add a section as shown below. Add to the same level as other root metadata tags:

   sdk_extension:
     - id: <your_extension_id>
       version: <your_extension_version>

3. This tells the project that it will use that SDK extension with specifically that version. You may define multiple SDK extensions to use in a project, but for a given id, you may only choose one version.

4. Now, tell the project to use one of the components in the SDK extension. There is a component key at the root of the yaml with a list of components selected in a project. Observe the difference between referring to a component from the SDK and a component from the SDK extension as shown below.

   component:
     - id: emlib
     - id: neopolitan_icecream
       from: <your_extension_id>

   • emlib comes from the GSDK. Any component from the GSDK needs only the id field. You do not need to have this specific component. This is just an example of what using a component from the main SDK looks like compared to the SDK extension.

   • neopolitan_icecream, or whatever id of a component in your sdk extension, comes from that SDK extension. As such, you need to tell SLC that this component comes from a different location. Note that the version is not included next to the from field. This is why sdk_extension field exists earlier. sdk_extension indicates what specific SDK extension to pick out. You cannot have multiple SDK extensions with the same id even if the versions are different, in the same project. The component listing will always refer to whatever version of that SDK extension is being brought in at the time.

5. You can now use slc summarise on the project to view and ensure that your project is seeing the component.

Using Your SDK Extension with the Simplicity Studio IDE#

The Simplicity Studio Integrated Development Environment (IDE) provides a User Interface (UI) for adding SDK extensions from anywhere on your system. However, if you are actively developing SDK extensions, it is important to be aware of a few limitations. This section discusses how to add your custom SDK extension to Simplicity Studio in this way and what to look out for as an SDK extension developer.

First, if you have followed the above procedures up to this point and used a project that is already part of a Simplicity Studio workspace, it is already connected. You need only launch Simplicity Studio and open the project. The SDK extension will already be installed and you can browse components within it.

If you followed the above procedures but did not use a project in a Simplicity Studio workspace, follow these steps

Using an already installed and trusted SDK extension with a project:

1. Create a new project or pick an existing one using the same sdk you installed the SDK extension for.

2. Open the .slcp file.

3. Navigate to the Component Selector by clicking the Software Components tab.

4. Search for a component in your SDK extension.

5. After you find it, Simplicity Studio prompts you to add the SDK extension to the project before you install the component.

6. Install the component and your project is now connected to that SDK extension.

For the above steps, you do not need to install the SDK extension at a preference level to be globally accessible. By placing it in the GSDK’s extension folder, you already did that manually and Simplicity Studio has detected that.

However, if you did not install the SDK extension or you are using a different GSDK that does not have the SDK extension, your flow will be a bit more involved. If you wish to use your SDK extension with a different SDK or you have distributed it and another SDK wishes to use it, follow these steps:

1. In Simplicity Studio go to Preferences > Simplicity Studio > SDKs and select the Gecko SDK Suite to which the SDK extension will be added. Click Add Extension….

2. Click Browse and navigate to the root folder of the new SDK extension and click Select Folder.

3. The SDK extension should be displayed in the Detected SDK Extension window with the correct name, version, and path. Click OK and then Trust and Apply and Close.

   Important: Be aware that installing an SDK extension like this will copy the SDK extension from wherever it was into the proper folder structure and rename it so it is detected as an SDK extension. Because this is a copy, changes you make to your original SDK extension will not be reflected until you remove and add the SDK extension again. This is why the earlier part of the above procedures recommend starting from the correct installation location of the GSDK you want to test with because this shields you from this complication.

4. You can now follow the above steps in Using an already installed and trusted SDK extension with a 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.

Shutting 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-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.

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.