Stack Structure#

The following figure describes the firmware structure that integrates the Amazon Sidewalk protocol stack and enables Amazon Sidewalk connectivity for the end device. The Platform Abstraction Layer assures communication between Silicon Labs Simplicity SDK and the Amazon Sidewalk protocol stack. The developer creates applications on top of the stack, which Silicon Labs provides as a precompiled library.

The Amazon Sidewalk stack contains the following blocks:

• Application Layer Library: Contains API call definitions to be used in application development.

• BLE Network Interface: Contains Amazon Sidewalk-specific configuration for the Bluetooth LE (BLE) link layer.

• Sub-GHz Network Interface: Contains Amazon Sidewalk-specific configuration for sub-GHz link layer and Semtech drivers.

• MAC Layer: Amazon Sidewalk implementation of the MAC layer.

Dependencies#

The following software components are used by the stack:

• FreeRTOS: Used as a base to run the stack.

• PSA crypto: Used for all cryptographic operation.

• BLE stack: Used to access the BLE stack.

• SPI driver: Used only in sub-GHz-enabled applications, for communication with a third-party sub-GHz radio module.

• RAIL: Used to access the radio and high-precision timers.

Library Files#

Amazon Sidewalk extension contains several library files: for the Sidewalk stack and its features, for the BLE stack, and for the Semtech chip drivers. The Silicon Labs Platform Abstraction Layer is available in source in the extension.

Amazon Sidewalk PAL#

The Platform Abstraction Layer (PAL) acts as a bridge between the Sidewalk protocol stack and the underlying hardware and RTOS. Configuration is typically handled via compile-time macros and linker symbols specific to the chosen MCU platform.

For more detailed documentation on the PAL layer, see the PAL API Reference Documentation.

Software Components#

The Amazon Sidewalk extension includes the following software components. Each component can be used in a custom application. Each is described and documented in the API documentation, a quick presentation is shown here.

• Sidewalk

  • Protocol

    • BLE: the BLE stack and abstraction layer for Amazon Sidewalk

    • SubGHz driver EFR32xGxx: the FSK driver and abstraction layer for the Silicon Labs parts

    • SubGHz driver Semtech SX1262: the driver and abstraction layer for the Semtech SX1262 part

    • SubGHz driver Semtech LR1110: the driver and abstraction layer for the Semtech LR1110 part

    • KG100S: Necessary pin configuration for KG100S module

    • DMP Components

    • Sidewalk NVM3 Migrator: a tool to migrate to the new NVM3 architecture starting Sidewalk extension 2.0.0

  • Utility

    • Logs: the component that allows to control the logs level and output

    • Credentials Backup/Restore Feature: Private component used in the OOB demo to backup the credentials

For more detailed documentation on software components, see the Software Component Documentation.

DMP Components#

These components enable Dynamic Multiprotocol (DMP) operation by allowing Sidewalk to coexist with other wireless protocols such as Bluetooth Low Energy on the same radio hardware. They replace the default single-protocol stack libraries with DMP-aware versions and integrate with the Silicon Labs multiprotocol scheduler. Example applications include concurrent BLE and Sidewalk operation using shared time-sliced radio access.

Credentials Backup/Restore Feature#

The out-of-the-box (OOB) application provided with the Pro Kit has a feature that allows users to erase the flash memory without losing the device private keys and other device-specific information. The feature relies on the user data partition that is not affected by mass-erase but it can still be erased. This feature can be used alongside Secure Vault seamlessly.

The manufacturing page needs to persist in order for the application to work in the Amazon Sidewalk network. This data can be divided in two groups, one for device-specific information and the other for information common to all devices created under the same device profile. As the capacity of the user data partition is quite limited, the common information is stored in the application code and only the device-specific information is backed up on the user data partition.

The following flow diagram shows the backup/restore feature workflow.

The Backup feature is used to copy device-specific information from the manufacturing page onto the user data partition. There is no need to copy common information as it is hard-coded in the application. Backup takes place when the application cannot detect any backed up data on the user data partition. This implies that, if the user data partition is erased but not the application, then the application will perform a backup process after each boot.

The Restore feature is used to copy device-specific information from the user data partition and common information from the OOB application code onto the manufacturing page. Restore takes place when the application cannot detect any valid manufacturing page. This implies that, if the device is mass-erased, then the application will perform a restore process after each boot and restore the whole manufacturing page.