Custom Board Configuration Methods#

You can configure a custom board by using one of the following methods:

The recommended method is to use Software Components and the Pin Tool. These tools automate project configuration, manage dependencies, and reduce manual setup. However, all three methods are supported. Select the method that best meets your project requirements and development workflow.

Configure Using Software Components and the Pin Tool (Recommended)#

Software Components#

Software Components are the preferred method in Simplicity Studio® 6 for enabling and configuring most project features.

Software Components may be used to configure:

  • Drivers

  • Middleware

  • Protocol stacks

  • Board support features

  • Peripheral services

  • External memory

  • Bootloader-related features

  • Application utilities

Software Components can also manage dependencies and generate project configuration files. When moving from a Silicon Labs development board to a custom board, review the installed components and confirm that each one is required by the custom hardware or application.

Remove or modify components when:

  • The hardware resource is not present on the custom board.

  • The component assumes a pin assignment from the original development board.

  • The component depends on an external device that is not populated.

  • The component introduces unused initialization code.

  • The component conflicts with pins or peripherals used by the custom design.

  • The component assumes a memory layout that does not match the custom board.

For example, a development board example may include components for LEDs, buttons, sensors, or external flash. If those resources are not present on the custom board, remove or update the corresponding components.

For more information, see Software Components and Simplicity Studio 6 - Working with Software Components.

Pin Tool#

The Pin Tool is the primary tool for reviewing and updating pin assignments in Simplicity Studio 6.

Use the Pin Tool to:

  • Assign general-purpose input/output (GPIO) pins

  • Configure peripheral signal routing

  • Review pin conflicts

  • Update pins after retargeting

  • Free pins used by removed board resources

  • Compare project configuration against the custom board schematic

Review the Pin Tool whenever a project is retargeted from a Silicon Labs development board. Retargeting changes the selected device, but it does not guarantee that board-level resources match the custom board.

Pin Tool Review Checklist#

If the project is created from a Silicon Labs example, review the following items in the Pin Tool:

  • LEDs

  • Buttons

  • Universal Asynchronous Receiver/Transmitter (UART) or Virtual COM (VCOM) pins

  • Inter-Integrated Circuit (I2C) pins

  • Serial Peripheral Interface (SPI) or Universal Synchronous/Asynchronous Receiver/Transmitter (USART) pins

  • External flash pins

  • Sensor interface pins

  • Radio frequency (RF) control pins, if applicable

  • Debug-related pins

  • Pins assigned by software components

  • Pins copied from the original development board configuration

For more information, see the Pin Tool documentation.

Important Hardware Configuration Options#

The custom board configuration must reflect the actual hardware design. Review the following areas carefully.

Clock Configuration#

Review oscillator and clock source configuration, including:

  • High-Frequency Crystal Oscillator (HFXO)

  • Low-Frequency Crystal Oscillator (LFXO)

  • High-Frequency RC Oscillator (HFRCO) or other internal oscillator usage

  • External crystal availability

  • Low-frequency clock source

  • Clock requirements for protocol stacks or low-power operation

Incorrect clock configuration can prevent startup, affect radio behavior, or cause low-power features to fail.

GPIO and Peripheral Routing#

Review GPIO and peripheral routing against the custom board schematic, including:

  • Pin mode

  • Pull-up or pull-down settings

  • Default output state

  • Peripheral route location

  • Alternate pin locations

  • Shared pins

  • Pins reserved for debug or programming

External Resources#

Check whether the project assumes any external board resources, such as:

  • External flash

  • Electrically Erasable Programmable Read-Only Memory (EEPROM)

  • Sensors

  • Displays

  • Buttons

  • LEDs

  • Oscillators

  • RF front-end components

  • Power management devices

Any resource that is not present on the custom board should be removed from the project configuration or replaced with the correct custom-board implementation.

Example Configuration Error#

A common error occurs when a project is retargeted from a Silicon Labs development board and still contains configuration for resources that are not present on the custom board.

Example:
The original development board includes an external SPI flash device.
The custom board does not include external SPI flash.

After retargeting, the external flash software component remains installed and the SPI pins remain assigned in the Pin Tool. During startup, the application attempts to initialize the missing flash device. This may cause initialization failures, timeout delays, bootloader issues, or application errors.

Recommended fix:

  1. Remove the external flash software component if it is not needed.

  2. Remove or update any application code that depends on external flash.

  3. Free the SPI pins in the Pin Tool.

  4. Review bootloader and Over-the-Air (OTA) settings to confirm they do not require external flash.

  5. Rebuild the project and verify that no component dependency errors remain.

A similar issue can occur with LEDs, buttons, sensors, or VCOM configuration copied from a development board example.

Memory Configuration#

Memory configuration is an important part of the custom board workflow, especially when the application uses a bootloader, OTA updates, non-volatile storage, or a device with a different flash or RAM size.

Review the following memory-related items:

  • Target device flash size

  • Target device RAM size

  • Linker script configuration

  • Bootloader region

  • Application region

  • Non-volatile storage region

  • Token storage

  • OTA image storage

  • External flash usage

  • Persistent application data

When a project is retargeted, Simplicity Studio may update device-level settings. However, you should still review the application for memory assumptions inherited from the original example or board.

Bootloader and Specific Use Cases#

Bootloader configuration must be aligned with the application memory layout and the custom board hardware.

Review bootloader configuration when the project uses:

  • Internal storage bootloader

  • External storage bootloader

  • OTA update support

  • Secure boot

  • Signed firmware images

  • Multiple firmware image slots

  • Manufacturing tokens

  • Non-volatile application storage

Important checks include:

  • The bootloader is built for the correct target device.

  • The application start address matches the bootloader layout.

  • The selected storage type is available on the custom board.

  • External flash is not enabled unless it exists on the board.

  • OTA storage regions do not overlap with application or persistent data.

  • Linker files and memory maps match the intended production layout.

For example, if the original development board used an external storage bootloader but the custom board does not include external flash, change the bootloader and application update strategy.

Configure Using the Pin Tool Only#

Use Software Components and the Pin Tool where possible because they are easier to review, regenerate, and maintain. However, some custom board configuration may require direct implementation in application code.

These configurations may use:

  • Hardware Abstraction Layer (HAL) APIs

  • Peripheral driver APIs

  • Application initialization code

  • Board-specific source files

  • Direct register configuration

  • Manually edited configuration files

  • Linker script changes

These methods are typically used for advanced or highly board-specific behavior.

Configure Peripherals Using HAL APIs#

HAL or lower-level peripheral APIs may be needed when a configuration is not exposed through Simplicity Studio UI tools.

You can still use the Pin Tool without Software Components for pin assignments and definitions. However, when Software Components are not used, configure each peripheral parameter manually in code.

Common examples include:

  • Analog peripheral configuration

  • Custom GPIO handling

  • Runtime peripheral reconfiguration

  • Low-energy peripheral behavior

  • Application-specific wake source configuration

  • Custom sensor or board bring-up sequences

Analog peripherals are a common example because their configuration often depends on the application and board design. For example, analog-to-digital converter (ADC) configuration may require manual setup of input channels, references, acquisition timing, oversampling, calibration, and runtime sampling behavior.

Add Required HAL Source Files to CMake#

When Software Components are not used, the required drivers and libraries may not be added to the project automatically. In this case, manually include the necessary source files and libraries in the project’s CMake configuration.

The project CMake file can be found at:

<projectname>/cmake_gcc/<projectname>.cmake

Add the required driver and library files to this CMake file so they are included during the build process.

Configure Without UI Tools#

Manual Configuration (Not Using UI Tools)#

This flow avoids both the Pin Tool and Software Components. Instead of generating pin declarations through the Simplicity Studio UI, the application defines the required ports and pins directly in source code and initializes GPIO and peripherals using Peripheral HAL APIs.

This approach is suitable when:

  • A fully code-driven bring-up flow is required.

  • The board pinout is already known.

  • The project should avoid generated pin abstraction layers.

  • Dependency on Simplicity Studio UI tools for pin configuration is not desired.

  • The application requires direct HAL-level control over GPIO and peripherals.

Key Difference from the Pin Tool Flow#

In a typical Simplicity Studio workflow using Software Components and the Pin Tool, the application uses generated pin configuration macros from pin_config.h, and the required driver source files are included through the project’s CMake configuration.

When you bypass Software Components and generated pin configurations, these dependencies are not added automatically. Therefore, explicitly add the required HAL or driver source files to the project CMake configuration. See Add Required HAL Source Files to CMake.

Define and maintain all peripheral pin assignments in a centralized, well-documented location to improve readability, maintainability, and future updates.