diff --git a/docs/guides/nxp_rw61x_ota_software_update.md b/docs/guides/nxp_rw61x_ota_software_update.md index 0c04e6c849f8bb..c3bd5227a054ed 100644 --- a/docs/guides/nxp_rw61x_ota_software_update.md +++ b/docs/guides/nxp_rw61x_ota_software_update.md @@ -1,44 +1,77 @@ # Matter Over-The-Air Software Update with NXP RW61x example applications ## Overview -The OTA Requestor feature enables the device to be informed of, download and apply a software update from an OTA Provider. -This section explains how to perform an OTA Software Update with NXP RW61x example applications. Throughout this guide, the all-clusters application is used as an example. +The OTA Requestor feature enables the device to be informed of, download and +apply a software update from an OTA Provider. -In general, the Over-The-Air Software Update process consists of the following steps : -- The OTA Requestor queries an update image from the OTA Provider which responds according to its availability. -- The update image is received in blocks and stored in the external flash of the device. -- Once the update image is fully downloaded, the bootloader is notified and the device resets applying the update in test-mode. -- If the test is successful, the update is applied permanently. Otherwise, the bootloader reverts back to the primary application, preventing any downgrade. +This section explains how to perform an OTA Software Update with NXP RW61x +example applications. Throughout this guide, the all-clusters application is +used as an example. + +In general, the Over-The-Air Software Update process consists of the following +steps : + +- The OTA Requestor queries an update image from the OTA Provider which + responds according to its availability. +- The update image is received in blocks and stored in the external flash of + the device. +- Once the update image is fully downloaded, the bootloader is notified and + the device resets applying the update in test-mode. +- If the test is successful, the update is applied permanently. Otherwise, the + bootloader reverts back to the primary application, preventing any + downgrade. ### Flash Memory Layout The RW61x Flash is divided into different regions as follow : -- Bootloader : MCUBoot resides at the base of the flash and occupies 0x20000 (128 kB). -- Primary application partition : The example application which would be run by the bootloader (active application). The size reserved for this partition is 4.4 MB. -- Secondary application partition : Update image received with the OTA (candidate application). The size reserved for the partition is 4.4 MB. -Notes : -- The CPU1/CPU2 firmware are embedded in the CPU3 example application. -- The sizes of the primary and secondary applications are provided as an example (currently 4.4 MB is reserved for each partition). The size can be changed by modifying the `m_app_max_sectors` value in the linker script of the application (`RW610_flash.ld`). +- Bootloader : MCUBoot resides at the base of the flash and occupies 0x20000 + (128 kB). +- Primary application partition : The example application which would be run + by the bootloader (active application). The size reserved for this partition + is 4.4 MB. +- Secondary application partition : Update image received with the OTA + (candidate application). The size reserved for the partition is 4.4 MB. + +Notes : + +- The CPU1/CPU2 firmware are embedded in the CPU3 example application. +- The sizes of the primary and secondary applications are provided as an + example (currently 4.4 MB is reserved for each partition). The size can be + changed by modifying the `m_app_max_sectors` value in the linker script of + the application (`RW610_flash.ld`). ### MCUBoot Bootloader -MCUBoot is an open-source secure bootloader used by RW61x to apply the self-upgrade. For more details, please refer to the [MCUBoot documentation](https://github.com/mcu-tools/mcuboot/blob/main/docs/design.md). +MCUBoot is an open-source secure bootloader used by RW61x to apply the +self-upgrade. For more details, please refer to the +[MCUBoot documentation](https://github.com/mcu-tools/mcuboot/blob/main/docs/design.md). -In our use case, the bootloader runs the application residing in the primary partition. In order to run the OTA update image, the bootloader will swap the content of the primary and the secondary partitions. This type of upgrade is called swap-move and is the default upgrade configured by MCUBoot. +In our use case, the bootloader runs the application residing in the primary +partition. In order to run the OTA update image, the bootloader will swap the +content of the primary and the secondary partitions. This type of upgrade is +called swap-move and is the default upgrade configured by MCUBoot. ## OTA Software Update process for RW61x example application ### Flashing the bootloader -In order for the device to perform the software update, the MCUBoot bootloader must be flashed first at the base of the flash. A step-by-step guide is given below. +In order for the device to perform the software update, the MCUBoot bootloader +must be flashed first at the base of the flash. A step-by-step guide is given +below. + +- It is recommended to start with erasing the external flash of the device, + for this JLink from Segger can be used. It can be downloaded and installed + from https://www.segger.com/products/debug-probes/j-link. Once installed, + JLink can be run using the command line : -- It is recommended to start with erasing the external flash of the device, for this JLink from Segger can be used. It can be downloaded and installed from https://www.segger.com/products/debug-probes/j-link. Once installed, JLink can be run using the command line : ``` $ JLink ``` + Run the following commands : + ``` J-Link > connect Device> ? # you will be presented with a dialog -> select `RW612` @@ -52,15 +85,25 @@ Speed> # J-Link > exec EnableEraseAllFlashBanks J-Link > erase 0x8000000, 0x88a0000 ``` -- Using MCUXPresso, import the `mcuboot_opensource` demo example from the SDK previously downloaded. -![mcuboot_demo](../../examples/platform/nxp/rt/rw61x/doc/images/mcuboot_demo.PNG) -- Before building the demo example, it should be specified that the application to be run by the bootloader is monolithic. As a result, only one image will be upgraded by the bootloader. This can be done by defining `MONOLITHIC_APP` as 1 in the settings of the `mcuboot_opensource` project : + +- Using MCUXPresso, import the `mcuboot_opensource` demo example from the SDK + previously downloaded. + ![mcuboot_demo](../../examples/platform/nxp/rt/rw61x/doc/images/mcuboot_demo.PNG) +- Before building the demo example, it should be specified that the + application to be run by the bootloader is monolithic. As a result, only one + image will be upgraded by the bootloader. This can be done by defining + `MONOLITHIC_APP` as 1 in the settings of the `mcuboot_opensource` project : + ``` Right click on the Project -> Properties -> C/C++ Build -> Settings -> Tool Settings -> MCU C Compiler -> Preprocessor -> Add "MONOLITHIC_APP=1" in the Defined Symbols ``` + ![rw610_mcuboot_monolithic](../../examples/platform/nxp/rt/rw61x/doc/images/mcuboot_monolithic_app.PNG) -- Build the demo example project and program it to the target board. -- To run the flashed demo, either press the reset button of the device or use the debugger IDE of MCUXpresso. If it runs successfully, the following logs will be displayed on the terminal : + +- Build the demo example project and program it to the target board. +- To run the flashed demo, either press the reset button of the device or use + the debugger IDE of MCUXpresso. If it runs successfully, the following logs + will be displayed on the terminal : ``` hello sbl. @@ -73,97 +116,153 @@ erasing trailer; fa_id=2 Unable to find bootable image ``` -Note : By default, mcuboot application considers the primary and secondary partitions to be the size of 4.4 MB. If the size is to be changed, the partition addresses should be modified in the flash_partitioning.h accordingly. For more information about the flash partitioning with mcuboot, please refer to the dedicated readme.txt located in "`SDK_RW612/boards/rdrw612bga/ota_examples/mcuboot_opensource/`". +Note : By default, mcuboot application considers the primary and secondary +partitions to be the size of 4.4 MB. If the size is to be changed, the partition +addresses should be modified in the flash_partitioning.h accordingly. For more +information about the flash partitioning with mcuboot, please refer to the +dedicated readme.txt located in +"`SDK_RW612/boards/rdrw612bga/ota_examples/mcuboot_opensource/`". ### Generating and flashing the signed application image -After flashing the bootloader, the application can be programmed to the board. The image must have the following format : -- Header : contains general information about the image (version, size, magic...) -- Code of the application : generated binary -- Trailer : contains metadata needed by the bootloader such as the image signature, the upgrade type, the swap status... +After flashing the bootloader, the application can be programmed to the board. +The image must have the following format : + +- Header : contains general information about the image (version, size, + magic...) +- Code of the application : generated binary +- Trailer : contains metadata needed by the bootloader such as the image + signature, the upgrade type, the swap status... -The all-clusters application can be generated using the instructions from the [README.md 'Building'](../../examples/all-clusters-app/nxp/rt/rw61x/README.md#building) section. The application is automatically linked to be executed from the primary image partition, taking into consideration the offset imposed by mcuboot. +The all-clusters application can be generated using the instructions from the +[README.md 'Building'](../../examples/all-clusters-app/nxp/rt/rw61x/README.md#building) +section. The application is automatically linked to be executed from the primary +image partition, taking into consideration the offset imposed by mcuboot. +The resulting executable file found in out/debug/chip-rw61x-all-cluster-example +needs to be converted into raw binary format as shown below. -The resulting executable file found in out/debug/chip-rw61x-all-cluster-example needs to be converted into raw binary format as shown below. ``` arm-none-eabi-objcopy -R .flash_config -R .NVM -O binary chip-rw61x-all-cluster-example chip-rw61x-all-cluster-example.bin ``` -To sign the image and wrap the raw binary of the application with the header and trailer, "`imgtool`" is provided in the SDK and can be found in "`/middleware/mcuboot_opensource/scripts/`". -The following commands can be run (make sure to replace the /path/to/file/binary with the adequate files): +To sign the image and wrap the raw binary of the application with the header and +trailer, "`imgtool`" is provided in the SDK and can be found in +"`/middleware/mcuboot_opensource/scripts/`". + +The following commands can be run (make sure to replace the /path/to/file/binary +with the adequate files): ``` user@ubuntu: cd ~/Desktop/SDK_RW612/middleware/mcuboot_opensource/scripts user@ubuntu: python3 imgtool.py sign --key ~/Desktop/SDK_RW612/boards/rdrw612bga/ota_examples/mcuboot_opensource/keys/sign-rsa2048-priv.pem --align 4 --header-size 0x1000 --pad-header --slot-size 0x440000 --max-sectors 1088 --version "1.0" ~/Desktop/connectedhomeip/examples/all-clusters-app/nxp/rt/rw61x/out/debug/chip-rw61x-all-cluster-example.bin ~/Desktop/connectedhomeip/examples/all-clusters-app/nxp/rt/rw61x/out/debug/chip-rw61x-all-cluster-example_SIGNED.bin ``` -Notes : -- If internal SDK is used instead, the key can be found in : "`~/Desktop/SDK_RW612/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-priv.pem`". -- The arguments `slot-size` and `max-sectors` should be adjusted to the size of the partitions reserved for the primary and the secondary applications. (By default the size considered is 4.4 MB) -- In this example, the image is signed with the private key provided by the SDK as an example (`/path_to_sdk/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-priv.pem`), MCUBoot is built with its corresponding public key which would be used to verify the integrity of the image. It is possible to generate a new pair of keys using the following commands. This procedure should be done prior to building the mcuboot application. -- To generate the private key : +Notes : + +- If internal SDK is used instead, the key can be found in : + "`~/Desktop/SDK_RW612/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-priv.pem`". +- The arguments `slot-size` and `max-sectors` should be adjusted to the size + of the partitions reserved for the primary and the secondary applications. + (By default the size considered is 4.4 MB) +- In this example, the image is signed with the private key provided by the + SDK as an example + (`/path_to_sdk/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-priv.pem`), + MCUBoot is built with its corresponding public key which would be used to + verify the integrity of the image. It is possible to generate a new pair of + keys using the following commands. This procedure should be done prior to + building the mcuboot application. + +- To generate the private key : ``` user@ubuntu: python3 imgtool.py keygen -k priv_key.pem -t rsa-2048 ``` -- To extract the public key : + +- To extract the public key : ``` user@ubuntu: python3 imgtool.py getpub -k priv_key.pem ``` -- The extracted public key can then be copied to the `/path_to_sdk/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-pub.c`, given as a value to the rsa_pub_key[] array. +- The extracted public key can then be copied to the + `/path_to_sdk/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-pub.c`, + given as a value to the rsa_pub_key[] array. + +The resulting output is the signed binary of the application version "1.0". -The resulting output is the signed binary of the application version "1.0". +JLink can be used to flash the application at the address 0x8020000, using the +command : -JLink can be used to flash the application at the address 0x8020000, using the command : ``` J-Link > loadbin chip-rw61x-all-cluster-example_SIGNED.bin 0x8020000 ``` -The bootloader should then be able to jump directly to the start of the application and run it. +The bootloader should then be able to jump directly to the start of the +application and run it. ### Generating the OTA Update Image -To generate the OTA update image the same procedure can be followed from the [Generating and flashing the signed application image](#generating-and-flashing-the-signed-application-image) sub-section, replacing the "--version "1.0"" argument with "--version "2.0"" (recent version of the update). +To generate the OTA update image the same procedure can be followed from the +[Generating and flashing the signed application image](#generating-and-flashing-the-signed-application-image) +sub-section, replacing the "--version "1.0"" argument with "--version "2.0"" +(recent version of the update). -When the signed binary of the update is generated, the file should be converted into OTA format. To do so, the ota_image_tool is provided in the repo and can be used to convert a binary file into an .ota file. +When the signed binary of the update is generated, the file should be converted +into OTA format. To do so, the ota_image_tool is provided in the repo and can be +used to convert a binary file into an .ota file. ``` user@ubuntu:~/connectedhomeip$ : ./src/app/ota_image_tool.py create -v 0xDEAD -p 0xBEEF -vn 2 -vs "2.0" -da sha256 chip-rw61x-all-cluster-example_SIGNED.bin chip-rw61x-all-cluster-example.ota ``` -The generated OTA file can be used to perform the OTA Software Update. The instructions below describe the procedure step-by-step. + +The generated OTA file can be used to perform the OTA Software Update. The +instructions below describe the procedure step-by-step. ### Performing the OTA Software Update -Setup example : -- [Chip-tool](../../examples/chip-tool/README.md) application running on the RPi. -- OTA Provider application built on the same RPi (as explained below). -- RW61x board programmed with the example application (with the instructions above). +Setup example : + +- [Chip-tool](../../examples/chip-tool/README.md) application running on the + RPi. +- OTA Provider application built on the same RPi (as explained below). +- RW61x board programmed with the example application (with the instructions + above). + +Before starting the OTA process, the Linux OTA Provider application can be built +on the RPi (if not already present in the pre-installed apps) : -Before starting the OTA process, the Linux OTA Provider application can be built on the RPi (if not already present in the pre-installed apps) : ``` user@ubuntu:~/connectedhomeip$ : ./scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/ota-provider-app chip_config_network_layer_ble=false user@ubuntu:~/connectedhomeip$ : rm -rf /tmp/chip_* user@ubuntu:~/connectedhomeip$ : ./out/ota-provider-app/chip-ota-provider-app -f chip-rw61x-all-cluster-example.ota ``` -The OTA Provider should first be provisioned with chip-tool by assigning it the node id 1, and then granted the ACL entries : + +The OTA Provider should first be provisioned with chip-tool by assigning it the +node id 1, and then granted the ACL entries : + ``` user@ubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool pairing onnetwork 1 20202021 user@ubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": null}]' 1 0 ``` -The second step is to provision the device with the node id 2 using ble-wifi or ble-thread commissioning. For example : + +The second step is to provision the device with the node id 2 using ble-wifi or +ble-thread commissioning. For example : + ``` user@ubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool pairing ble-wifi 2 WIFI_SSID WIFI_PASSWORD 20202021 3840 ``` +Once commissioned, the OTA process can be initiated with the +"announce-ota-provider" command using chip-tool (the given numbers refer +respectively to [ProviderNodeId][vendorid] [AnnouncementReason][endpoint] +[node-id][endpoint-id]) : -Once commissioned, the OTA process can be initiated with the "announce-ota-provider" command using chip-tool (the given numbers refer respectively to [ProviderNodeId] [VendorId] [AnnouncementReason] [Endpoint] [node-id] [endpoint-id]) : ``` user@ubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0 ``` -When the full update image is downloaded and stored, the bootloader will be notified and the device will reboot with the update image. \ No newline at end of file +When the full update image is downloaded and stored, the bootloader will be +notified and the device will reboot with the update image. diff --git a/examples/all-clusters-app/nxp/rt/rw61x/README.md b/examples/all-clusters-app/nxp/rt/rw61x/README.md index 25bc51a8b2086a..d5b436d9fee8e1 100644 --- a/examples/all-clusters-app/nxp/rt/rw61x/README.md +++ b/examples/all-clusters-app/nxp/rt/rw61x/README.md @@ -1,14 +1,12 @@ # CHIP RW61x All-clusters Application -The all-clusters example implements a server which can be accessed by a CHIP controller and can accept basic cluster commands. +The all-clusters example implements a server which can be accessed by a CHIP +controller and can accept basic cluster commands. The example is based on -[Project CHIP](https://github.com/project-chip/connectedhomeip) and the NXP RW612 SDK, -and provides a prototype application that demonstrates device commissioning and different cluster -control. - - - +[Project CHIP](https://github.com/project-chip/connectedhomeip) and the NXP +RW612 SDK, and provides a prototype application that demonstrates device +commissioning and different cluster control.
@@ -27,24 +25,26 @@ control. The RW61x all-cluster application provides a working demonstration of the RW610/RW612 board integration, built using the Project CHIP codebase and the NXP -RW612 SDK. The example supports basic ZCL commands and acts as a thermostat device-type. +RW612 SDK. The example supports basic ZCL commands and acts as a thermostat +device-type. The example supports: -- Matter over Wi-Fi -- Matter over Openthread - +- Matter over Wi-Fi +- Matter over Openthread ### Hardware requirements + For Matter over Thread configuration : -- [`NXP RD-RW612-BGA`] board -- BLE/15.4 antenna (to plug in Ant1) + +- [`NXP RD-RW612-BGA`] board +- BLE/15.4 antenna (to plug in Ant1) For Matter over WiFi configuration : -- [`NXP RD-RW612-BGA`] or [`NXP RD-RW610-BGA`] board -- BLE antenna (to plug in Ant1) -- Wi-Fi antenna (to plug in Ant2) +- [`NXP RD-RW612-BGA`] or [`NXP RD-RW610-BGA`] board +- BLE antenna (to plug in Ant1) +- Wi-Fi antenna (to plug in Ant2) @@ -53,17 +53,20 @@ For Matter over WiFi configuration : In order to build the Project CHIP example, we recommend using a Linux distribution (the demo-application was compiled on Ubuntu 20.04). -- Follow instruction in [BUILDING.md](../../../../../docs/guides/BUILDING.md) to setup the environment to be able to build Matter. +- Follow instruction in [BUILDING.md](../../../../../docs/guides/BUILDING.md) + to setup the environment to be able to build Matter. - Download [RD-RW612 SDK v2.13.1](https://mcuxpresso.nxp.com/en/select). Creating an nxp.com account is required before being able to download the SDK. Once the account is created, login and follow the steps for downloading - SDK. The SDK Builder UI selection should be similar with - the one from the image below. In case you do not have access to the SDK, please ask your NXP representative. + SDK. The SDK Builder UI selection should be similar with the one from the + image below. In case you do not have access to the SDK, please ask your NXP + representative. ![MCUXpresso SDK Download](../../../../platform/nxp/rt/rw61x/doc/images/mcux-sdk-download.PNG) - (Note: All SDK components should be selected. If size is an issue Azure RTOS component can be omitted.) + (Note: All SDK components should be selected. If size is an issue Azure RTOS + component can be omitted.) - Start building the application. @@ -74,7 +77,8 @@ user@ubuntu:~/Desktop/git/connectedhomeip$ cd examples/all-clusters-app/nxp/rt/r ``` #### Building with Matter over Wifi configuration on RW61x -- Build Matter-over-Wifi configuration with BLE commissioning (ble-wifi) : + +- Build Matter-over-Wifi configuration with BLE commissioning (ble-wifi) : ``` user@ubuntu:~/Desktop/git/connectedhomeip/examples/all-clusters-app/nxp/rt/rw61x$ gn gen --args="chip_enable_wifi=true is_sdk_package=true" out/debug @@ -89,48 +93,69 @@ user@ubuntu:~/Desktop/git/connectedhomeip/examples/all-clusters-app/nxp/rt/rw61x user@ubuntu:~/Desktop/git/connectedhomeip/examples/all-clusters-app/nxp/rt/rw61x$ gn gen --args="chip_enable_openthread=true chip_inet_config_enable_ipv4=false chip_config_network_layer_ble=true is_sdk_package=true" out/debug user@ubuntu:~/Desktop/git/connectedhomeip/examples/all-clusters-app/nxp/rt/rw61x$ ninja -C out/debug ``` + #### General information -The resulting output file can be found in out/debug/chip-rw61x-all-cluster-example. +The resulting output file can be found in +out/debug/chip-rw61x-all-cluster-example. Optional GN options that can be added when building an application: -- To enable the [matter CLI](README.md#testing-the-all-clusters-application-with-matter-cli-enabled), the argument ```chip_enable_matter_cli=true``` must be added to the *gn gen* command. -- To switch the SDK type used, the argument ```is_=true``` must be added to the *gn gen* command (with being either sdk_package or sdk_internal). -- By default, the RW612 A1 board revision will be chosen. To switch to an A0 revision, the argument ```board_version=\"A0\"``` must be added to the *gn gen* command. -- To build the application in debug mode, the argument ```is_debug=true optimize_debug=false``` must be added to the *gn gen* command. -- To build with the option to have Matter certificates/keys pre-loaded in a specific flash area the argument ```chip_with_factory_data=1``` must be added to the *gn gen* command. (for more information see [Guide for writing manufacturing data on NXP devices](../../../../../docs/guides/nxp_manufacturing_flow.md). -- To build the application with the OTA Requestor enabled, the arguments ```chip_enable_ota_requestor=true no_mcuboot=false``` must be added to the *gn gen* command. (More information about the OTA Requestor feature in [OTA Requestor README](README_OTA_Requestor.md))) - +- To enable the + [matter CLI](README.md#testing-the-all-clusters-application-with-matter-cli-enabled), + the argument `chip_enable_matter_cli=true` must be added to the _gn gen_ + command. +- To switch the SDK type used, the argument `is_=true` must be added + to the _gn gen_ command (with being either sdk_package or + sdk_internal). +- By default, the RW612 A1 board revision will be chosen. To switch to an A0 + revision, the argument `board_version=\"A0\"` must be added to the _gn gen_ + command. +- To build the application in debug mode, the argument + `is_debug=true optimize_debug=false` must be added to the _gn gen_ command. +- To build with the option to have Matter certificates/keys pre-loaded in a + specific flash area the argument `chip_with_factory_data=1` must be added to + the _gn gen_ command. (for more information see + [Guide for writing manufacturing data on NXP devices](../../../../../docs/guides/nxp_manufacturing_flow.md). +- To build the application with the OTA Requestor enabled, the arguments + `chip_enable_ota_requestor=true no_mcuboot=false` must be added to the _gn + gen_ command. (More information about the OTA Requestor feature in + [OTA Requestor README](README_OTA_Requestor.md))) ## Manufacturing data -See [Guide for writing manufacturing data on NXP devices](../../../../../docs/guides/nxp_manufacturing_flow.md) +See +[Guide for writing manufacturing data on NXP devices](../../../../../docs/guides/nxp_manufacturing_flow.md) Other comments: -The all cluster app demonstrates the usage of encrypted Matter manufacturing data storage. Matter manufacturing data should be encrypted using an AES 128 software key before flashing them to the device flash. +The all cluster app demonstrates the usage of encrypted Matter manufacturing +data storage. Matter manufacturing data should be encrypted using an AES 128 +software key before flashing them to the device flash. ## Flashing and debugging + ### Flashing the All-Clusters application In order to flash the application we recommend using [MCUXpresso IDE (version >= 11.6.0)](https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE). -- Import the previously downloaded NXP SDK into MCUXpresso IDE. +- Import the previously downloaded NXP SDK into MCUXpresso IDE. -Right click the empty space in the MCUXpresso IDE "Installed SDKs" tab to show the menu, select the "Import archive" (or "Import folder" if a folder is used) menu item. +Right click the empty space in the MCUXpresso IDE "Installed SDKs" tab to show +the menu, select the "Import archive" (or "Import folder" if a folder is used) +menu item. - -- Import the connectedhomeip repo in MCUXpresso IDE as Makefile Project. Use _none_ as _Toolchain for Indexer Settings_: +- Import the connectedhomeip repo in MCUXpresso IDE as Makefile Project. Use + _none_ as _Toolchain for Indexer Settings_: ``` File -> Import -> C/C++ -> Existing Code as Makefile Project ``` -- Configure MCU Settings: +- Configure MCU Settings: ``` Right click on the Project -> Properties -> C/C++ Build -> MCU Settings -> Select RW612 -> Apply & Close @@ -138,7 +163,7 @@ Right click on the Project -> Properties -> C/C++ Build -> MCU Settings -> Selec ![MCU_Set](../../../../platform/nxp/rt/rw61x/doc/images/mcu-set.PNG) -- Configure the toolchain editor: +- Configure the toolchain editor: ``` Right click on the Project -> C/C++ Build-> Tool Chain Editor -> NXP MCU Tools -> Apply & Close @@ -146,32 +171,43 @@ Right click on the Project -> C/C++ Build-> Tool Chain Editor -> NXP MCU Tools - ![toolchain](../../../../platform/nxp/rt/rw61x/doc/images/toolchain.JPG) -- Create a debug configuration : +- Create a debug configuration : ``` Right click on the Project -> Debug -> As->SEGGER JLink probes -> OK -> Select elf file ``` -(Note : if SDK package is used, a simpler way could be duplicating the debug configuration from the SDK Hello World example after importing it.) -- Debug using the newly created configuration file. +(Note : if SDK package is used, a simpler way could be duplicating the debug +configuration from the SDK Hello World example after importing it.) + +- Debug using the newly created configuration file. ## Testing the example -CHIP Tool is a Matter controller which can be used to commission a Matter device into the network. For more information regarding how to use the CHIP Tool controller, please refer to the [CHIP Tool guide](../../../../../docs/guides/chip_tool_guide.md). - -To know how to commission a device over BLE, follow the instructions from [chip-tool's README.md 'Commission a device over BLE'][readme_ble_commissioning_section]. +CHIP Tool is a Matter controller which can be used to commission a Matter device +into the network. For more information regarding how to use the CHIP Tool +controller, please refer to the +[CHIP Tool guide](../../../../../docs/guides/chip_tool_guide.md). -[readme_ble_commissioning_section]:../../../../chip-tool/README.md#commission-a-device-over-ble +To know how to commission a device over BLE, follow the instructions from +[chip-tool's README.md 'Commission a device over +BLE'][readme_ble_commissioning_section]. -To know how to commissioning a device over IP, follow the instructions from [chip-tool's README.md 'Pair a device over IP'][readme_pair_ip_commissioning_section] +[readme_ble_commissioning_section]: + ../../../../chip-tool/README.md#commission-a-device-over-ble -[readme_pair_ip_commissioning_section]: ../../../../chip-tool/README.md#pair-a-device-over-ip +To know how to commissioning a device over IP, follow the instructions from +[chip-tool's README.md 'Pair a device over +IP'][readme_pair_ip_commissioning_section] +[readme_pair_ip_commissioning_section]: + ../../../../chip-tool/README.md#pair-a-device-over-ip #### Matter over wifi configuration : -The "ble-wifi" pairing method can be used in order to commission the device. + +The "ble-wifi" pairing method can be used in order to commission the device. #### Matter over thread configuration : @@ -179,27 +215,35 @@ The "ble-thread" pairing method can be used in order to commission the device. ### Testing the all-clusters application without Matter CLI: -1. Prepare the board with the flashed `All-cluster application` (as shown above). -2. The All-cluster example uses UART1 (`FlexComm3`) to print logs while running the server. To view raw UART output, start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings: +1. Prepare the board with the flashed `All-cluster application` (as shown + above). +2. The All-cluster example uses UART1 (`FlexComm3`) to print logs while running + the server. To view raw UART output, start a terminal emulator like PuTTY and + connect to the used COM port with the following UART settings: - - Baud rate: 115200 - - 8 data bits - - 1 stop bit - - No parity - - No flow control + - Baud rate: 115200 + - 8 data bits + - 1 stop bit + - No parity + - No flow control 3. Open a terminal connection on the board and watch the printed logs. -4. On the client side, start sending commands using the chip-tool application as it is described [here](../../../../chip-tool/README.md#using-the-client-to-send-matter-commands). +4. On the client side, start sending commands using the chip-tool application as + it is described + [here](../../../../chip-tool/README.md#using-the-client-to-send-matter-commands). + ### Testing the all-clusters application with Matter CLI enabled: The Matter CLI can be enabled with the all-clusters application. -For more information about the Matter CLI default commands, you can refer to the dedicated [ReadMe](../../../../shell/README.md). +For more information about the Matter CLI default commands, you can refer to the +dedicated [ReadMe](../../../../shell/README.md). The All-clusters application supports additional commands : + ``` > help [...] @@ -207,32 +251,44 @@ mattercommissioning Open/close the commissioning window. Usage : mattercommi matterfactoryreset Perform a factory reset on the device matterreset Reset the device ``` -- ```matterfactoryreset``` command erases the file system completely (all Matter settings are erased). -- ```matterreset``` enables the device to reboot without erasing the settings. -Here are described steps to use the all-cluster-app with the Matter CLI enabled +- `matterfactoryreset` command erases the file system completely (all Matter + settings are erased). +- `matterreset` enables the device to reboot without erasing the settings. -1. Prepare the board with the flashed `All-cluster application` (as shown above). -2. The matter CLI is accessible in UART1. For that, start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings: +Here are described steps to use the all-cluster-app with the Matter CLI enabled - - Baud rate: 115200 - - 8 data bits - - 1 stop bit - - No parity - - No flow control +1. Prepare the board with the flashed `All-cluster application` (as shown + above). +2. The matter CLI is accessible in UART1. For that, start a terminal emulator + like PuTTY and connect to the used COM port with the following UART settings: -3. The All-cluster example uses UART2 (`FlexComm0`) to print logs while running the server. To view raw UART output, a pin should be plugged to an USB to UART adapter (connector `HD2 pin 03`), then start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings: + - Baud rate: 115200 + - 8 data bits + - 1 stop bit + - No parity + - No flow control - - Baud rate: 115200 - - 8 data bits - - 1 stop bit - - No parity - - No flow control +3. The All-cluster example uses UART2 (`FlexComm0`) to print logs while running + the server. To view raw UART output, a pin should be plugged to an USB to + UART adapter (connector `HD2 pin 03`), then start a terminal emulator like + PuTTY and connect to the used COM port with the following UART settings: -4. On the client side, start sending commands using the chip-tool application as it is described [here](../../../../chip-tool/README.md#using-the-client-to-send-matter-commands). + - Baud rate: 115200 + - 8 data bits + - 1 stop bit + - No parity + - No flow control +4. On the client side, start sending commands using the chip-tool application as + it is described + [here](../../../../chip-tool/README.md#using-the-client-to-send-matter-commands). ## OTA Software Update -Over-The-Air software updates are supported with the RW61x all-clusters example. The process to follow in order to perform a software update is described in the dedicated guide ['Matter Over-The-Air Software Update with NXP RW61x example applications'](../../../../../docs/guides/nxp_rw61x_ota_software_update.md). \ No newline at end of file + +Over-The-Air software updates are supported with the RW61x all-clusters example. +The process to follow in order to perform a software update is described in the +dedicated guide +['Matter Over-The-Air Software Update with NXP RW61x example applications'](../../../../../docs/guides/nxp_rw61x_ota_software_update.md).