SILICON LABS UG575 SiWx917 NCP Manufacturing Utility User Guide

< filename.bin> serialinterface –skipinit

| commander manufacturing read efusecopy –out efusecopy.bin

Note: If no MBR is present in the device, you will see an error. Refer to the Possible Error Codes section for more information on error codes.

Security Key Programming
This part of manufacturing includes generation of static keys and Physically Unclonable Function (PUF) generated keys and loading them into flash. While programming the static keys, the keys are saved in wrapped format in the flash. There are multiple keys that are generated inside and outside of the device. Refer to Secure Key Management and Protection section for information on keys generated at commander and PUF Intrinsic keys.

The sequence to do security key programming is as follows:

1. Activation code generation for PUF Block.
2. Power cycle the device to boot again after step 1.
3. Generate keys from commander (generates keys at commander).
4. Intrinsic key generation (PUF generated keys) and loading keys (loads both device-dependent keys and generated keys at commander)

Activation Code Generation for PUF Block

This command is used to generate an activation code from the PUF module present in the SiWN917 device. Once generated, the firmware will burn this activation code into flash.

MBR (filename.bin) files are present at the folder “Commander_xxx_xxx\Simplicity Commander\resources\jlink\Si917”s

Example:
commander manufacturing init –mbr ta_mbr_SiWN917M100LGTBA.bin –data updated_mbr_file.json -d si917 –serial interface

Return Code

• Success – 0xa05a
• Failure – Try again.

Power Cycle the device
The users need to power cycle the device after the Activation Code Generation and flash completion. This is a mandatory step.

Generate Keys from Commander
These keys are generated at commander. The key generation will produce a JSON file containing the OTA keys, public keys, and Attestation keys. For each of the public or private keys, the respective pair counterpart

Example:
commander until genkeyconfig –out file commanderkeys.json -d si917

Return Code

• Success – 0xa05a
• Failure – Try again.

Intrinsic Key Generation, Update MBR, and Loading Keys
This step performs the actual provisioning of the intrinsic keys (PUF generated keys), static keys, and final TA MBR and key descriptor table.
Along with keys loading and burning, the MBR will be updated with filename.bin or the “default” option (selected based on the OPN).

Example:
commander manufacturing provision –mbr ta_mbr_SiWN917M100LGTBA.bin –keys commanderkeys.json –data updatedmbrfields.json -d si917 –serialinterface

Note: The updated-mbr-fields.json file provided is to be updated with different security levels discussed in MBR Programming with Security Section. Once we give this command, it updates default OPN-based MBR with .json file parameters and loads to the flash after keys loading.

Add Security to TA Firmware Image Files
When the security is enabled in the device, it expects the TA file also to have the same level of security enabled. If the user tries to flash the non- secured image, the system will give an error.

Extract Keys

We need some of the keys generated in the section Generate Keys from Commander to secure the TA firmware image. We will have to extract these keys to a different folder

Note: If security is enabled in your device (according to section 4.2 – Security Key Programming), you will have to load the secured image. Or else the loading fails.

MBR Programming with Security
In the catalogue parts, the SiWN917 devices do not have security features enabled. The devices will have a default common flash configuration if the device’s OPN has a flash.
In all the default cases, the device’s MBR and EFUSE configurations have all the security features programmed to disabled state – the PUF is not enabled, the activation code for the PUF is not programmed, keys or key descriptors are not programmed.

• The security fields in MBR, PUF Activation code, Key descriptors, and the Keys are to be programmed in the device while enabling the security features in the device.
• The MBR includes the address of the sector where the PUF Activation code must be programmed as well as the address where the Key descriptors must be saved.
• This way the user can change the location of the PUF Activation code, Key descriptor table, and the address of the Keys.
• The MBR contains a field – valids, which has bits to set the PUF_ACTIVATION_CODE_ADDRESS_VALID and KEY_DESCRIPTOR_ADDRESS_VALID
• The device uses these bits to determine the address of the PUF Activation code, Key Descriptor, and the Keys.

Programmable Fields in MBR
The table below shows a few of the Requirements and the MBR fields which can be programmed.

XTS mode)
Start address of the sector where the PUF Activation code must be saved, 0x2000 is the default|

mbr

|

puf_activation_code_addr = 0x2000;

Start address where the key descriptor table must be saved. (0x300 is the default)|

mbr

|

key_desc_table_addr = 0x300;

If PUF Activation code’s start address is being changed|

mbr

|

valids |= PUF_ACTIVATION_CODE_ADDR_VALID;

If Key descriptor’s start address is being changed|

mbr

|

valids |= KEY_DESCRIPTOR_ADDRESS_VALID;

Security Levels
There are three different security levels available as described below. The levels are defined to make the security configurations easier for the user.

1. Security Level 1 or Low Security Level
2. Security Level 2 or Partial Security Level
3. Security Level 3 or Full Security Level

Security Level 1 (Low Security)
If the user wants to enable only secure boot, this level should be selected. This security level enables the bootloader to carry out the Message Integrity Check (MIC) of the firmware image during firmware loading and firmware update.
In this configuration, the firmware update process will be faster, the bootup time will be less, and the execution also will be faster.
This configuration is selected using the following fields:

Security Level 2 (Partial Security)
This level is for the user who wants to enable Secure boot along with Signature check of firmware image. This security level enables the bootloader to carry out the Message Integrity Check (MIC) and Signature validation of the firmware image during firmware loading and firmware update.
In this configuration, the Firmware update process will be slower but faster than Security Level 3, the bootup time will be relatively less than Security Level 3, and the execution will be same as Security Level 3.
This configuration is selected using the following fields:

Security Level 3 (Full Security)
This level is for the user who wants to enable the Secure Boot, the Signature check, and the Inline Encryption. This security level enables the bootloader to carry out the Message Integrity Check (MIC), Encryption, Signature check of the firmware image during firmware loading and firmware update and Inline Encryption while saving the firmware in the flash.
In this configuration, the Firmware update process will be slower, the bootup time will be higher, and the execution also will be slower compared to security levels 1 and 2.
This configuration is selected using the following fields:

Example JSON file with security parameters of MBR
The following example shows the structure and the available fields:
Download the .json file from the link

Manufacturing Procedure – eFuse Data

In the case of eFuse/OTP data, Commander will first check that the requested update is possible (since bits can only be set to 1 and never cleared). Then it will ask for confirmation from the user. It is possible to skip the confirmation via the –noprompt option although note that this is a one-time operation.
It is possible to check the results of the operation before physically going ahead with the one-time programming by using the –dryrun option.
This command is used to write eFuse data into flash.

Security Features – Manufacturing Utility

The following sections provide information on how to enable security using a manufacturing utility (Simplicity Commander CLI) to enable different SiWN917 Security features.

Secure Boot
Configure or enable/disable a pre-flashed secure bootloader on the chips to encrypt your software intellectual property (IP). Safeguard your competitive edge in the market.
Secure Boot is a feature for ensuring only an authenticated code can run on the chip. If any device fails its security check, it is not allowed to run, and program control will typically stall in the validating module.
The SiWx917 includes a Security Bootloader or Secure Bootloader. The Security Bootloader runs on the ThreadArch processor. On any reset, the Security Bootloader configures the module hardware based on the configuration present in the eFuse. It also validates the integrity and authenticity of the firmware in Flash and detects and prevents the execution of unauthorized software during the boot sequence.

Secure Boot Process:

1. Upon reset, the Security Bootloader configures the module hardware based on the configuration present in the ROM and Flash.
2. Device configurations in Flash are authenticated by Security Bootloader
3. Security Bootloader validates the integrity and authenticity of the firmware in the Flash and invokes the Application Bootloader.
   To enable only secure boot or secure boot along with other security features refer to Security Levels section.

Secure Key Management and Protection
Inject custom public and private keys and other custom secret keys on the chips during manufacturing – safeguard your products right from the beginning of their lifecycle. The Bootloader uses public and private key-based digital signatures to recognize authentic software. The Security Bootloader provides provision for inline execution (XIP) of encrypted firmware from Flash.
If this feature is enabled, PUF engine will be invoked. PUF Keys will be generated internally via PUF and stored in flash. Images are encrypted and decrypted using PUF intrinsic keys.
The PUF Intrinsic Keys are device-dependent keys. They are unique for each device.
PUF Intrinsic Keys are as below. These are generated randomly.

• Master Key – Used to encrypt the TA OTA Key and TA Public Key for storing in the Flash.
• Unwrap Key – Used to encrypt the M4 OTA Key and M4 Public Key for storing in the Flash.
• TA FW Keys (2) – Used for Inline decryption.

Keys generated at the commander are as follows.

• OTP Symmetric Key – Used for flash content (Message Integrity Check) verification.
• OTP Public Key – Used for flash content (digital signature) verification.
• TA Public Key – Used for TA firmware signature verification.
• TA OTA key – Used for TA Firmware upgrade.
• Attestation Private Key – Used for secure attestation.
• M4 OTA Key – Used for M4 firmware upgrade.
• M4 Public Key – Used for M4 firmware signature verification.

For information on how to generate the keys at commander, refer to Generate Keys from Commander. For PUF activation, refer to Activation Code Generation, and to generate intrinsic keys and load the keys (both the intrinsic keys and keys generated at commander), refer to Intrinsic Key Generation and Loading Keys.

The table below shows the Key type, Key length, and Storage type.

Note: For TA Public key actual key size is 91 bytes, remaining 5 padding bytes added to make key size multiple of 16 for AES encryption. For the Attestation key also, the actual key size is 227 bytes.

Calibration Using Manufacturing Utility

The following two flows are possible with the manufacturing utility (Simplicity Commander CLI) to calibrate the SiWN917 device.

Transmission in Burst Mode

Steps for Frequency Offset Correction.

1. Set up the radio and start transmission. commander manufacturing radio –power 16 –phy 6MBPS –channel 1 –start -d SiWG917M111MGTBA –serial interface
2. Measure the frequency on the instrument which has the capability of measuring frequency error in modulated packets. For example, Keysight instruments with modulation analysis measurement setting capability reports the frequency error in burst packets.
3. Adjust the CTUNE values by providing the frequency error as input. This is a frequency offset correction, with the value ranging from –255 to 255 Offset = measured frequency (in kHz) – 2412000 commander manufacturing xocal –offset –skipload -d SiWG917M111MGTBA –serial interface –skip-init
4. Check the instrument and verify that the channel frequency is within expectations. If not, repeat from step 3.
5. Store the CTUNE values. The radio transmission will stop. commander manufacturing xocal –store –skipload -d SiWG917M111MGTBA –serial interface –skip-init

Steps for Customer Gain-Offset

1. Setup the radio and start transmission on channel 1. Commander manufacturing radio –power 16 –phy 6MBPS –channel 1 –start -d SiWG917M111MGTBA —serial interface
2. Measure the output power with the instrument that has the capability of measuring burst power. For example, Keysight instruments with modulation analysis measurement setting capability report the burst packet power.
3. Calculate the offset to meet the expected output power (16 dBm). Offset = ceil ((output power measure (dBm) + cable loss — 16) * 2)
4. Store the gain values for channel 1 commander manufacturing gain –ch1 –skipload -d SiWG917M111MGTBA –serial interface –skip-init
5. Repeat from step 1 for channel 6 and 11. In step 4m replace –ch1 with –ch6 and –ch11 when measuring for channels 6 and 11 respectively.
6. Stop the radio. commander manufacturing radio –stop –skipload -d SiWG917M111MGTBA –serial interface –skip-init

Transmission in Continuous Mode

Steps for CTUNE Adjustments

1. Set up the radio and start transmission. commander manufacturing radio –power 16 –phy CW –channel 1 –start -d SiWG917M111MGTBA –serial interface
2. Measure the frequency on the instrument using peak search (use the instrument that supports spectrum mode/modulation).
3. Adjust the CTUNE values by providing the frequency error as input. This is a frequency offset correction, with the value ranging from –255 to 255. Offset = measured frequency (in kHz) — 2412000 commander manufacturing xocal –offset –skipload -d SiWG917M111MGTBA –serial interface –skip-init
4. Check the instrument and verify that the channel frequency is within expectations. If not, repeat from step 3.
5. Store the CTUNE values. The radio transmission will stop. commander manufacturing xocal –store –skipload -d SiWG917M111MGTBA –serial interface –skip-init

Steps for Gain Offset Adjustments

1. Setup the radio and start transmission on channel 1. commander manufacturing radio –power 16 –phy 6MBPS –channel 1 –noburst –start -d SiWG917M111MGTBA –serial interface
2. Measure the output power (use the instrument which supports spectrum mode/modulation). Measure the integrated power in 20MHz bandwidth.
3. Calculate the offset to meet the expected output power (16 dBm). Offset = ceil ((output power measure (dBm) + cable loss — 16) * 2)
4. Store the gain values for channel 1. commander manufacturing gain –ch1 –skipload -d SiWG917M111MGTBA –serial interface –skip-init
5. Repeat from step 1 for channels 6 and 11. In step 4 replace –ch1 with –ch6 and –ch11 when measuring for channels 6 and 11 respectively.
6. Stop the radio. commander manufacturing radio –stop –skipload -d SiWG917M111MGTBA –serial interface –skip-init

Note:

• There can be a variation of up to +/- 2dB in power across parts at Typical/Room temperature.
• It is recommended that the user makes the “Customer Gain-offset” correction on customer-end products to correct for IC part-to-part variation and insertion-loss variations in the RF front-end on customer boards. This calibration process would ensure accurate Transmit power control for Regulatory compliance @ volume production.

Read Manufacturing Parameters

This command is used to read the manufacturing parameters from DUT and to save the data to a file.
Command: commander manufacturing read <tambr|taipmu|efuse|efusecopy> –out <filename.bin|filename.json> –serialinterface –skipinit

region
 | –out | Filename to store the read data in. “*.bin”
 | taipmu| Read the TA flash ipmu data available for memory region
 | efuse| Read the OTP data
 | efusecopy| Read the efusecopy data in flash

Possible Error Codes

from the user to select pinset/damaged MBR file
Activation code| 0xa0b0| Activation code generated failed| security module might throw an error if PUF enroll fails, if the device is locked to use PUF
Intrinsic keys| 0xa0b1| Intrinsic keys generation failed| This may occur if this command triggered before activation code command.
Static keys| 0xa0b2| Static keys stored failed| This may occur if there are no intrinsic keys.
Update Firmware| 108| Failed to load firmware| This may occur if the header part of rps file is not proper.

Appendix

Parameters – Manufacturing Utility

if a JSON parser is available for this memory region data.
taipmu| Read the TA flash IPMU data available for the memory region
efusecopy| updating eFuse data to flash for selected region