diff --git a/.github/.wordlist.txt b/.github/.wordlist.txt
index 535c153c9c0639..a77179ec77e6b8 100644
--- a/.github/.wordlist.txt
+++ b/.github/.wordlist.txt
@@ -47,6 +47,7 @@ argc
args
argv
armeabi
+ARMmbed
armv
asdk
ASYNC
@@ -69,6 +70,7 @@ autotools
avL
AwaitNextAction
AXXXF
+AYNJV
babaf
backend
backticks
@@ -118,6 +120,7 @@ CACACACA
cacerts
CAfile
cancelled
+capacitive
CBB
cbd
CCMP
@@ -148,6 +151,7 @@ ChipImResponder
ChipLight
ChipMessageLayer
CHIPOBLE
+CHIPProjectConfig
CHIPTest
CHIPTool
chmod
@@ -169,6 +173,7 @@ clusterListName
ClusterRevision
ClusterTestGeneration
cmake
+CMakeLists
CMD
CMSIS
CMVH
@@ -207,6 +212,7 @@ cp
cpio
cpp
cppreference
+CPROTO
cpuapp
cpython
crypto
@@ -304,6 +310,7 @@ eabi
EB
ECC
ECD
+EchoMessage
EchoRequests
EchoResponse
EchoService
@@ -394,6 +401,7 @@ GetDeviceInfo
GetDns
GetIP
getstarted
+githubusercontent
gitignore
glibc
gn
@@ -524,10 +532,12 @@ lifecycle
lightbulb
lightin
LightingColor
+LightingState
LinkSoftwareAndDocumentationPack
LocalConfigDisabled
localhost
localstatedir
+LockingState
loopback
LowPower
LPC
@@ -558,6 +568,11 @@ matterUTestLib
MaxInterval
MaxIntervalCeilingSeconds
MaxRtrAdvInterval
+mbed
+MbedCommissioning
+MbedNewTarget
+mbedos
+mbedTarget
mbedTLS
mcu
MCUboot
@@ -582,6 +597,7 @@ MfrDeviceCert
MfrDeviceId
mgmt
microcontroller
+microcontrollers
MicroSD
middleware
Minicom
@@ -607,6 +623,8 @@ Multiband
Multicast
multilib
Multiprotocol
+multithreaded
+mutexes
MX
mydir
MyPASSWORD
@@ -653,6 +671,7 @@ OnOff
OnOffClusterTest
OnPlatformEvent
OO
+OpenOCD
OpenSSL
OpenThread
OpenThreadDemo
@@ -690,6 +709,7 @@ peerAddrStr
pem
percentageLiftValue
pexpect
+pickString
PID
Pigweed
PinCode
@@ -714,15 +734,18 @@ productrev
ProductRevision
ProductURL
proto
+protobuf
protos
Prover
PRs
PSCAN
PSK
+PSoC
PTR
pts
PumpConfigurationAndControl
pwd
+PWM
PXXXF
py
pychip
@@ -768,6 +791,7 @@ repo
req
Requestor
responder
+retargeting
reusability
rfid
rfids
@@ -802,8 +826,8 @@ SDC
SDHC
SDK
sdkconfig
-SDKs
SDK's
+SDKs
SDKTARGETSYSROOT
sdl
segger
@@ -837,6 +861,7 @@ softmmu
SoftwareDiagnostics
SoftwareVersion
SoftwareVersionString
+SPI
spinel
src
SRP
@@ -846,6 +871,7 @@ startoffset
StartScan
stderr
stdout
+sterm
str
strcpy
su
@@ -877,6 +903,7 @@ systemduserunitdir
sysv
TargetNavigator
TBD
+tcl
TCP
teardown
Telink
diff --git a/docs/guides/images/matter_mbedos_overview_simplified.png b/docs/guides/images/matter_mbedos_overview_simplified.png
new file mode 100644
index 00000000000000..065a5b7a44e122
Binary files /dev/null and b/docs/guides/images/matter_mbedos_overview_simplified.png differ
diff --git a/docs/guides/mbedos_add_new_target.md b/docs/guides/mbedos_add_new_target.md
new file mode 100644
index 00000000000000..92e38a8eb27ac6
--- /dev/null
+++ b/docs/guides/mbedos_add_new_target.md
@@ -0,0 +1,115 @@
+
+ 
+
+
+ Mbed-OS add new hardware target
+
+# Overview
+
+This document shows how to add the new Mbed OS hardware target to Matter
+project.
+
+Please check the list of supported
+[development boards](https://os.mbed.com/platforms/) which are compatible with
+Mbed OS.
+
+In order to adapt the new hardware target to the Matter project, you need to
+remember about the following requirements:
+
+- Bluetooth Low Energy support.
+- Wireless communication module with WiFi or Thread network support (IPv6
+ protocol is required).
+- Serial port support
+- On-chip debug with OpenOCD support
+
+Additional target component requirements are different for each of example
+application. Check the **Device UI** paragraph in example description.
+
+# Example Application
+
+The first step to add the new target to each of example application is to modify
+the `examples/example_name/mbed/mbed_app.json` file. It contains the common
+project settings and override the default values for supported boards. You
+should add the necessary components and parameters for the target there.
+
+If the new target uses the external libraries, it will be required to link it in
+the CMakeLists.txt file.
+
+# Building
+
+To add the new hardware target to the build system the
+`scripts/examples/mbed_example.sh` script should be modify. Extend
+**SUPPORTED_TARGET_BOARD** variable with a new target name.
+
+Example:
+
+ SUPPORTED_TARGET_BOARD=(CY8CPROTO_062_4343W NEW_TARGET_NAME)
+
+The next step is add the target name to build task in `.vscode/task.json` file.
+Extend the **options** variable in **mbedTarget** input setting.
+
+Example:
+
+ {
+ "type": "pickString",
+ "id": "mbedTarget",
+ "description": "What mbed target do you want to use?",
+ "options": ["CY8CPROTO_062_4343W", "NEW_TARGET_NAME"],
+ "default": "CY8CPROTO_062_4343W"
+ }
+
+# Flashing
+
+Mbed OS example application flashing process uses the
+[Open On-Chip Debugger](http://openocd.org/). The first step is to create the
+target configuration file inside `config/mbed/scripts` directory. The file name
+should be the same as target and the extension should be **.tcl**. The target
+CPU and programming interface definitions are essential parts of the
+configuration file.
+
+The next steps are the same as for building process. Adding the name of the
+target to `scripts/examples/mbed_example.sh` and `.vscode/task.json` files
+allows the use of available flashing processes.
+
+Additional flashing option is based on VSCode launch task. Adding the new target
+to it required `.vscode/launch.json` modification. Extend the **options**
+variable in **mbedTarget** input setting.
+
+Example:
+
+ {
+ "type": "pickString",
+ "id": "mbedTarget",
+ "description": "What mbed target do you want to use?",
+ "options": ["CY8CPROTO_062_4343W", "NEW_TARGET_NAME"],
+ "default": "CY8CPROTO_062_4343W"
+ }
+
+# Debugging
+
+Debugging process of Mbed OS applications is also based on VSCode launch task.
+Adding the new target to it required `.vscode/launch.json` modification. Extend
+the **options** variable in **mbedTarget** input setting.
+
+Example:
+
+ {
+ "type": "pickString",
+ "id": "mbedTarget",
+ "description": "What mbed target do you want to use?",
+ "options": ["CY8CPROTO_062_4343W", "NEW_TARGET_NAME"],
+ "default": "CY8CPROTO_062_4343W"
+ }
+
+# CI
+
+The Matter project continue integration process is based on Github Actions tool.
+It uses workflow configuration files to execute actions on CI server.
+
+To add the new target to the validation process of building Mbed OS applications
+you need to modify the `.github/workflows/examples-mbed.yaml` file. Extend the
+job's environment variable **APP_TARGET** with the target name.
+
+Example:
+
+ APP_TARGET: [CY8CPROTO_062_4343W, NEW_TARGET_NAME]
diff --git a/docs/guides/mbedos_commissioning.md b/docs/guides/mbedos_commissioning.md
new file mode 100644
index 00000000000000..f0c950948f62f2
--- /dev/null
+++ b/docs/guides/mbedos_commissioning.md
@@ -0,0 +1,276 @@
+
+
+
+
+ Matter Arm Mbed OS provisioning guide
+
+- [Overview](#overview)
+- [Prerequisites](#prerequisites)
+- [CHIPTool for Android](#chiptool-for-android)
+ - [Building and installing](#building-and-installing)
+ - [Accessory Matter device setup](#accessory-matter-device-setup)
+ - [Device commissioning for Android](#device-commissioning-for-android)
+ - [Sending ZCL commands](#sending-zcl-commands)
+- [POSIX CLI CHIPTool](#posix-cli-chiptool)
+ - [Building](#building)
+ - [Device commissioning for CLI](#device-commissioning-for-cli)
+ - [Sending ZCL commands](#sending-zcl-commands-1)
+- [Python Device Controller](#python-device-controller)
+ - [Building and installing](#building-and-installing-1)
+ - [Device commissioning for Python Device Controller](#device-commissioning-for-python-device-controller)
+ - [Sending ZCL commands](#sending-zcl-commands-2)
+ - [ZCL commands details](#zcl-commands-details)
+
+
+
+# Overview
+
+This document provides a step-by-step guide how to commission any Matter
+application. For demonstration purposes the Lighting app is used.
+
+The provisioning process is composed of the following stages:
+
+- CHIPTool discovers a Matter accessory device over Bluetooth Low Energy
+ (BLE).
+
+- CHIPTool establishes a secure channel to the device over BLE, and sends
+ network credentials data.
+
+BLE is only used during first phase. Afterwards, only the IP connectivity
+between the smartphone and the accessory device is needed to send messages.
+
+# Prerequisites
+
+To complete all the steps in the tutorial, you need:
+
+- A smartphone with Android 8+ or PC with Ubuntu 20.04 and Bluetooth
+ connectivity
+
+- A WiFi Access Point (smartphone router, standalone AP, wireless router or
+ PC)
+
+- Any currently supported target device (for example, a Cypress PSoC6
+ CY8CPROTO-062-4343W board)
+
+# CHIPTool for Android
+
+## Building and installing
+
+To make provisioning possible and to control the Matter device from your Android
+based smartphone, you must first build and install the CHIPTool application.
+
+To build the CHIPTool application for your smartphone, read
+[Android building guide](android_building.md).
+
+After building, install the application by completing the following steps:
+
+1. Install the Android Debug Bridge (adb) package by running the following
+ command:
+
+ $ sudo apt install android-tools-adb
+
+2. Enable **USB debugging** on your smartphone. See the
+ [Configure on-device developer options](https://developer.android.com/studio/debug/dev-options)
+ guide on the Android Studio hub for detailed information.
+3. If the **Install via USB** option is supported for your Android version,
+ turn it on.
+4. Plug your smartphone into a USB port on your PC.
+5. Run the following command to install the application, with _matter-dir_
+ replaced with the path to the Matter source directory:
+
+ $ adb install out/android-$TARGET_CPU-chip-tool/outputs/apk/debug/app-debug.apk
+
+6. Navigate to settings on your smartphone and grant **Camera** and
+ **Location** permissions to CHIPTool.
+
+Android CHIPTool is now ready to be used for commissioning.
+
+## Accessory Matter device setup
+
+To prepare the accessory Matter device for commissioning (called rendezvous),
+complete the following steps:
+
+- Open a serial terminal session to connect to the UART console of the
+ accessory device. You can use **mbed-tools** for this purpose
+ ([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+To start the rendezvous, CHIPTool must get the commissioning information from
+the Matter device. The data payload is encoded within a QR code and is printed
+to the UART console.
+
+- Reset the device.
+
+- Find a message similar to the following one in the application logs:
+
+ [INFO][CHIP]: [SVR]Copy/paste the below URL in a browser to see the QR Code:
+ [INFO][CHIP]: [SVR]https://dhrishi.github.io/connectedhomeip/qrcode.html?data=MT%3AYNJV7VSC00CMVH7SR00
+
+- Open URL from the console to display the QR in a web browser.
+
+## Device commissioning for Android
+
+To commission Matter device onto the network created complete the following
+steps:
+
+- Enable Bluetooth and Location services on your smartphone.
+
+- Connect the smartphone to the WiFi Network
+
+- Open the CHIPTool application on your smartphone.
+
+- Tap the 'PROVISION CHIP DEVICE WITH WI-FI' button and scan the commissioning
+ QR code.
+
+- Go through the the paring and connecting Bluetooth on your smartphone (you
+ will see a few pop-up messages appear as the commissioning progresses.
+ Finally, the network settings screen appears.
+
+- In the network settings screen enter the Wi-Fi credentials and tap the Save
+ Network button to send a WiFi provisioning message to the accessory device.
+
+- After successful completion of the process, the application returns to the
+ main screen.
+
+## Sending ZCL commands
+
+After the accessory device has been successfully commissioned to the network, it
+is possible to communicate with it using IP. Matter uses Zigbee Cluster Library
+(ZCL) protocol which defines common means for applications to communicate.
+
+Communication with the device via ZCL commands is possible by using buttons of
+the main screen.
+
+For example, selecting the 'LIGHT ON/OFF & LEVEL CLUSTER' button opens the
+screen which allows controlling the light dimming. Tap either the ON or the OFF
+button to toggle between min and max brightness. Use the slider to modify the
+brightness between 0-255.
+
+If **Lighting LED** is available then brightness change can be observed.
+
+> For more details about Android CHIPTool please visit
+> [CHIPTool](../../src/android/CHIPTool/README.md)
+
+# POSIX CLI CHIPTool
+
+## Building
+
+To make provisioning possible and to control the Matter device from Linux-based
+device, you can build and run the Matter Client example application on it.
+
+To build the POSIX CLI CHIPTool application check the guide
+[POSIX CLI guide](../../examples/chip-tool/README.md).
+
+## Device commissioning for CLI
+
+In order to send commands to a device, it must be paired with the client and
+connected to the network.
+
+To run the commissioning process via BLE, run the built executable and pass it
+the network ssid and password, fabric id, discriminator and pairing code of the
+remote device.
+
+Example:
+
+ $ chip-tool pairing ble-wifi network_ssid network_password 0 20202021 3840
+
+## Sending ZCL commands
+
+If the commissioning process was successful, it is possible to send a ZCL
+command to the device which initiate a certain action.
+
+To send a ZCL commands, run the executable and pass it the target cluster name,
+the target command name as well as an endpoint id.
+
+The endpoint id must be between 1 and 240.
+
+For example:
+
+ $ chip-tool onoff on 1
+
+The client will send a single command packet and then exit.
+
+> For more details about POSIX CLI CHIPTool please visit
+> [POSIX CLI CHIPTool](../../examples/chip-tool/README.md)
+
+# Python Device Controller
+
+## Building and installing
+
+To make provisioning possible and to control the Matter device with Python
+application, you can build and run the Python CHIP controller.
+
+To build and install the Python Device Controller application check the guide
+[Python Device Controller guide](python_chip_controller_building.md).
+
+## Device commissioning for Python Device Controller
+
+In order to send commands to a device, it must be paired with the client and
+connected to the network.
+
+To run the commissioning process via BLE:
+
+- Run Device Controller:
+
+ chip-device-ctrl
+
+- Scan BLE devices:
+
+ chip-device-ctrl > ble-scan
+
+- Connect the device via BLE (provide the accessory device discriminator,
+ setup pin code and node ID):
+
+ chip-device-ctrl > connect -ble 3840 20202021 1234
+
+- Pass the Wi-Fi credentials to the device:
+
+ chip-device-ctrl > zcl NetworkCommissioning AddWiFiNetwork 1234 0 0 ssid=str:TESTSSID credentials=str:P455W4RD breadcrumb=0 timeoutMs=1000
+
+- Enable the Wi-Fi interface:
+
+ chip-device-ctrl > zcl NetworkCommissioning EnableNetwork 1234 0 0 networkID=str:TESTSSID breadcrumb=0 timeoutMs=1000
+
+- Close BLE connection:
+
+ chip-device-ctrl > zcl NetworkCommissioning EnableNetwork 1234 0 0 networkID=str:TESTSSID breadcrumb=0 timeoutMs=1000
+
+- Discover IP address of the device (address is cached in the controller for
+ later usage). You should provide the fabric and node ID:
+
+ chip-device-ctrl > resolve 5544332211 1234
+
+## Sending ZCL commands
+
+If the commissioning process was successful, it is possible to send a ZCL
+command to the device which initiates a certain action.
+
+`zcl [arguments]`
+
+Example:
+
+ chip-device-ctrl > zcl LevelControl MoveWithOnOff 12344321 1 0 moveMode=1 rate=2
+
+### ZCL commands details
+
+To get the list of supported clusters run:
+
+ chip-device-ctrl > zcl ?
+
+To get the list of available commands in cluster run:
+
+ chip-device-ctrl > zcl ?
+
+**Format of arguments**
+
+For any integer and char string (null terminated) types, just use `key=value`,
+for example: `rate=2`, `string=123`, `string_2="123 456"`
+
+For byte string type, use `key=encoding:value`, currently, we support `str` and
+`hex` encoding, the `str` encoding will encode a NULL terminated string. For
+example, `networkId=hex:0123456789abcdef` (for
+`[0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef]`), `ssid=str:Test` (for
+`['T', 'e', 's', 't', 0x00]`).
+
+For boolean type, use `key=True` or `key=False`
diff --git a/docs/guides/mbedos_platform_overview.md b/docs/guides/mbedos_platform_overview.md
new file mode 100644
index 00000000000000..7252f992369422
--- /dev/null
+++ b/docs/guides/mbedos_platform_overview.md
@@ -0,0 +1,146 @@
+
+
+
+
+# Mbed-OS platform overview
+
+The Mbed-OS platform is a
+[Matter](https://github.com/project-chip/connectedhomeip) platform that uses Arm
+Mbed-OS 6.
+
+The following diagram shows a simplified structure of a Matter application which
+runs on the top of the Mbed-OS.
+
+
+ 
+
+
+# ARM Mbed-OS
+
+Arm Mbed OS is an open source embedded operating system designed specifically
+for the "things" in the Internet of Things. It includes all the features you
+need to develop a connected product based on an Arm Cortex-M microcontroller,
+including security, connectivity, an RTOS and drivers for sensors and I/O
+devices.
+
+Mbed OS provides an abstraction layer for the microcontrollers it runs on, so
+that developers can focus on writing C/C++ applications that call functionality
+available on a range of hardware. That means Mbed OS applications can be reused
+on any Mbed-compatible platform.
+
+Mbed OS uses a hardware abstraction layer (HAL) to support the most common parts
+of a microcontroller, such as timers. This foundation facilitates writing
+applications against a common set of application programming interfaces (APIs);
+device automatically includes necessary libraries and driver support for
+standard MCU peripherals, such as I2C, serial and SPI.
+
+Mbed OS has an RTOS core, so it supports deterministic, multithreaded, real-time
+software execution. The RTOS primitives are always available, allowing drivers
+and applications to rely on threads, semaphores, mutexes and other RTOS
+features.
+
+The structure of Mbed OS enables matching applications and storage systems. In
+other words, where the block level storage options vary and are application
+dependent, The file system that best fits the IoT device can be chosen. The FAT
+file system - backed by an SD card - provides compatibility with other operating
+systems, such as Windows, Mac OS or Linux. When high reliability and recovery
+from power failure are important, it makes sense to use our embedded file
+system, backed with a (Q)SPI NOR flash chip.
+
+Finally, Mbed OS implements the retargeting layer and boot process integration
+of each supported toolchain, so application development feels similar to C or
+C++ development for any other operating system.
+
+# Bluetooth and IP stacks
+
+In the Mbed-oS platform applications, the Bluetooth LE interface is used to
+perform pairing and Wi-Fi network provisioning operations between the Matter
+device and the Matter controller. Afterwards, the fully provisioned device is
+able to communicate with other devices inside the Wi-Fi network.
+
+For the Bluetooth LE communication purposes, the Mbed-OS platform application is
+using
+[ARM Mbed BLE](https://os.mbed.com/docs/mbed-os/latest/apis/bluetooth-apis.html)
+(also called BLE_API) - Bluetooth Low Energy software solution which interfaces
+with the BLE controller on the hardware target. Arm Mbed BLE hides the BLE
+stack’s complexity behind C++ abstractions and is compatible with all
+BLE-enabled Mbed board. The Mbed OS BLE_API automatically configuring the
+clocks, timers and other hardware peripherals to work at their lowest power
+consumption.
+
+For Wi-FI communication purposes, the Mbed-OS application is using the internal
+Mbed LWIP stack and Mbed Socket API together. To integrate it with Matter
+network layer, special glue socket layer has been introduced to take care of
+adapting the Mbed socket to BSD interface which is used inside the Matter
+endpoints implementation.
+
+## Matter integration
+
+The Bluetooth LE and Wi-Fi used stacks provided by the Mbed-OS have been
+integrated with the Matter stack using a special intermediate layer.
+
+This layer contains platform-specific implementations of abstract manager
+interfaces defined in the Matter stack. The application is able to use Matter's
+platform agnostic interfaces and no additional platform-related actions are
+needed to perform communication through the Matter stack.
+
+# Matter example applications
+
+Sample Matter applications are provided for the Mbed OS platform. They can be
+used to speed up development:
+
+- [shell](../../examples/shell/mbed)
+- [all-clusters-app](../../examples/all-clusters-app/mbed)
+- [lock-app](../../examples/lock-app/mbed/README.md)
+- [lighting-app](../../examples/lighting-app/mbed/README.md)
+- [pigweed-app](../../examples/pigweed-app/mbed/README.md)
+
+## Example configuration
+
+Each of the supporting examples contains the `config.in` file which allows you
+to configure the application in a proper way. You can define/disable/enable
+application settings. Then they are propagated through Mbed-OS and Matter stack
+build systems.
+
+## Matter stack configuration
+
+In each of supported examples, the Matter stack can be configured by modifying
+`CHIPProjectConfig.h` file which is placed inside the project directory.
+
+## Mbed-OS configuration
+
+Mbed-OS gives possibility to tweak its parameters by using the
+[Mbed-OS configuration system](https://os.mbed.com/docs/mbed-os/latest/program-setup/advanced-configuration.html).
+The same configuration system can be used to change default hardware target
+setup used in application. Additionally, it is the first place for adding
+support of the new hardware target support into the application. Mbed-OS
+configuration system can be accessed by modifying the `mbed_app.json` file which
+exists in each sample project directory.
+
+## Build system
+
+The Mbed-OS platform makes use of the following build systems to generate ninja
+build scripts:
+
+- GN - Used by the Matter project in majority of cases.
+- CMake (+ mbed-tools) - Used by the Mbed-OS user application and other
+ components within Mbed ecosystem.
+
+Matter's stack and platform modules are built with GN and output a library file.
+The application, Mbed-OS and target specific libraries are built with CMake and
+the Matter library file is imported during the compilation process.
+
+## Build profiles
+
+Arm Mbed OS defines three collections of toolchain flags used during the build:
+
+- develop
+- release
+- debug
+
+Build profiles can be easy selected when building example application using
+either vscode task or its associated build script directly
+([mbed_examples.sh](../../scripts/examples/mbed_example.sh)).
+
+For more details about each of this profiles, please visit official
+[ARM Mbed documentation](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
diff --git a/examples/all-clusters-app/mbed/README.md b/examples/all-clusters-app/mbed/README.md
new file mode 100644
index 00000000000000..45224ea31ecd8b
--- /dev/null
+++ b/examples/all-clusters-app/mbed/README.md
@@ -0,0 +1,253 @@
+
+
+
+
+ Matter Arm Mbed OS All Clusters Example Application
+
+The Arm Mbed OS All Clusters Example demonstrates device commissioning process
+and all available clusters control.
+
+You can use this example as a reference for creating your own application.
+
+The example is based on
+[Matter](https://github.com/project-chip/connectedhomeip) and Arm Mbed OS, and
+supports remote access and control of device over a WiFi network.
+
+The example behaves as a Matter accessory, in other words a device that can be
+paired into an existing Matter network and can be controlled by this network.
+
+
+
+- [Overview](#overview)
+ - [Bluetooth Low Energy advertising](#bluetooth-low-energy-advertising)
+ - [Bluetooth Low Energy rendezvous](#bluetooth-low-energy-rendezvous)
+ - [WiFi provisioning](#wifi-provisioning)
+- [Run application](#run-application)
+ - [Environment setup](#environment-setup)
+ - [Building](#building)
+ - [Flashing](#flashing)
+ - [Debugging](#debugging)
+ - [Testing](#testing)
+ - [Serial port terminal](#serial-port-terminal)
+ - [CHIP Tools](#chip-tools)
+ - [Supported devices](#supported-devices)
+ - [Notes](#notes)
+- [Device UI](#device-ui)
+ - [Notes](#notes-1)
+
+
+
+# Overview
+
+The Matter device that runs the All Clusters application is controlled by the
+Matter controller device over WiFi. By default, the Matter device is
+disconnected, and it should be paired with Matter controller and get
+configuration from it. Actions required before establishing full communication
+are described below.
+
+## Bluetooth Low Energy advertising
+
+To commission the device onto a Matter network, the device must be discoverable
+over BLE. The BLE advertising starts automatically after device boot-up.
+
+## Bluetooth Low Energy rendezvous
+
+In Matter, the commissioning procedure (called rendezvous) is done over BLE
+between a Matter device and the Matter controller, where the controller has the
+commissioner role.
+
+To start the rendezvous, the controller must get the commissioning information
+from the Matter device. The data payload is encoded within a QR code, printed to
+the UART console.
+
+## WiFi provisioning
+
+The last part of the rendezvous procedure, provisioning involves sending the
+network credentials from the Matter controller to the Matter device. As a
+result, device is able to join the network and communicate with other devices in
+the network.
+
+# Run application
+
+## Environment setup
+
+Before building the example, check out the Matter repository and sync submodules
+using the following command:
+
+ $ git submodule update --init
+
+Building the example application requires the use of **ARM Mbed-OS** sources and
+the **arm-none-gnu-eabi** toolchain. The OpenOCD package is used for flashing
+purpose.
Some additional packages may be needed, depending on selected
+build target and its requirements.
+
+> **The VSCode devcontainer has these components pre-installed. Using the VSCode
+> devcontainer is the recommended way to interact with Arm Mbed-OS port of the
+> Matter Project.**
+>
+> **Please read this [README.md](../../..//docs/VSCODE_DEVELOPMENT.md) for more
+> information about using VSCode in container.**
+
+To initialize the development environment, download all registered sub-modules
+and activate the environment:
+
+```
+$ source ./scripts/bootstrap.sh
+$ source ./scripts/activate.sh
+```
+
+If packages are already installed then you just need to activate the development
+environment:
+
+```
+$ source ./scripts/activate.sh
+```
+
+## Building
+
+The All Clusters application can be built in the same way as any other Matter
+example ported to the mbed-os platform.
+
+- **by using generic vscode task**:
+
+```
+Command Palette (F1) => Run Task... => Run Mbed Application => build => all-clusters-app => (board name) => (build profile)`
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=build -a=all-clusters-app -b= -p=
+```
+
+Both approaches are limited to supported evaluation boards which are listed in
+[Supported devices](#supported_devices) paragraph.
+
+Mbed OS defines three building profiles: _develop, debug_ and _release_. For
+more details please visit
+[ARM Mbed OS build profiles](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
+
+When using the building script, it is possible expand the list of acceptable
+targets; this may be useful for rapid testing of a new mbed-targets.
+
+## Flashing
+
+The All Clusters application can be flashed in the same way as any other Matter
+example ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to upload a binary
+image and reset the device.
+
+- **by using VSCode task**:
+
+```
+Command Palette (F1) => Run Task... -> Run Mbed Application => flash => all-clusters-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=flash -a=all-clusters-app -b= -p=
+```
+
+- **by using VSCode launch task**:
+
+```
+Run and Debug (Ctrl+Shift+D) => Flash Mbed examples => Start Debugging (F5) => (board name) => all-clusters-app => (build profile)
+```
+
+The last option uses the Open On-Chip Debugger to open and manage the gdb-server
+session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset
+device.
+
+It is possible to connect to an external gdb-server session by using a specific
+**'Flash Mbed examples [remote]'** task.
+
+## Debugging
+
+Debugging can be performed in the same was as with any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to to open and manage
+the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server
+to upload binary image and control debugging.
+
+```
+Run and Debug (Ctrl+Shift+D) => Debug Mbed examples => Start Debugging (F5) => (board name) => all-clusters-app => (build profile)
+```
+
+It is possible to connect to an external gdb-server session by using specific
+**'Debug Mbed examples [remote]'** task.
+
+## Testing
+
+### Serial port terminal
+
+The application traces are streaming to serial output. To start communication
+open a terminal session and connect to the serial port of the device. You can
+use **mbed-tools** for this purpose
+([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+After device reset these lines should be visible:
+
+ [INFO][CHIP]: [-]Mbed all-clusters-app example application start
+ ...
+ [INFO][CHIP]: [-]Mbed all-clusters-app example application run
+
+The all-clusters-app application launched correctly and you can follow traces in
+the terminal.
+
+### CHIP Tools
+
+Read the [MbedCommissioning](../../../docs/guides/mbedos_commissioning.md) to
+see how to use different CHIP tools to commission and control the application
+within a WiFi network.
+
+## Supported devices
+
+| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
+| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | CY8CPROTO-062-4343W
LEDs
- Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
Slider
+
+
+
+ Matter Arm Mbed OS Lighting Example Application
+
+The Arm Mbed OS Lighting Example demonstrates how to remotely control a dimmable
+white light source. The example takes advantage of the IO available on board:
+
+- A button press turns the light on or off.
+- Intensity can be displayed and changed depending on the target IO (PWM
+ output, slider).
+
+You can use this example as a reference for creating your own application.
+
+The example is based on
+[Matter](https://github.com/project-chip/connectedhomeip) and Arm Mbed OS, and
+supports remote access and control of lighting over a WiFi network.
+
+The example behaves as a Matter accessory, in other words a device that can be
+paired into an existing Matter network and can be controlled by this network.
+
+Pigweed functionalities are also integrated into this application. The Remote
+Procedure Call (RPC) server is created. It allows sending commands through the
+serial port to the device. The following RPC protocols services are available:
+
+- **Device** - perform basic operations on device: reboot, factory reset,
+ software update or get basic device information
+- **Button** - trigger specific button event (push/release)
+- **Lighting** - set/get lighting state (on/off/brightness level)
+
+
+
+- [Overview](#overview)
+ - [Bluetooth Low Energy advertising](#bluetooth-low-energy-advertising)
+ - [Bluetooth Low Energy rendezvous](#bluetooth-low-energy-rendezvous)
+ - [WiFi provisioning](#wifi-provisioning)
+- [Run application](#run-application)
+ - [Environment setup](#environment-setup)
+ - [Building](#building)
+ - [Flashing](#flashing)
+ - [Debugging](#debugging)
+ - [Testing](#testing)
+ - [Serial port terminal](#serial-port-terminal)
+ - [CHIP Tools](#chip-tools)
+ - [RPC console](#rpc-console)
+ - [Supported devices](#supported-devices)
+ - [Notes](#notes)
+- [Device UI](#device-ui)
+ - [Notes](#notes-1)
+
+
+
+# Overview
+
+The Matter device that runs the lighting application is controlled by the Matter
+controller device over WiFi. By default, the Matter device is disconnected , and
+it should be paired with Matter controller and get configuration from it.
+Actions required before establishing full communication are described below.
+
+## Bluetooth Low Energy advertising
+
+To commission the device onto a Matter network, the device must be discoverable
+over BLE. The BLE advertising starts automatically after device boot-up.
+
+## Bluetooth Low Energy rendezvous
+
+In Matter, the commissioning procedure (called rendezvous) is done over BLE
+between a Matter device and the Matter controller, where the controller has the
+commissioner role.
+
+To start the rendezvous, the controller must get the commissioning information
+from the Matter device. The data payload is encoded within a QR code, printed to
+the UART console.
+
+## WiFi provisioning
+
+The last part of the rendezvous procedure, provisioning involves sending the
+network credentials from the Matter controller to the Matter device. As a
+result, device is able to join the network and communicate with other devices in
+the network.
+
+# Run application
+
+## Environment setup
+
+Before building the example, check out the Matter repository and sync submodules
+using the following command:
+
+ $ git submodule update --init
+
+Building the example application requires the use of **ARM Mbed-OS** sources and
+the **arm-none-gnu-eabi** toolchain. The OpenOCD package is used for flashing
+purpose.
Some additional packages may be needed, depending on selected
+build target and its requirements.
+
+> **The VSCode devcontainer has these components pre-installed. Using the VSCode
+> devcontainer is the recommended way to interact with Arm Mbed-OS port of the
+> Matter Project.**
+>
+> **Please read this [README.md](../../..//docs/VSCODE_DEVELOPMENT.md) for more
+> information about using VSCode in container.**
+
+To initialize the development environment, download all registered sub-modules
+and activate the environment:
+
+```
+$ source ./scripts/bootstrap.sh
+$ source ./scripts/activate.sh
+```
+
+If packages are already installed then you just need to activate the development
+environment:
+
+```
+$ source ./scripts/activate.sh
+```
+
+## Building
+
+The Lighting application can be built in the same way as any other Matter
+example ported to the mbed-os platform.
+
+- **by using generic vscode task**:
+
+```
+Command Palette (F1) => Run Task... => Run Mbed Application => build => lighting-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=build -a=lighting-app -b= -p=
+```
+
+Both approaches are limited to supported evaluation boards which are listed in
+[Supported devices](#supported_devices) paragraph.
+
+Mbed OS defines three building profiles: _develop, debug_ and _release_. For
+more details please visit
+[ARM Mbed OS build profiles](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
+
+When using the building script, it is possible expand the list of acceptable
+targets; this may be useful for rapid testing of a new mbed-targets.
+
+## Flashing
+
+The Lighting application can be flashed in the same way as any other Matter
+example ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to upload a binary
+image and reset the device.
+
+- **by using VSCode task**:
+
+```
+Command Palette (F1) => Run Task... -> Run Mbed Application => flash => lighting-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=flash -a=lighting-app -b= -p=
+```
+
+- **by using VSCode launch task**:
+
+```
+Run and Debug (Ctrl+Shift+D) => Flash Mbed examples => Start Debugging (F5) => (board name) => lighting-app => (build profile)
+```
+
+The last option uses the Open On-Chip Debugger to open and manage the gdb-server
+session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset
+device.
+
+It is possible to connect to an external gdb-server session by using specific
+**'Flash Mbed examples [remote]'** task.
+
+## Debugging
+
+Debugging can be performed in the same was as with any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to to open and manage
+the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server
+to upload binary image and control debugging.
+
+```
+Run and Debug (Ctrl+Shift+D) => Debug Mbed examples => Start Debugging (F5) => (board name) => lighting-app => (build profile)
+```
+
+It is possible to connect to an external gdb-server session by using specific
+**'Debug Mbed examples [remote]'** task.
+
+## Testing
+
+### Serial port terminal
+
+The application traces are streaming to serial output. To start communication
+open a terminal session and connect to the serial port of the device. You can
+use **mbed-tools** for this purpose
+([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+After device reset these lines should be visible:
+
+ [INFO][CHIP]: [-]Mbed lighting-app example application start
+ ...
+ [INFO][CHIP]: [-]Mbed lighting-app example application run
+
+The lighting-app application launched correctly and you can follow traces in the
+terminal.
+
+### CHIP Tools
+
+Read the [MbedCommissioning](../../../docs/guides/mbedos_commissioning.md) to
+see how to use different CHIP tools to commission and control the application
+within a WiFi network.
+
+### RPC console
+
+The RPC console is an interactive Python shell console, where the different RPC
+command can be invoked. It is a complete solution for interacting with hardware
+devices using pw_rpc over a pw_hdlc transport. For more details about Pigweed
+modules visit [Pigweed modules](https://pigweed.dev/module_guides.html).
+
+** Building and installing
**
+
+To build and install the RPC console check the guide
+[CHIP RPC console](../../common/pigweed/rpc_console/README.md).
+
+** Run
**
+
+To start the RPC console run the following command and provide device connection
+parameters as arguments:
+
+- --device/-d the serial port to use.
+- --baudrate/-b the baud rate to use.
+- --output/-o the file to which to write device output (HDLC channel 1),
+ provide - or omit for stdout.
+- --socket-addr/-s alternatively use socket to connect to server, type default
+ for localhost:33000, or manually input the server address:port.
+
+Example:
+
+ python -m chip_rpc.console -d /dev/ttyUSB0 -b 115200 -o /tmp/pw_rpc.out
+
+To control the lighting type the following command, where you define if 'on'
+state is true or false:
+
+ In [1]: rpcs.chip.rpc.Lighting.Set(on=True)
+
+The response from the device should be:
+
+ Out[1]: (Status.OK, pw.protobuf.Empty())
+
+To check the lighting state type the following command:
+
+ In [1]: rpcs.chip.rpc.Lighting.Get()
+
+The response from the device should contain the current lighting state:
+
+ Out[1]: Status.OK, chip.rpc.LightingState(on=True))
+
+For more details about RPC console and supported services visit
+[CHIP RPC console](../../common/pigweed/rpc_console/README.md).
+
+## Supported devices
+
+The example supports building and running on the following mbed-enabled devices:
+
+| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
+| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | CY8CPROTO-062-4343W
LEDs
- Board has only one usable LED (LED4) which corresponds to USER LED from UI.
- Lighting LED should be an external component connected to PB9_6 pin (active high).
Buttons
- SW2 push-button is not used in this example due to its interaction with WIFI module interrupt line.
- Button 0 corresponds to BTN0 capacitive button.
- Button 1 corresponds to BTN1 capacitive button.
Slider
- The board's touch slider corresponds to UI slider
+
+
+
+ Matter Arm Mbed OS Lock Example Application
+
+The Arm Mbed OS Lock Example demonstrates how to remotely control a door lock
+device with one basic bolt. The example takes advantage of the IO available on
+board:
+
+- A button press close or open the lock.
+- A LED shows the lock state.
+
+You can use this example as a reference for creating your own application.
+
+The example is based on
+[Matter](https://github.com/project-chip/connectedhomeip) and Arm Mbed OS, and
+supports remote access and control of lock over a WiFi network.
+
+The example behaves as a Matter accessory, in other words a device that can be
+paired into an existing Matter network and can be controlled by this network.
+
+
+
+- [Overview](#overview)
+ - [Bluetooth Low Energy advertising](#bluetooth-low-energy-advertising)
+ - [Bluetooth Low Energy rendezvous](#bluetooth-low-energy-rendezvous)
+ - [WiFi provisioning](#wifi-provisioning)
+- [Run application](#run-application)
+ - [Environment setup](#environment-setup)
+ - [Building](#building)
+ - [Flashing](#flashing)
+ - [Debugging](#debugging)
+ - [Testing](#testing)
+ - [Serial port terminal](#serial-port-terminal)
+ - [CHIP Tools](#chip-tools)
+ - [RPC console](#rpc-console)
+ - [Supported devices](#supported-devices)
+ - [Notes](#notes)
+ - [Device UI](#device-ui)
+
+
+
+# Overview
+
+The Matter device that runs the lock application is controlled by the Matter
+controller device over WiFi. By default, the Matter device is disconnected , and
+it should be paired with Matter controller and get configuration from it.
+Actions required before establishing full communication are described below.
+
+## Bluetooth Low Energy advertising
+
+To commission the device onto a Matter network, the device must be discoverable
+over BLE. The BLE advertising starts automatically after device boot-up.
+
+## Bluetooth Low Energy rendezvous
+
+In Matter, the commissioning procedure (called rendezvous) is done over BLE
+between a Matter device and the Matter controller, where the controller has the
+commissioner role.
+
+To start the rendezvous, the controller must get the commissioning information
+from the Matter device. The data payload is encoded within a QR code, printed to
+the UART console.
+
+## WiFi provisioning
+
+The last part of the rendezvous procedure, provisioning involves sending the
+network credentials from the Matter controller to the Matter device. As a
+result, device is able to join the network and communicate with other devices in
+the network.
+
+# Run application
+
+## Environment setup
+
+Before building the example, check out the Matter repository and sync submodules
+using the following command:
+
+ $ git submodule update --init
+
+Building the example application requires the use of **ARM Mbed-OS** sources and
+the **arm-none-gnu-eabi** toolchain. The OpenOCD package is used for flashing
+purpose.
Some additional packages may be needed, depending on selected
+build target and its requirements.
+
+> **The VSCode devcontainer has these components pre-installed. Using the VSCode
+> devcontainer is the recommended way to interact with Arm Mbed-OS port of the
+> Matter Project.**
+>
+> **Please read this [README.md](../../..//docs/VSCODE_DEVELOPMENT.md) for more
+> information about using VSCode in container.**
+
+To initialize the development environment, download all registered sub-modules
+and activate the environment:
+
+```
+$ source ./scripts/bootstrap.sh
+$ source ./scripts/activate.sh
+```
+
+If packages are already installed then you just need to activate the development
+environment:
+
+```
+$ source ./scripts/activate.sh
+```
+
+## Building
+
+The Lock application can be built in the same way as any other Matter example
+ported to the mbed-os platform.
+
+- **by using generic vscode task**:
+
+```
+Command Palette (F1) => Run Task... => Run Mbed Application => build => lock-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=build -a=lock-app -b= -p=
+```
+
+Both approaches are limited to supported evaluation boards which are listed in
+[Supported devices](#supported_devices) paragraph.
+
+Mbed OS defines three building profiles: _develop, debug_ and _release_. For
+more details please visit
+[ARM Mbed OS build profiles](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
+
+When using the building script, it is possible expand the list of acceptable
+targets; this may be useful for rapid testing of a new mbed-targets.
+
+## Flashing
+
+The Lock application can be flashed in the same way as any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to upload a binary
+image and reset the device.
+
+- **by using VSCode task**:
+
+```
+Command Palette (F1) => Run Task... -> Run Mbed Application => flash => lock-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=flash -a=lock-app -b= -p=
+```
+
+- **by using VSCode launch task**:
+
+```
+Run and Debug (Ctrl+Shift+D) => Flash Mbed examples => Start Debugging (F5) => (board name) => lock-app => (build profile)
+```
+
+The last option uses the Open On-Chip Debugger to open and manage the gdb-server
+session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset
+device.
+
+It is possible to connect to an external gdb-server session by using specific
+**'Flash Mbed examples [remote]'** task.
+
+## Debugging
+
+Debugging can be performed in the same was as with any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to to open and manage
+the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server
+to upload binary image and control debugging.
+
+```
+Run and Debug (Ctrl+Shift+D) => Debug Mbed examples => Start Debugging (F5) => (board name) => lock-app => (build profile)
+```
+
+It is possible to connect to an external gdb-server session by using specific
+**'Debug Mbed examples [remote]'** task.
+
+## Testing
+
+### Serial port terminal
+
+The application traces are streaming to serial output. To start communication
+open a terminal session and connect to the serial port of the device. You can
+use **mbed-tools** for this purpose
+([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+After device reset these lines should be visible:
+
+ [INFO][CHIP]: [-]Mbed lock-app example application start
+ ...
+ [INFO][CHIP]: [-]Mbed lock-app example application run
+
+The lock-app application launched correctly and you can follow traces in the
+terminal.
+
+### CHIP Tools
+
+Read the [MbedCommissioning](../../../docs/guides/mbedos_commissioning.md) to
+see how to use different CHIP tools to commission and control the application
+within a WiFi network.
+
+### RPC console
+
+The RPC console is an interactive Python shell console, where the different RPC
+command can be invoked. It is a complete solution for interacting with hardware
+devices using pw_rpc over a pw_hdlc transport. For more details about Pigweed
+modules visit [Pigweed modules](https://pigweed.dev/module_guides.html).
+
+** Building and installing
**
+
+To build and install the RPC console check the guide
+[CHIP RPC console](../../common/pigweed/rpc_console/README.md).
+
+** Run
**
+
+To start the RPC console run the following command and provide device connection
+parameters as arguments:
+
+- --device/-d the serial port to use.
+- --baudrate/-b the baud rate to use.
+- --output/-o the file to which to write device output (HDLC channel 1),
+ provide - or omit for stdout.
+- --socket-addr/-s alternatively use socket to connect to server, type default
+ for localhost:33000, or manually input the server address:port.
+
+Example:
+
+ python -m chip_rpc.console -d /dev/ttyUSB0 -b 115200 -o /tmp/pw_rpc.out
+
+To control the lock type the following command, where you define if 'on' state
+is true or false:
+
+ In [1]: rpcs.chip.rpc.Locking.Set(locked=True)
+
+The response from the device should be:
+
+ Out[1]: (Status.OK, pw.protobuf.Empty())
+
+To check the lock state type the following command:
+
+ In [1]: rpcs.chip.rpc.Locking.Get()
+
+The response from the device should contain the current lock state:
+
+ Out[1]: Status.OK, chip.rpc.LockingState(locked=True))
+
+For more details about RPC console and supported services visit
+[CHIP RPC console](../../common/pigweed/rpc_console/README.md).
+
+## Supported devices
+
+The example supports building and running on the following mbed-enabled devices:
+
+| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
+| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | CY8CPROTO-062-4343W
LEDs
- Board has only one usable LED (LED4) which corresponds to USER LED from UI.
- Lock state LED should be an external component connected to PB9_6 pin (active high).
Buttons
- SW2 push-button is not used in this example due to its interaction with WIFI module interrupt line.
- Button 0 corresponds to BTN0 capacitive button.
- Button 1 corresponds to BTN1 capacitive button.
Slider
+
+
+
+ Matter Arm Mbed OS Pigweed Example Application
+
+The Arm Mbed OS Pigweed Example demonstrates the usage of Pigweed module
+functionalities in an application.
+
+You can use this example as a reference for creating your own application.
+
+The example is based on
+[Matter](https://github.com/project-chip/connectedhomeip) and Arm Mbed OS, and
+supports remote access and control of device over a serial port.
+
+Pigweed functionalities are integrated into this application. The Remote
+Procedure Call (RPC) server is created. It allows sending commands through the
+serial port to the device. The following RPC protocols services are available:
+
+- **Echo** - receive message and send the same payload back
+
+
+
+- [Overview](#overview)
+- [Run application](#run-application)
+ - [Environment setup](#environment-setup)
+ - [Building](#building)
+ - [Flashing](#flashing)
+ - [Debugging](#debugging)
+ - [Testing](#testing)
+ - [Serial port terminal](#serial-port-terminal)
+ - [RPC console](#rpc-console)
+ - [Supported devices](#supported-devices)
+ - [Notes](#notes)
+- [Device UI](#device-ui)
+ - [Notes](#notes-1)
+
+
+
+# Overview
+
+Pigweed libraries are built and organized in a way that enables faster and more
+reliable development. In the Matter project, the Pigweed module is planned to be
+used to create system infrastructures, for example for performing on-device
+tests, but considering its general functionalities, it can be useful also in
+other cases.
+
+# Run application
+
+## Environment setup
+
+Before building the example, check out the Matter repository and sync submodules
+using the following command:
+
+ $ git submodule update --init
+
+Building the example application requires the use of **ARM Mbed-OS** sources and
+the **arm-none-gnu-eabi** toolchain. The OpenOCD package is used for flashing
+purpose.
Some additional packages may be needed, depending on selected
+build target and its requirements.
+
+> **The VSCode devcontainer has these components pre-installed. Using the VSCode
+> devcontainer is the recommended way to interact with Arm Mbed-OS port of the
+> Matter Project.**
+>
+> **Please read this [README.md](../../..//docs/VSCODE_DEVELOPMENT.md) for more
+> information about using VSCode in container.**
+
+To initialize the development environment, download all registered sub-modules
+and activate the environment:
+
+```
+$ source ./scripts/bootstrap.sh
+$ source ./scripts/activate.sh
+```
+
+If packages are already installed then you just need to activate the development
+environment:
+
+```
+$ source ./scripts/activate.sh
+```
+
+## Building
+
+The Pigweed application can be built in the same way as any other Matter example
+ported to the mbed-os platform.
+
+- **by using generic vscode task**:
+
+```
+Command Palette (F1) => Run Task... => Run Mbed Application => build => pigweed-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=build -a=pigweed-app -b= -p=
+```
+
+Both approaches are limited to supported evaluation boards which are listed in
+[Supported devices](#supported_devices) paragraph.
+
+Mbed OS defines three building profiles: _develop, debug_ and _release_. For
+more details please visit
+[ARM Mbed OS build profiles](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
+
+When using the building script, it is possible expand the list of acceptable
+targets; this may be useful for rapid testing of a new mbed-targets.
+
+## Flashing
+
+The Pigweed application can be flashed in the same way as any other Matter
+example ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to upload a binary
+image and reset the device.
+
+- **by using VSCode task**:
+
+```
+Command Palette (F1) => Run Task... -> Run Mbed Application => flash => pigweed-app => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=flash -a=pigweed-app -b= -p=
+```
+
+- **by using VSCode launch task**:
+
+```
+Run and Debug (Ctrl+Shift+D) => Flash Mbed examples => Start Debugging (F5) => (board name) => pigweed-app => (build profile)
+```
+
+The last option uses the Open On-Chip Debugger to open and manage the gdb-server
+session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset
+device.
+
+It is possible to connect to an external gdb-server session by using specific
+**'Flash Mbed examples [remote]'** task.
+
+## Debugging
+
+Debugging can be performed in the same was as with any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to to open and manage
+the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server
+to upload binary image and control debugging.
+
+```
+Run and Debug (Ctrl+Shift+D) => Debug Mbed examples => Start Debugging (F5) => (board name) => pigweed-app => (build profile)
+```
+
+It is possible to connect to an external gdb-server session by using specific
+**'Debug Mbed examples [remote]'** task.
+
+## Testing
+
+### Serial port terminal
+
+The application traces are streaming to serial output. To start communication
+open a terminal session and connect to the serial port of the device. You can
+use **mbed-tools** for this purpose
+([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+After device reset these lines should be visible:
+
+ [INFO][CHIP]: [-]Mbed pigweed-app example application start
+ ...
+ [INFO][CHIP]: [-]Mbed pigweed-app example application run
+
+The pigweed-app application launched correctly and you can follow traces in the
+terminal.
+
+### RPC console
+
+The RPC console is an interactive Python shell console, where the different RPC
+command can be invoked. It is a complete solution for interacting with hardware
+devices using pw_rpc over a pw_hdlc transport. For more details about Pigweed
+modules visit [Pigweed modules](https://pigweed.dev/module_guides.html).
+
+** Building and installing
**
+
+To build and install the RPC console check the guide
+[CHIP RPC console](../../common/pigweed/rpc_console/README.md).
+
+** Run
**
+
+To start the RPC console run the following command and provide device connection
+parameters as arguments:
+
+- --device/-d the serial port to use.
+- --baudrate/-b the baud rate to use.
+- --output/-o the file to which to write device output (HDLC channel 1),
+ provide - or omit for stdout.
+- --socket-addr/-s alternatively use socket to connect to server, type default
+ for localhost:33000, or manually input the server address:port.
+
+Example:
+
+ python -m chip_rpc.console -d /dev/ttyUSB0 -b 115200 -o /tmp/pw_rpc.out
+
+To send the echo message type the following command, where you define the
+message content:
+
+ In [1]: rpcs.pw.rpc.EchoService.Echo(msg="Hello device")
+
+The response from the device should be:
+
+ Out[1]: (Status.OK, pw.rpc.EchoMessage(msg="Hello device"))
+
+For more details about RPC console and supported services visit
+[CHIP RPC console](../../common/pigweed/rpc_console/README.md).
+
+## Supported devices
+
+The example supports building and running on the following mbed-enabled devices:
+
+| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
+| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | CY8CPROTO-062-4343W
LEDs
- Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
Slider
+
+
+
+ Matter Arm Mbed OS Shell Example Application
+
+The Arm Mbed OS Shell Example exposes configuration and management APIs via a
+command line interface (CLI). Use the shell CLI to experiment with Matter
+interactively, which can also be used with additional application code.
+
+You can use this example as a reference for creating your own application.
+
+The example is based on
+[Matter](https://github.com/project-chip/connectedhomeip) and Arm Mbed OS, and
+supports remote access and control of device over serial port.
+
+
+
+- [Overview](#overview)
+- [Run application](#run-application)
+ - [Environment setup](#environment-setup)
+ - [Building](#building)
+ - [Flashing](#flashing)
+ - [Debugging](#debugging)
+ - [Testing](#testing)
+ - [Serial port terminal](#serial-port-terminal)
+ - [Supported devices](#supported-devices)
+ - [Notes](#notes)
+- [Shell commands](#shell-commands)
+
+
+
+# Overview
+
+The Matter device that runs the shell application can be controlled over serial
+port. The shell is used to parse a command line and call the corresponding
+service execution. There is a set of common shell commands which performs basic
+device operations. Mbed OS application also supports some custom services and
+corresponding shell commands allow them execution.
+
+# Run application
+
+## Environment setup
+
+Before building the example, check out the Matter repository and sync submodules
+using the following command:
+
+ $ git submodule update --init
+
+Building the example application requires the use of **ARM Mbed-OS** sources and
+the **arm-none-gnu-eabi** toolchain. The OpenOCD package is used for flashing
+purpose.
Some additional packages may be needed, depending on selected
+build target and its requirements.
+
+> **The VSCode devcontainer has these components pre-installed. Using the VSCode
+> devcontainer is the recommended way to interact with Arm Mbed-OS port of the
+> Matter Project.**
+>
+> **Please read this [README.md](../../..//docs/VSCODE_DEVELOPMENT.md) for more
+> information about using VSCode in container.**
+
+To initialize the development environment, download all registered sub-modules
+and activate the environment:
+
+```
+$ source ./scripts/bootstrap.sh
+$ source ./scripts/activate.sh
+```
+
+If packages are already installed then you just need to activate the development
+environment:
+
+```
+$ source ./scripts/activate.sh
+```
+
+## Building
+
+The shell application can be built in the same way as any other Matter example
+ported to the mbed-os platform.
+
+- **by using generic vscode task**:
+
+```
+Command Palette (F1) => Run Task... => Run Mbed Application => build => shell => (board name) => (build profile)`
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=build -a=shell -b= -p=
+```
+
+Both approaches are limited to supported evaluation boards which are listed in
+[Supported devices](#supported_devices) paragraph.
+
+Mbed OS defines three building profiles: _develop, debug_ and _release_. For
+more details please visit
+[ARM Mbed OS build profiles](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
+
+When using the building script, it is possible expand the list of acceptable
+targets; this may be useful for rapid testing of a new mbed-targets.
+
+## Flashing
+
+The shell application can be flashed in the same way as any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to upload a binary
+image and reset the device.
+
+- **by using VSCode task**:
+
+```
+Command Palette (F1) => Run Task... -> Run Mbed Application => flash => shell => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=flash -a=shell -b= -p=
+```
+
+- **by using VSCode launch task**:
+
+```
+Run and Debug (Ctrl+Shift+D) => Flash Mbed examples => Start Debugging (F5) => (board name) => shell => (build profile)
+```
+
+The last option uses the Open On-Chip Debugger to open and manage the gdb-server
+session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset
+device.
+
+It is possible to connect to an external gdb-server session by using specific
+**'Flash Mbed examples [remote]'** task.
+
+## Debugging
+
+Debugging can be performed in the same was as with any other Matter example
+ported to mbed-os platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to to open and manage
+the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server
+to upload binary image and control debugging.
+
+```
+Run and Debug (Ctrl+Shift+D) => Debug Mbed examples => Start Debugging (F5) => (board name) => shell => (build profile)
+```
+
+It is possible to connect to an external gdb-server session by using specific
+**'Debug Mbed examples [remote]'** task.
+
+## Testing
+
+### Serial port terminal
+
+To start communication open a serial terminal session and connect to the serial
+port of the device. You can use **mbed-tools** for this purpose
+([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+After device reset these lines should be visible:
+
+ [INFO][CHIP]: [-]Mbed shell example application start
+ ...
+ [INFO][CHIP]: [-]Mbed shell example application run
+
+The shell application launched correctly. Send commands and wait for the
+response [Shell commands](#shell-commands).
+
+Example:
+
+ > echo Hello
+ Hello
+ Done
+
+## Supported devices
+
+The example supports building and running on the following mbed-enabled devices:
+
+| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
+| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | CY8CPROTO-062-4343W
LEDs
Buttons
Slider
+
+
+
+ Matter Arm Mbed OS Unit Tests Application
+
+The Arm Mbed OS Unit Tests application executes all supported unit tests on the
+device.
+
+The application is based on
+[Matter](https://github.com/project-chip/connectedhomeip) and Arm Mbed OS, and
+validates Matter solution components directly on the device.
+
+
+
+- [Overview](#overview)
+- [Run application](#run-application)
+ - [Environment setup](#environment-setup)
+ - [Building](#building)
+ - [Flashing](#flashing)
+ - [Debugging](#debugging)
+ - [Testing](#testing)
+ - [Serial port terminal](#serial-port-terminal)
+ - [Supported devices](#supported-devices)
+ - [Notes](#notes)
+
+
+
+# Overview
+
+The Matter unit tests are included in a monolithic library and allow to validate
+most of the components used by Matter examples applications. The main goal of
+this application is to run registered tests on the device and check the results.
+The final result is the number of tests that failed.
+
+# Run application
+
+## Environment setup
+
+Before building the application, check out the Matter repository and sync
+submodules using the following command:
+
+ $ git submodule update --init
+
+Building the application requires the use of **ARM Mbed-OS** sources and the
+**arm-none-gnu-eabi** toolchain. The OpenOCD package is used for flashing
+purpose.
Some additional packages may be needed, depending on selected
+build target and its requirements.
+
+> **The VSCode devcontainer has these components pre-installed. Using the VSCode
+> devcontainer is the recommended way to interact with Arm Mbed-OS port of the
+> Matter Project.**
+>
+> **Please read this [README.md](../../..//docs/VSCODE_DEVELOPMENT.md) for more
+> information about using VSCode in container.**
+
+To initialize the development environment, download all registered sub-modules
+and activate the environment:
+
+```
+$ source ./scripts/bootstrap.sh
+$ source ./scripts/activate.sh
+```
+
+If packages are already installed then you just need to activate the development
+environment:
+
+```
+$ source ./scripts/activate.sh
+```
+
+## Building
+
+The Unit Test application can be built analogously to Matter examples ported to
+the mbed-os platform. It uses a custom script therefore it is a separate defined
+target.
+
+- **by using generic vscode task**:
+
+```
+Command Palette (F1) => Run Task... => Run Mbed Unit Tests => build => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/tests/mbed/mbed_unit_tests.sh -c=build -b= -p=
+```
+
+Both approaches are limited to supported evaluation boards which are listed in
+[Supported devices](#supported_devices) paragraph.
+
+Mbed OS defines three building profiles: _develop, debug_ and _release_. For
+more details please visit
+[ARM Mbed OS build profiles](https://os.mbed.com/docs/mbed-os/latest/program-setup/build-profiles-and-rules.html).
+
+When using the building script, it is possible expand the list of acceptable
+targets; this may be useful for rapid testing of a new mbed-targets.
+
+## Flashing
+
+The Unit Test application can be flashed analogously to Matter examples ported
+to the mbed-os platform. It uses a custom script therefore it is a separate
+defined target.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to upload a binary
+image and reset the device.
+
+- **by using VSCode task**:
+
+```
+Command Palette (F1) => Run Task... -> Run Mbed Unit Tests => flash => (board name) => (build profile)
+```
+
+- **by calling explicitly building script:**
+
+```
+${MATTER_ROOT}/scripts/tests/mbed/mbed_unit_tests.sh -c=flash -b= -p=
+```
+
+- **by using VSCode launch task**:
+
+```
+Run and Debug (Ctrl+Shift+D) => Flash Mbed unit tests => Start Debugging (F5) => (board name) => (build profile)
+```
+
+The last option uses the Open On-Chip Debugger to open and manage the gdb-server
+session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset
+device.
+
+It is possible to connect to an external gdb-server session by using specific
+**'Flash Mbed unit tests [remote]'** task.
+
+## Debugging
+
+Debugging can be performed analogously to Matter examples ported to the mbed-os
+platform.
+
+The [Open On-Chip Debugger](http://openocd.org/) is used to to open and manage
+the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server
+to upload binary image and control debugging.
+
+```
+Run and Debug (Ctrl+Shift+D) => Debug Mbed unit tests => Start Debugging (F5) => (board name) => (build profile)
+```
+
+It is possible to connect to an external gdb-server session by using specific
+**'Debug Mbed unit tests [remote]'** task.
+
+## Testing
+
+### Serial port terminal
+
+The test results are streaming to serial output. To start communication open a
+terminal session and connect to the serial port of the device. You can use
+**mbed-tools** for this purpose
+([mbed-tools](https://github.com/ARMmbed/mbed-tools)):
+
+ mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
+
+After device reset these lines should be visible:
+
+ [INFO][CHIP]: [-]Mbed unit-tests application start
+ ...
+ [INFO][CHIP]: [-]Mbed unit-tests application run
+
+The unit tests application launched correctly and registered tests are executed.
+
+The final result is the number of tests that failed:
+
+ [INFO][CHIP]: [-]CHIP test status: 0
+
+## Supported devices
+
+The application supports building and running on the following mbed-enabled
+devices:
+
+| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
+| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | CY8CPROTO-062-4343W
LEDs
- Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
Slider