Merge branch 'silabs' into RC_2.3.0-1.3

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -65,6 +65,7 @@ body:
         - release_2.1.0-1.1
         - release_2.2.0-1.2-alpha.1
         - release_2.2.0-1.2
+        - release_2.3.0-1.3-alpha.1
     validations:
       required: true
 

.github/ISSUE_TEMPLATE/feature_request.yaml

@@ -58,6 +58,7 @@ body:
         - release_2.1.0-1.1
         - release_2.2.0-1.2-alpha.1
         - release_2.2.0-1.2
+        - release_2.3.0-1.3-alpha.1
     validations:
       required: true
 

README.md

@@ -27,12 +27,12 @@ Device: SiWx917 SoC
 This repo contains documentation, demos, examples and all the code needed for Matter Accessory Device development on both Thread and Wi-Fi. The Thread development use cases differs from Wi-Fi because the Thread protocol requires the use of an Open Thread Border Router (OTBR).  
 
 -   To get started with the Thread demo and development see
-    [Matter Thread](https://siliconlabs.github.io/matter/2.2.0-1.2-alpha.1/thread/DEMO_OVERVIEW.html)
+    [Matter Thread](https://siliconlabs.github.io/matter/2.3.0-1.3-alpha.1/thread/DEMO_OVERVIEW.html)
 -   To get started with the Wi-Fi demo and development see
-    [Matter Wi-Fi](https://siliconlabs.github.io/matter/2.2.0-1.2-alpha.1/wifi/DEMO_OVERVIEW.html)
+    [Matter Wi-Fi](https://siliconlabs.github.io/matter/2.3.0-1.3-alpha.1/wifi/DEMO_OVERVIEW.html)
 
 The full documentation set starts here:
-[Silicon Labs Matter GitHub Documentation](https://siliconlabs.github.io/matter/2.2.0-1.2-alpha.1)
+[Silicon Labs Matter GitHub Documentation](https://siliconlabs.github.io/matter/2.3.0-1.3-alpha.1)
 
 ---
 

docs/silabs/NEW_FEATURES.md

@@ -91,7 +91,7 @@ With 1.1, devices will remain in Active Mode until the commissioning is complete
 The timer starts after the last communication.
 For this feature to take affect, there needs to be at least one message coming in or going out. If the device just polls its thread router and nothing else happens, this doesn't come into play.
 
-    For more details see the [Openthread Sleepy End Device](./general/OT_SLEEPY_END_DEVICE.md) section.
+    For more details see the [Openthread Sleepy End Device](./thread/OT_SLEEPY_END_DEVICE.md) section.
 
 ### Matter Sleepy End Devices over Wi-Fi
 

docs/silabs/README.md

@@ -50,7 +50,7 @@
    2. [Security Overview](general/SECURITY.md)
    3. [Matter Attestation Credentials for EFR32](../../silabs_examples/credentials/README.md)
    4. [Matter Intermittently Connected Devices](general/MATTER_ICD.md)
-   5. [Matter Sleepy End Devices over Openthread](general/OT_SLEEPY_END_DEVICE.md)
+   5. [Matter Sleepy End Devices over Openthread](thread/OT_SLEEPY_END_DEVICE.md)
    6. [Matter OTA Software Update](general/OTA_SOFTWARE_UPDATE.md)
 
 9. Reference Guides

docs/silabs/general/ARTIFACTS.md

@@ -1,7 +1,9 @@
 # Matter Software Artifacts
 
 This page provides links to pre-built software image artifacts that can be
-used to set up the Matter Demo for the Thread and Wi-Fi use cases. The majority of these artifacts can be found under the "Assets" section on the release page here:
+used to set up the Matter Demo for the Thread and Wi-Fi use cases.
+
+Images for the items listed below are available under the "Assets" section at the bottom of this page:
 
 https://github.com/SiliconLabs/matter/releases/tag/2.3.0-1.3-alpha.1
 
@@ -48,44 +50,42 @@ https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/bootl
 
 ## RS9116 Firmware
 
-The RS9116 firmware (rs9116_firmware_files_with_rev.zip) is used to update the RS9116 which can be found here:
+The RS9116 firmware (rs9116_firmware_files_with_rev_2.3.0-1.3-alpha.1.zip) is used to update the RS9116 which can be found in the Assets section of this page:
 
 https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/rs9116_firmware_files_with_rev_2.3.0-1.3-alpha.1.zip
 
 **Note**:
 RS9116 chip/module needs to be flashed with proper firmware as mentioned below:
+
 - `RS916.x.x.x.x.x.rps - This firmware image is valid for RS9116 1.5 revision chip/module`
 - `RS9116.x.x.x.x.x.rps - This firmware image is valid for RS9116 1.4/1.3 revision chip/module`
 
 ## SiWx917 Firmware for SiWx917 NCP
 
-The SiWx917 firmware(SiWx917NCP_firmware_files.zip) is used to update the SiWx917 NCP which can be found here:
+The SiWx917 firmware(SiWx917NCP_firmware_files_2.3.0-1.3-alpha.1.zip) is used to update the SiWx917 NCP which can be found in the Assets section of this page:
 
 https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/SiWx917NCP_firmware_files_2.3.0-1.3-alpha.1.zip
 
 **Note**:
 SiWx917 NCP board need to be flashed with proper firmware as mentioned below:
-- `SiWG917-A.2.9.X.X.X.rps - This firmware image is valid for BRD8036A (A0 Expansion v1.1) board`
 
+- `SiWG917-B.2.X.X.X.X.rps - This firmware image is valid for BRD4346A board`
 
 ## SiWx917 Firmware for SiWx917 SoC
 
-The SiWx917 firmware (SiWx917SOC_firmware_files.zip) along with WiSeConnect 3 SDK is used to update the SiWx917 SoC which can be found here:
+The SiWx917 firmware (SiWx917SOC_firmware_files_2.3.0-1.3-alpha.1.zip) along with WiSeConnect 3 SDK is used to update the SiWx917 SoC which can be found in the Assets section of this page:
 
 https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/SiWx917SOC_firmware_files_2.3.0-1.3-alpha.1.zip
 
 **Note**:
 SiWx917 SoC boards need to be flashed with proper firmware as mentioned below:
-- `SiWG917-A.2.9.X.X.X.rps - This firmware image is valid for BRD4325B(A0 dual flash 1.1) and BRD4325B(A0 dual flash 1.2) boards`
-- `SiWG917-B.2.9.X.X.X.rps - This firmware image is valid for BRD4325C(B0 common flash v1.2), BRD4325G(B0 Stacked Flash + External PSRAM v1.2) and BRD4338A(B0 common flash v2.0) boards`
 
-## SiWx917 SoC Configuration Files for Flashing the Matter Application
+- `SiWG917-B.2.X.X.X.X.rps - This firmware image is valid for BRD4338A(B0 common flash v2.0) board`
+
+## SiWx917 SoC Configuration Files For JLink RTT Logging
 
-In order to flash the Matter Application on the SiWx917 SoC, the Ozone Debugger must
-be configured for the SiWx917 SoC device by following the instructions on the [Ozone Environment Setup for SiWx917 SoC page](../wifi/SiWx917_Enablement_For_Ozone.md).
+In order to check device logs for the Matter Application on the SiWx917 SoC, the **JLink RTT** must be configured for the SiWx917 SoC device by following the instructions on the [JLink RTT SOC Support](../wifi/JLINK_GUIDE_917.md).
 
-The **JLinkDevices.xml** and **ELF** files referenced in the instructions may be found 
-here:
+The [JLinkDevices.xml](https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/JLinkDevices.xml) and **.elf** files referenced in the instructions may be found in the Assets section of this page.
 
-https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/JLinkDevices.xml
-https://github.com/SiliconLabs/matter/releases/download/v2.3.0-1.3-alpha.1/RS9117_SF_4MB_42bsp.elf
+**Note**:- For EFR32MG2x devices, JLink RTT Logging support is already available.

docs/silabs/general/CODE_SIZE_SAVINGS.md

@@ -1,5 +1,5 @@
-# Code Savings Guide for Matter Applications
+# Code Savings Guide for Building Matter Applications
 
-*   Remove unnecessary clusters from the zap configuration. Example applications have clusters enabled to support both Thread and WiFi transport layers such as the Diagnostics clusters. 
+* Remove unnecessary clusters from the zap configuration. Example applications have clusters enabled to support both Thread and WiFi transport layers such as the Diagnostics clusters. 
 
-*   Remove optional features in Matter that may not be needed for a certain application. In the EFR32 build [script](https://github.com/SiliconLabs/matter/blob/latest/scripts/examples/gn_build_example.sh), there are additional build arguments that are added to either add or remove optional Matter features. For example, added a build argument disable_lcd=true will save flash by disabling the lcd screen.
+* Remove optional features in Matter that may not be needed for a certain application. In the EFR32 build script, there are additional build arguments that are added to either add or remove optional Matter features. For example, added a build argument disable_lcd=true will save flash by disabling the lcd screen.

docs/silabs/general/COMMISSIONING.md

@@ -1,4 +1,4 @@
-# Matter Commissioning
+# Commissioning
 
 ## Overview
 
@@ -7,10 +7,10 @@ The commissioning process supports two potential starting points:
 1. The device is already on the network
 2. The device needs network credentials for Wi-Fi or Thread (requires Bluetooth LE (BLE) support)
 
-The current Matter revision supports Ethernet, Wi-Fi, and Thread devices. 
+The current Matter revision supports Ethernet, Wi-Fi, and Thread devices.
 
 - Ethernet devices get into the operational network when their Ethernet cable is connected. Therefore the devices are normally already on the network before commissioning.
-- Wi-Fi and Thread devices must have credentials configured before the devices can be joined into the operational network. This is normally done over BLE. 
+- Wi-Fi and Thread devices must have credentials configured before the devices join into the operational network. This is normally done over BLE.
 
 This page focuses on Wi-Fi and Thread. The first step for these devices is to enter commissioning mode, following one of two scenarios:  
 
@@ -19,35 +19,34 @@ This page focuses on Wi-Fi and Thread. The first step for these devices is to en
 | Standard | Device automatically goes into the commissioning mode on power-up. Beneficial for limited UI devices (such as light bulbs) |
 | User-Directed | Device only enters commissioning mode when initiated by the user.  Helpful for devices that have user interfaces or for which commissioning should not be initiated without a user present. |
 
-The following figure provides an overview of the commissioning process and the actions each role performs. 
+The following figure provides an overview of the commissioning process and the actions each role performs.
 
 ![Commissioning Overview](./images/CommissioningOverview.png)
 
 ## Example Commissioning Flow
 
 ![Steps 1-4](./images/CommissioningSteps1-4.png)
 
-In step 1, the Matter device must enter commissioning mode in one of the two scenarios
-described above. 
+In step 1, the Matter device must enter commissioning mode in one of the two scenarios described above.
 
 Usually, a mobile phone serves as the administrator. Step 2 is to use the mobile phone to scan the QR code of the Matter device. The QR code is used as a passcode to set up a secured BLE connection.
 
-Step 3 is to set up the BLE beaconing and connection between the mobile phone and the Matter device, so that the commissioning information can be exchanged through the BLE connection channel. 
+Step 3 is to set up the BLE beaconing and connection between the mobile phone and the Matter device, so that the commissioning information can be exchanged through the BLE connection channel.
 
-As the connection should be secure, step 4 is to secure the connection in a process known as password-authenticated session establishment (**PACE**). The passcode derived from the QR code is used as an input for this process. The output is the security key used by the connection.
+As the connection should be secure, step 4 is to secure the connection in a process known as password-authenticated session establishment (**PASE**). The passcode derived from the QR code is used as an input for this process. The output is the security key used by the connection.
 
 ![Steps 5-7](./images/CommissioningSteps5-7.png)
 
 After the secured connection is established, step 5 is to verify the Matter device's manufacturer certificate and compliance status. Each Matter device must have a device certificate programmed before it is shipped. The mobile phone, acting as administrator, reads the device certificate through the commissioning channel, then communicates with a remote database to validate the certificate and the compliance status of the device. The remote database is called the Distributed Compliance Ledger (**DCL**).
 
 Step 6 is to install the operational certificate for the device. The administrator either obtains the certificate from the remote server or generates the certificate locally and then transfers the certificate to the device. The administrator also configures the Access Control List (**ACL**) with the list of administrators.
 
-After operational security is configured, step 7 is to configure the operational network for the device. For Wi-Fi devices, the SSID and the password are configured. For Thread devices, the PAN ID, network key, and other parameters are configured. 
+After operational security is configured, step 7 is to configure the operational network for the device. For Wi-Fi devices, the SSID and the password are configured. For Thread devices, the PAN ID, network key, and other parameters are configured.
 
 ![Steps 8-10](./images/CommissioningSteps8-10.png)
 
-In step 8, the device starts to join the operational network with the configured parameters. 
+In step 8, the device starts to join the operational network with the configured parameters.
 
-Once the device is attached to the network (step 9), it can be discovered through Service Registration Protocol (**SRP**). To control that device, you must establish a secured connection through the Certification Authorized Session Establishment (**CASE**) process. 
+Once the device is attached to the network (step 9), it can be discovered through Service Registration Protocol (**SRP**). To control that device, you must establish a secured connection through the Certification Authorized Session Establishment (**CASE**) process.
 
-After the CASE session is established, the Matter device is commissioned successfully and can communicate with other devices in the Matter network (step 10).
+After the CASE session is established, the Matter device is commissioned successfully and can communicate with other devices in the Matter network (step 10).

docs/silabs/general/COMMIT_HASHES.md

@@ -7,13 +7,19 @@ in this release of the Silicon Labs Matter Out of Box Experience
 
 | Repo                                       | Branch | Commit Hash                              |
 | ------------------------------------------ | ------ | ---------------------------------------- |
-| https://github.com/SiliconLabs/ot-br-posix | main   | bb565ca0164981f58a2659222c30917399703a9b |
+| https://github.com/SiliconLabs/ot-br-posix | main   | 42f98b27bc7f54951c860cd98ce5ff7c7fedc68c |
 
 ## Radio Co-Processor (RCP)
 
 | Repo                                    |   Branch    | Commit Hash                              |
 | --------------------------------------- | ----------  | ---------------------------------------- |
-| https://github.com/SiliconLabs/ot-efr32 | matter_sve  | 038475dcc21c51448d35309496a2f7401eb2ccfe |
+| https://github.com/SiliconLabs/ot-efr32 |    main     | e75c767374a6a6fccd62f024c7217762ae652891 |
+
+## Openthread
+
+| Repo                                    |   Branch    | Commit Hash                              |
+| --------------------------------------- | ----------  | ---------------------------------------- |
+| https://github.com/openthread/openthread |    main      | 7074a43e4577d32d5535d52e7940ed2ea7e3a528 |
 
 ## Connectivity Standards Alliance (CSA) connectedhomeip (Matter)
 
@@ -25,10 +31,10 @@ in this release of the Silicon Labs Matter Out of Box Experience
 
 | Repo                                            | Branch                     | Commit Hash       |
 | ----------------------------------------------- | ------------------------   | ----------------- |
-| https://github.com/SiliconLabs/matter           | release_2.3.0-1.3-alpha.1  | \<latest commit\> |
+| https://github.com/SiliconLabs/matter           | release_2.3.0-1.3-alpha.1  | c36f4a7745ac0092982933987c694a6b605de35d |
 
 ## Matter Accessory Device (MAD)
 
 | Repo                                            | Branch                     | Commit Hash           |
 | ----------------------------------------------- | ------------------------   | ----------------------|
-| https://github.com/SiliconLabs/matter           | release_2.3.0-1.3-alpha.1  | \<latest commit\>     |
+| https://github.com/SiliconLabs/matter           | release_2.3.0-1.3-alpha.1  | c36f4a7745ac0092982933987c694a6b605de35d|

docs/silabs/general/CUSTOM_MATTER_DEVICE.md

@@ -31,7 +31,6 @@ application example.
 ```shell
 $ ./scripts/tools/zap/run_zaptool.sh examples/lighting-app/lighting-common/lighting-app.zap
 ```
-
 On the left side of the application, there is a tab for Endpoint 0 and
 Endpoint 1. Endpoint 0 is known as the root node. This endpoint is akin to a
 "read me first" endpoint that describes itself and the other endpoints that make
@@ -53,7 +52,7 @@ your application to the full power of the Matter SDK.
 For example, if a lighting application only includes
 single color LEDs instead of RGB LEDs, it might make sense to disable the Color
 Control cluster in the ZAP configuration. Similarly, if a
-lighting application doesn't take advantage of the Level Control cluster,
+lighting application does not take advantage of the Level Control cluster,
 which allows you to customize current flow to an LED, it might make sense to
 disable the Level Control cluster.
 
@@ -64,11 +63,10 @@ generate ZAP code.
 ```shell
 $ ./scripts/tools/zap/generate.py examples/lighting-app/lighting-common/lighting-app.zap -o zzz_generated/lighting-app/zap-generated/
 ```
-
 ## Receiving Matter Commands
 
 All Matter commands reach the application through the intermediate function
-MatterPostAttributeChangeCallback(). When a request is made by a Matter client,
+`MatterPostAttributeChangeCallback()`. When a request is made by a Matter client,
 the information contained in the request is forwarded to a Matter application
 through this function. The command can then be dissected using conditional logic
 to call the proper application functions based on the most recent command
@@ -113,6 +111,7 @@ MoveToLevel action.
        LightMgr().InitiateActionLight(AppEvent::kEventType_Light, action_type, endpoint, *value);
     }
    ```
+
 ## Send a MoveToLevel Command and Read the CurrentLevel Attribute
 
 Rebuild the application and load the new executable on your EFR32 device. Send
@@ -133,4 +132,4 @@ $ mattertool levelcontrol read current-level 1 1 // Returns 10
 ```
 
 For more information on running a Silicon Labs lighting example on a Thunderboard Sense 2 see 
-[sl-newlight/efr32](https://github.com/SiliconLabs/matter/blob/latest/silabs_examples/sl-newLight/efr32/README.md).
+[sl-newlight/efr32](https://github.com/SiliconLabs/matter/blob/latest/silabs_examples/sl-newLight/efr32/README.md). 

docs/silabs/general/EP.md

@@ -7,7 +7,7 @@ developing an energy-friendly device.
 Using Energy Profiler with Matter is the same as any other protocol except that
 you need to start the usage from within Energy Profiler inside Simplicity
 Studio, rather than using an existing Simplicity Studio project, since your
-Matter project will not have been created inside Simplicity Studio.
+Matter project will not have been created inside Simplicity Studio. 
 
 Complete documentation on using the Simplicity Studio Energy Profiler is
 provided in the