[K32W0] SDK 2.6.12 changes (#28489)
* k32w0: Re-use Thread task for BLE processing
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* k32w0: Use generic FreeRTOS functions
Avoid using messaging/allocation functions specific to K32W0-SDK
and use instead generic FreeRTOS functions.
This opens the path for a common BLE Manager between K32W0/K32W1.
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* k32w0: event queues: use generic FreeRTOS functions
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* k32w0: avoid useless advertising restarting
There is no need to restart advertising after a connect event.
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* [K32W0] Place BLE common code in a single file
Only specific BLE initialization code is placed under k32w0 folder.
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* [K32W0] Place specific initialization code in an abstract method
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* [K32W0] Avoid useless stop of ble advertising
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* [K32W0] Remove unused function
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* k32w0: remove useless controller code
NVIC Priority set is done inside the controller library.
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* [K32W0] Small fixes
- return codes;
- comments.
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
* [K32W0] Add LP API header
The LP API was not included in BleManagerImpl when building
in low power mode.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Clear unsupported thread metrics
Thread metrics optional fields should call ClearValue explicitly,
to make sure no garbage is returned in the response message.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Disable CHIP_DEVICE_CONFIG_BLE_SET_PHY_2M_REQ for lock/contact sensor
This define enables/disables the Gap_LeSetPhy request to switch to 2M.
It is disabled here for interoperability reasons just to be extra cautious.
Both devices may send a Link Layer control procedure in parallel resulting in a
LPM Error Transaction Collision.
If the peer device doesn't accept our reject command, this can result in a BLE
connection timeout.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] FRO 32K mode should be used with 32Mhz cpu clock
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Remove OTA API dependency in factory data provider
If factory data is used, then it is expected that the internal flash
section is written, so the factory data provider can memcpy directly,
without additional checks that were previously done in OtaUtils.
Using the OTA API for reading internal flash data just seems unnatural.
In the absence of another API, just memcpy directly assuming the section
was written.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Rename factory data flag
CONFIG_CHIP_K32W0_REAL_FACTORY_DATA renamed to CONFIG_CHIP_LOAD_REAL_FACTORY_DATA.
Also replaced format string in factory data provider logs.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Rename K32W0FactoryDataProvider to FactoryDataProvider
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Move FactoryDataProvider to K32W common area
Update #include statements to use an absolute path.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Add FactoryDataProviderImpl
FactoryDataProviderImpl has two main features:
- CHIP_DEVICE_CONFIG_USE_CUSTOM_PROVIDER - enables application factory data provider
- CONFIG_CHIP_K32W0_OTA_FACTORY_DATA_PROCESSOR - enables factory data OTA
Enclose the corresponding functions in their respective flags.
Applications should instantiate a FactoryDataProviderImpl instance,
which can be default or custom.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Add support for kSoftwareUpdateCompleted boot reason
A new K32WConfig key is introduced: kConfigKey_SoftwareUpdateCompleted
This key is stored in OTA HandleApply, before the device is reset.
Upon initialization, if the reset is caused by a system reset (ResetMCU),
then if this key exists, the boot reason is kSoftwareUpdateCompleted.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] POWER_GetResetCause() should be called once for each startup, and its return value should be processed bit by bit
* [K32W0] the priority is watchdog reset, when software reset and watchdog reset are set at the same time in POWER_GetResetCause()
* [K32W0] Remove ble connections state
Other changes:
* Set fast advertising flag when advertising is stopped
* Add device connected state
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Remove unused members
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Move global variables to class members
Add HandleForceDisconnect method.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Event queue should be emptied in DoBleProcessing
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Cancel BLE advertising timer upon connection close event
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Schedule stop advertising from Matter task
Stop advertising was wrongly scheduled from the timer service daemon task,
which has the highest priority. This caused BLE controller task to be preempted
when doing the switch from fast to slow advertising mode, which caused some events
to not be captured on time, resulting in a failed advertising stop.
Stop advertising is now scheduled to run from Matter task.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Add instructions to overwrite board configuration files
The example uses template/reference board configuration files.
To overwrite the board configuration files, set `override_is_DK6=false` in the
`k32w0_sdk` target from the app `BUILD.gn`:
```
k32w0_sdk("sdk") {
override_is_DK6 = false
...
}
```
This variable will be used by `k32w0_sdk.gni` to overwrite `chip_with_DK6` option,
thus the reference board configuration files will no longer be used.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Restructure RAM storage
RAM storage class was moved to k32w0 folder.
RamStorageKey files were removed and implementation was moved
inside RamStorage.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Add extendedSearch option
Increase number of KVS keys to 200.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Remove unused ksdk_mbedtls file
Not in the scope of the ticket.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Extended search should be taken into account when factory resetting
If extended search was enabled for a RAM storage instance, then factory reset
should remove all PDM ids used, starting with the base one.
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Update SDK version in README files
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Set rotating device id unique id length to max by default
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Use west to get K32W0 SDK
* [K32W0] Remove deprecated function pointer
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [NXP] Bump ot-nxp to latest
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* Restyled by whitespace
Restyled by clang-format
Restyled by gn
Restyled by prettier-markdown
Restyled by prettier-yaml
* [K32W0] update cPWR_UsePowerDownMode to chip_with_low_power
update cPWR_UsePowerDownMode usage to a more generic chip_with_low_power
in order to be able to be used by multiple platforms
Signed-off-by: Marius Vilvoi <marius.vilvoi@nxp.com>
* [K32W0] Remove unused flag in README files
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Remove redundant header file
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* [K32W0] Update path for building K32W041 as this missing files are only under the K32W061 board
* [K32W0] Update docker image version in examples job
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* Restyled by whitespace
Restyled by gn
Restyled by prettier-markdown
* [K32W0] Update documentation for reference apps
The user can specify a custom SDK by setting NXP_K32W0_SDK_ROOT.
If such an env variabile is not defined, then the gn env will
implicitly set it to the SDK found in the repo:
third_party/nxp/k32w0_sdk/repo/core
Signed-off-by: Marius Tache <marius.tache@nxp.com>
* Restyled by gn
* Restyled by prettier-markdown
* [K32W0] BLE processing should be done under the corresponding flag
Signed-off-by: Marius Tache <marius.tache@nxp.com>
---------
Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
Signed-off-by: Marius Tache <marius.tache@nxp.com>
Signed-off-by: Marius Vilvoi <marius.vilvoi@nxp.com>
Co-authored-by: Doru Gucea <doru-cristian.gucea@nxp.com>
Co-authored-by: tanyue518 <ethan.tan@nxp.com>
Co-authored-by: Gabriel Couturier <gabriel.couturier@nxp.com>
Co-authored-by: Restyled.io <commits@restyled.io>
Co-authored-by: Marius Vilvoi <marius.vilvoi@nxp.com>
Builds
Tests
Tools
Documentation
Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
Matter is a unified, open-source application-layer connectivity standard built to enable developers and device manufacturers to connect and build reliable, and secure ecosystems and increase compatibility among connected home devices. It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports. Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.
Matter simplifies development for manufacturers and increases compatibility for consumers.
The standard was built around a shared belief that smart home devices should be secure, reliable, and seamless to use. By building upon Internet Protocol (IP), Matter enables communication across smart home devices, mobile apps, and cloud services and defines a specific set of IP-based networking technologies for device certification.
The Matter specification details everything necessary to implement a Matter application and transport layer stack. It is intended to be used by implementers as a complete specification.
The Alliance officially opened the Matter Working Group on January 17, 2020, and the specification is available for adoption now.
Visit buildwithmatter.com to learn more and read the latest news and updates about the project.
Matter is developed with the following goals and principles in mind:
Unifying: Matter is built with and on top of market-tested, existing technologies.
Interoperable: The specification permits communication between any Matter-certified device, subject to users’ permission.
Secure: The specification leverages modern security practices and protocols.
User Control: The end user controls authorization for interaction with devices.
Federated: No single entity serves as a throttle or a single point of failure for root of trust.
Robust: The set of protocols specifies a complete lifecycle of a device — starting with the seamless out-of-box experience, through operational protocols, to device and system management specifications required for proper function in the presence of change.
Low Overhead: The protocols are practically implementable on low compute-resource devices, such as MCUs.
Pervasive: The protocols are broadly deployable and accessible, by leveraging IP and being implementable on low-capability devices.
Ecosystem-Flexible: The protocol is flexible enough to accommodate deployment in ecosystems with differing policies.
Easy to Use: The protocol provides smooth, cohesive, integrated provisioning and out-of-box experience.
Open: The Project’s design and technical processes are open and transparent to the general public, including non-members wherever possible.
Matter aims to build a universal IPv6-based communication protocol for smart home devices. The protocol defines the application layer that will be deployed on devices and the different link layers to help maintain interoperability. The following diagram illustrates the normal operational mode of the stack: 
The architecture is divided into layers to help separate the different responsibilities and introduce a good level of encapsulation among the various pieces of the protocol stack. The vast majority of interactions flow through the stack captured in the following Figure:
Security: An encoded action frame is then sent down to the Security Layer to encrypt and sign the payload to ensure that data is secured and authenticated by both sender and receiver of a packet.
Message Framing & Routing: With an interaction encrypted and signed, the Message Layer constructs the payload format with required and optional header fields; which specify the message's properties and some routing information.
Matter’s design and technical processes are intended to be open and transparent to the general public, including to Working Group non-members wherever possible. The availability of this GitHub repository and its source code under an Apache v2 license is an important and demonstrable step to achieving this commitment. Matter endeavors to bring together the best aspects of market-tested technologies and redeploy them as a unified and cohesive whole-system solution. The overall goal of this approach is to bring the benefits of Matter to consumers and manufacturers as quickly as possible. As a result, what you observe in this repository is an implementation-first approach to the technical specification, vetting integrations in practice. The Matter repository is growing and evolving to implement the overall architecture. The repository currently contains the security foundations, message framing and dispatch, and an implementation of the interaction model and data model. The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.
We welcome your contributions to Matter. Read our contribution guidelines here.
Instructions about how to build Matter can be found here .
The Matter repository is structured as follows:
| File/Folder | Content |
|---|---|
| build | Build system support content and built output directories |
| build_overrides | Build system parameter customization for different platforms |
| config | Project configurations |
| credentials | Development and test credentials |
| docs | Documentation, including guides. Visit the Matter SDK documentation page to read it. |
| examples | Example firmware applications that demonstrate use of Matter |
| integrations | 3rd Party integrations |
| scripts | Scripts needed to work with the Matter repository |
| src | Implementation of Matter |
| third_party | 3rd party code used by Matter |
| zzz_generated | zap generated template code - Revolving around cluster information |
| BUILD.gn | Build file for the gn build system |
| CODE_OF_CONDUCT.md | Code of conduct for Matter and contribution to it |
| CONTRIBUTING.md | Guidelines for contributing to Matter |
| LICENSE | Matter license file |
| REVIEWERS.md | PR reviewers |
| gn_build.sh | Build script for specific projects such as Android, EFR32, etc. |
| README.md | This File |
Matter is released under the Apache 2.0 license.