Custom Board Bring-Up#

This section outlines the initial hardware preparation needed to support the Sidewalk SDK on custom boards. It ensures that fundamental aspects such as clock sources, bootloader presence, and pin configuration are correctly established before layering in Sidewalk-specific functionality.

Base Hardware Checklist#

Before integrating the Sidewalk SDK, your custom hardware must meet certain baseline requirements. This includes configuring external clock sources (HFXO/LFXO) and verifying the presence of a compatible bootloader. These foundational elements are critical for reliable SDK operation and over-the-air updates.

1. By default, Sidewalk uses the LFXO external crystal to keep time during sleep. Some chip models integrate an internal clock source called LFRCO, but it is not precise enough for Sidewalk SubGHz operations. The Amazon Sidewalk specification recommends using +/-100ppm precision in SubGHz (section 5.1.4.3).

2. It is possible to use only HFXO high frequency clock if power consumption is not a concern. However, this will require to modify the PAL to disable deep sleep and remove the LFXO.

3. Bootloader is not mandatory for Sidewalk but it can be added and is recommended if you wish to perform OTA. Follow the instructions in Sidewalk and Bluetooth FUOTA Documentation for more details on bootloader usage.

4. The Amazon Sidewalk stack is integrated with RTOS and can't run as a baremetal application.

Additional configurations#

Non-Volatile Memory Management in Sidewalk Context#

Amazon Sidewalk example applications use non-volatile memory to store the application code, registration information, and manufacturing data. This section describes how this memory is used for each type of data stored.

⚠ WARNING ⚠: Starting Sidewalk extension 2.x.x, a change was made to the NVM3 usage in Sidewalk. This change is not backward compatible, you should be careful to use the manufacturing page generation that corresponds to the Sidewalk version that you are using.

The default NVM3 instance is used by the Simplicity SDK Suite for BLE stack status and cryptographic storage. This is where the wrapped private keys are stored when using Secure Vault. For more information, see Using Third Generation Non-Volatile Memory (NVM3) Data Storage.

The default NVM3 instance consists of the following logical partitions and subpartitions:

The manufacturing (MFG) partition is used to store the manufacturing page generated for every device. The manufacturing page contains various information such as device public keys, signatures, and Sidewalk Manufacturing Serial Number (SMSN). This instance is read-only from application code.

The Key-value (KV) storage partition contains information about the Amazon Sidewalk stack. The way the key-value pairs are stored on NVM3 is a bit different from the way the manufacturing information is stored. Objects are stored under groups, so there is actually one NVM3 object (so-called group) to store different information. The size of this instance depends on the needs of the stack (depending on the link layer). The values stored in the instance are not part of the public Amazon Sidewalk APIs. This instance is accessible in read-write from application code.

You can see an example of the memory layout in the following picture:

For more information on Silicon Labs NVM driver, see the dedicated documentation NVM3 - NVM Data Manager. For background on NVM3, see the Platform Resources section.

Memory Map for EFR32xG24 Series#

Those addresses are given as an example for an EFR32xG24 with a flash size of 1536 kB. The base addresses can change to adapt to smaller flash sizes or other radio boards. You can use Simplicity Commander to display the memory layout of your application:

1. With your kit selected, go to Device Info panel.

2. Select Flash Map in Main Flash panel.