In 802.11 standards, the connection procedure includes three major steps that shall be performed to make the device part of the Wi-Fi network and communicate in the network. Those three steps are device discovery (scanning), device authentication (checking compatibility-capability etc. before connection) and then finally establishment of connection (Association). Going forward, this post provides details for each step. The message exchange in connection procedure is shown below.   Figure 1. Connection Process in open system   Figure 2. Messages exchange in Connection Process   Figure 2 shows Wi-Fi sniffer log for messages exchange procedure between Client and AP device at the time of connection, here Client device is Xiaomi and AP is Marvell device.   Connection Setup Process 1. Scanning To join any network first client or station needs to find it the network. In the wired network, just plugging the cable or jack will find the network. In the wireless world, this requires identification of the compatible network before joining process can begin. This identification process of the network is referred as scanning. Several parameters are needed in the scanning process. These parameters are BSSType, BSSID, channel list, scantype, MinChannelTime and MaxChannelTime. The parameters are set as default depending upon manufacturer Wi-Fi driver, but it can be modified by the user i.e. if the requirement is for hidden network then we can set scantype parameter as passive scan because the active scan is not useful for the hidden network (networks that do not broadcast their SSID). There are two scanning methods, passive scanning and active scanning. By default, radios perform both the types of scanning on all the channels allowed by the country of operation.  While both the types of scanning are available by default, active scanning is performed only by those channels that are allowed to transmit by regional government regulations. Channels that are not authorized for unlicensed use are excluded from active scanning. Passive scan: In Passive Scanning, WLAN station moves to each channel as per the channel list and waits for beacon frames. Beacon frames are used by the access points (and stations in an IBSS) to communicate or to announce themselves. The access point tries to send the beacon at defined interval that is called Target Beacon Transmission Time (TBTT) Nevertheless, access points are just like the any wireless device in the cell. They cannot send if the network is busy. When the time comes for an AP to send a beacon & the network is busy, the AP will delay its beacon transmission until it can gain access to the media. In 802.11, network is busy or not can be checked using CSMA/CA protocol. In CSMA/CA when a frame is ready, the transmitting device checks whether the channel is idle or busy to avoid the collision. If the channel is busy the transmitting device will wait for random duration and check again whether the channel is idle or not. If channel is idle it will send the frame. The Beacon frame structure is as shown below.   Figure 3. Beacon Frame   Description of mandatory field of a Beacon Frame. Timestamp: After receiving the beacon frame, all the stations update their local clocks with this timestamp. This helps with synchronization. Beacon Interval: Represents the number of Time Units (TUs) between Target Beacon Transmission Times (TBTT). Default value is 100TU (102.4 milliseconds). Capability information: It contains information about capability of the device/network SSID: It contains Service set ID of the network. Supported rates: This field contains information of supported data rates by the access point. Notice that this information is not only used by potential clients during passive scanning but also by clients that are already associated to the BSS. A passive scan generally takes more time, since the client must listen and wait for a beacon versus actively probing to find an AP. Another limitation with a passive scan is that if the client does not wait long enough on a channel, then the client may miss an AP beacon.   Active scan: Discovering the network by scanning all possible channels and listening to beacons is not considered to be very efficient. To enhance this discovery process, stations often use what is called active scanning. In the active scanning mode, stations still go through each channel in turn, but instead of passively listening to the signals from AP, stations send a probe request management frame aimed at asking what network is available on this channel. If any AP or active station in an IBSS is presenting that frequency, they should answer with the probe response frame.   Figure 4. Scanning Methods   Once the probe request is sent by the emitting station, it starts a Probe Timer countdown and waits for answers. This Probe Timer value is usually a lot shorter than a beacon interval. Common values are in the 10-millisecond range. At the end of the timer, the station processes the answers it has received. If no answer was received, the station moves to the next channel (on different frequency) and repeats the same discovery process. The purpose of a probe request is typically to discover APs and their supported networks (SSIDs and/or BSSIDs).   Figure 5. Probe Request/Response Frame   This frame contains mainly two fields, the SSID and the rates supported by the mobile station. Stations that receive Probe Request use the information to determine whether the requesting station can join the network. The Probe Response frame fields are very similar to Beacon frame fields that enable mobile stations to match parameters and join the network.   2. Authentication After having performed a network discovery through the probe request/probe response exchange or by listening to beacons, a station wanting to join a network goes through an authentication process, exchanging authentication frames with the access point. On reception of the authentication frame, AP sends acknowledgement and then Authentication Response. The initial purpose of the ‘authentication’ frames to validate the device type, in other words, verify that the requesting station has proper 802.11 capabilities to join the network. Open system authentication: Information related to capabilities are exchanged between station and AP using Authentication Request. If request is accepted, AP sends “success” in Authentication Response. Shared key authentication: IEEE 802.11-1997 standard included a WEP shared key exchange authentication mechanism Called “Shared Key”. This shared key exchange adds two more frames to the default Open System authentication, resulting in a four-frame exchange. This latter method is called Shared Key authentication, requires the use of WEP encryption, and is not widely used (and not recommended) today. First phase of authentication is described above but when WPA or WPA2 is used then second phase of authentication (i.e. 4-way handshaking process) takes place after the device gets associated. The details regarding Open System authentication and Shared-Key authentication is available in 802.11 security post <Link TBD>.   Figure 6. Authentication frame   As shown above, the Authentication Frame consist of the following fields. Authentication Algorithm Number: 0 for Open System & 1 for Shared Key. Authentication Transaction Sequence Number: Indicate current state of progress. Status Code: 0 for Success & 1for Unspecified failures. Challenge Text: Used in Shared Key Authentication frame.   3. Association If the 802.11 authentication phase completes with a Success result, the station moves to the Association phase. The purpose of this exchange is for the station to join the network and obtain an Association ID [AID]. Association request: The first frame sent in the association phase is from the requesting station to the AP (or a station in an IBSS). This frame is the association request frame and the response of this frame is association response frame. Association request is unicast management frame and is always acknowledged.   Figure 7. Association Request   Association response: Once the Association request is acknowledged, the AP examine each field of the request & verify they all match its own 802.11 parameters (refer Figure 6). In case of parameter mismatch, AP checks whether the difference is a blocking or not and based on that AP sends authentication response. -    If the parameter difference is blocking, then response with status code 1 will be sent (to reject the association). -    In case of non-blocking difference/No difference in the parameters, response with status code 0(success) and AP’s own parameters will be sent to the requesting station. Station must be compatible with the AP’s capability otherwise it will drop the association process and start looking for another AP.   Figure 8. Association Response   Connection Teardown Disassociation: Once a station is associated to an AP, either side can terminate the association at any time by sending a disassociation frame. A station can send Disassociation frame before leaving the current network to roam/join another AP. An AP can send this frame in multiple cases like, if the station tries to use invalid parameters, AP itself under configuration change, hackers attack, etc. The disassociation frame (DA) can be the unicast MAC address of the station to disassociate or a broadcast address if the AP needs to disassociate all the stations in its network. In case of unicast frame, the frame will get acknowledge by receiving station and the broadcast frames are not acknowledged.   Figure 9. Disassociation Frame The Disassociation frame is quite small. It contains only one field “Reason code”. A disassociated station is still authenticated. It can try to re-associate by sending a new Association request frame, keeping its authenticated status. A station roaming to another cell may also choose to use a disassociation frame, to be able to keep its authenticated status and accelerate the process when roaming back to the same cell before its authentication timeout expires.   Figure 10. Disassociation Frame Exchange   This frame is also used when parameters change and the station or the AP needs to renegotiate the communications parameters.   De-authentication: The station or AP can also send a de-authentication frame. This frame is used when all communications are terminated, for example, because the AP has to reboot or because the station stops its Wi-Fi communications. It is also used when a frame is received before authentication has completed. For example, a station trying to send an association request or a data frame before having performed the authentication sequence then station will receive a Deauthentication frame from the AP, indicating that authentication must be performed first. The frame format is same as disassociation frame.   Figure 11. Deauthentication Frame Exchange   Roaming Roaming, in the context of an 802.11 wireless network, is the process of a client moving an established Wi-Fi network association from one access point to another access point within the same Extended Service Set (ESS) without losing connection (e.g. within a defined time interval, usually in the range of a few seconds). The roaming time should be smaller for the better performance. In the roaming process, the mobile device will send the disassociation frame to the previously associated Access Point (AP), and will start re-association process by exchanging 802.11 frames with another access point to which the device wants to connect. The client device scans the another AP then exchange authentication frames after that it will send re-association request, here instead of association re-association request is used and the first 2 steps of connection process remains the same.   Figure 12. Message Exchange in Roaming Process     Figure 13. Roaming representation   Wi-Fi APIs used in Connection and Disconnection process Table below shows some of the available APIs in NXP i.MX RT SDK for connection and disconnection process.   Table 1. APIs Available in SDK API Description Can be called from wifi_send_scan_cmd Used for scanning the available network. It supports only single SSID based scan. We can extend this to a list of multiple SSIDs. Station and AP wlan_add_network Add specific network profile to the list of known networks. Station and AP wlan_remove_network Remove specific network profile from the list of known networks. Station and AP wlan_connect Connect with specific network (AP). Station wlan_disconnect Disconnect the station from network (AP). Station wlan_start_network Start specific network. AP wlan_stop_network Stop specific network. AP   For more details on such APIs refer the document “MCUXpresso_SDK_WLAN_Driver_Reference_Manual.pdf” available at location <SDK Documentation>/docs/wifi.

This document is a supplement for USB MSC device bootloader revision for FRDM-KL25Z (IAR) written by Kai Liu and describes the bootloader support for FRDM-K64F. FTFE support, board specific and MCU specific code was added to the initial software. This porting work was done for connectivity purposes but it can be used as support for FRDM-K64F board. Please refer to USB-KW24D512  MSD Bootloader to find out how to use this bootloader, binary files upload and other restrictions. The bootloader has conditional jump to user application. The condition is the state of the SW2 button (PTC6). If the button is pressed (PTC6 grounded) during reset, the bootloader sequence will start, installing BOOTLOADER drive. Else if the button is released during reset, the SP and PC will be updated from address 0xC000. This means, the user application has to be designed so as to have 0xC000 application start address. If a valid SP and PC value is found at address 0xC000, the user application is launched. The bootloader application is located in the flash memory of the MK64FN1M0VLL12 microcontroller, from address 0x0000 to 0xBFFF, so the user application should not access this memory region. The bootloader software was tested under Microsoft Windows 10, Microsoft Windows 8, Microsoft Windows 7 and Ubuntu 14.04 operating systems. Attached files: USB_MSD_Bootloader.bin – boolader binary file for FRDM-K64; Pflash_1024KB_0xC000.icf – IAR linker file for user application development; Demos.7z - user application demo S record files for FRDM-K64F (got from Kinetis SDK demo list).

The “BeyondStudio for NXP” Integrated Development Environment (IDE) provides a platform for the development of wireless network applications to be run on NXP’s JN516x family of wireless microcontrollers. For more details and installation guide.  JN-UG-3098 (BeyondStudio for NXP Installation and User Guide). This document explains the common issues that the user will face when trying to develop a new application using BeyondStudio IDE.   First of all, be sure that you are working with the latest SDK version and application note.    Import Problems After you import some application note that you want to take as reference. 2.2 Importing a Project. BeyondStudio for NXP Installation and User Guide.     1. Wrong Path A  common issue is a user uses another path for the installation of the SDK than the default one (C:\nxp\bstudio_nxp\workspace). When trying to find the Makefile ("SDK/JN-SW-4168/Stack/Common/Build/config.mk"), the IDE uses a relative path, for that reason it assumes that the file is in the correct directory. As the path was changed, the file can’t be found.   2.Project Directory After you select the Application Note (AN) you want to import remember that there will be an option for the JN517x as most of the projects are compatible between them (Zigbee 3.0, ZigBee Link Light). Nonetheless, BeyondStudio is not compatible with the JN517x.  While importing the project you only must select the JN516x project and none of the options must not be selected.     Linking Errors Open a source file (.c) or a header file (.h),  you will notice that the IDE shows a lot of errors even though the project has not been compiled yet. The errors you are seeing is Eclipse not being able to resolve various variables and functions within the SDK. You might see some errors like: Symbol “xxx” could not be resolved for example. After starting the compilation process, look at the console log and notice that the bin file is being generated correctly. Do not try to add another file in the path and Symbols trying to avoid all those errors; the IDE will look for the includes that the project needs. If you used the default path location, it will not have any problem with the compilation. The OS_Gen, ZPS_Gen, and PDUM_Gen, for example, are all files automatically generated based on the configuration files, performing a clean will remove those files but will be created again after a new compilation. File app.zpscfg Problems Encountered The next error will appear if the Zigbee Plug-in is not installed. Follow the installation procedure for the plug-ins 1.2.3 Installing the ZigBee Plug-ins BeyondStudio for NXP Installation and User Guide. Look at the installation folder that is included in the SDK. C:\NXP\bstudio_nxp\sdk\JN-SW-41xx\Tools\Eclipse_plugins\com.nxp.sdk.update_site For a better reference the ZPS Configuration Editor provides a convenient way to set ZigBee network parameters ZigBee PRO Stack User Guide I hope it helps. Regards, Mario

Certification is the process of testing radio hardware to demonstrate that it meets the stated regulations in the country that it will operate in. A certification is needed generally when electronic hardware will be sold in a country, the certification requirements of that country must be met. If you require changes in your certificated hardware that will affects your RF performance, then you need to re-certificate the device. Most common regions and certification's institutes are (it applies for 2.4GHz & SubGHz): FCC for USA IC for Canada ETSI (CE) for Europe ARIB for Japan Other countries generally follow FCC or ETSI standars. The institute in charge of certifications depends on the region. It's the same institute to certificate your device in 2.4GHz or SubGHz in a certain region, the only difference are the articles of each institute to operate in the different frequencies. For operating in the 2.4GHZ band (worldwide): - In the U.S, CFR 47 FCC Part 15 203, 15.209 and 15.247 - In Canada, IC RSS-210 which closely follows FCC Part 15 - In EU, ETSI EN 300, 301 - In Japan, ARIB STD-T66 For SubGHz depends on the frequency you want to operate in. Taking Japan as an example: In Japan you can operate in the 920MHz band or in the 400MHz band for SubGHz. For both frequencies, ARIB is the institute in charge of the certifications but to operate in the 400MHz band the article that you will need is the ARIB STD-T67, and to operate in the 920MHz you will need to certificate your hardware with ARIB STD-T108 article. Freescale's MRB-KW019032 is certificated to operate in the following SubGHz ISM bands: The firmware used to certificate our KW products is the Radio Utility or the Connectivity Test, it allows the user in changing some RF parameters needed to pass the certification process. If you are thinking in certificate a product, contact an expert! There are Telecommunication Certification Body (TCB) companies which can give you guidance in the processes you need to follow to achieve a certification. To know more about FCC certification requirements and processes, refer to the reference manual “Freescale IEEE 802.15.4 / ZigBee Node RF Evaluation and Test Guidelines” in the Freescale's website. Best regards, Burgos. This document was generated from the following discussion: Certifications

Sniffing is the process of capturing any information from the surrounding environment. In this process, addressing or any other information is ignored, and no interpretation is given to the received data. Freescale provides both means and hardware to create devices capable of performing this kind of operation. For example, a KW01 board can be easily turned into a Sub-GHz sniffer using Test Tool 12.2.0 which can be found at https://www.freescale.com/webapp/sps/download/license.jsp?colCode=TESTTOOL_SETUP&appType=file2&location=null&DOWNLOAD_ID=null After downloading and installing Test Tool 12.2.0 there are several easy steps to create your own sniffer for Sub-GHz bands. 1) How to download the sniffer image file onto KW01.      a) Connect KW01 to PC using the mini-usb cable      b) Connect the J-Link to the PC      c) Open Test Tool 12.2 and go to the Firmware Loaders tab      d) Select Kinetis Firmware Loader. A new tab will pop-up.      e) J-Link will appear under the J-Link devices tab.      f) Select the KW01Z128_Sniffer.srec file and press the upload button.     g) From the Development Board Option menu select KW01Z128.      h) Follow the on-screen instruction and unplug the board. Then plug it back in.      i) Close the Kinetis Firmware Loader tab and open the Protocol Analyzer Tab 2) How to use the Protocol Analyzer feature. Basics.     a) The Protocol Analyzer should automatically detect the KW01 sniffer. If not, close the tab, unplug the board, plug it back and re-open the tab. If this doesn’t work, try restarting Test Tool.     b) To start “sniffing” the desired channel, click the arrow down button from Devices: KW01 (COMx) Off and select the desired mode and channel.     c) The tab will change to ON meaning that KW01 will "sniff" on the specified channel. To select another channel, click the tab again and it will switch back to Off. Then select a new channel.      d) Regarding other configurations, please note that you can specify what decoding will be applied to the received data. Additional information: The sniffer image found in Test Tool is compiled for the 920-928MHz frequency band. Because of this, the present document will have attached to it two sniffer images, for the 863-870MHz and the 902-928MHz frequency bands. To upload a custom image perform the steps described at the beginning of this document, but instead of selecting a *.srec file from the list in Kinetis Firmware Loader click the Browse button and locate the file on disk. After selecting it, redo the steps for uploading an image file. A potential outcome: sometimes, if you load a different frequency band sniffer image, the Protocol Analyzer will display the previously used frequency band. To fix this, close Test Tool, re-open it and go to the Protocol Analyzer tab again. The new frequency band should be displayed. More information on this topic can be found in Test Tool User Guide (..\Freescale\Test Tool 12\Documentation\TTUG.pdf), under Chapter 5 (Protocol Analyzer, page 87).

The FRDM-KW36 comes with the OpenSDA circuit which allows users to program and debug the evaluation board. There are different solutions to support such OpenSDA circuits: 1. The J-Link (SEGGER) firmware.  2. The CMSIS-DAP (mbed) firmware. The FRDM-KW36 comes pre-programmed with the CMSIS-DAP firmware. However, if you want to update the firmware version, you need to perform the next steps.  Press and hold the Reset button (SW1 push button in the board).  Unplug and plug the FRDM-KW36 again to the PC.  The board will be enumerated as "DAPLINKBOOT" device. Drag and drop the binary file to update the OpenSDA firmware.  If the J-Link version is programmed, the board will be enumerated as "FRDM-KW36J". On the other hand, if the CMSIS-DAP version is programmed, the board will be enumerated as "FRDM-KW36". The binary for the J-link version can be downloaded from the next link: SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace  The binary for the CMSIS-DAP version can be found in the next link: OpenSDA Serial and Debug Adapter|NXP    Hope this helps... 

This guide explains how to configure Wi-Fi as Access Point using the i.MX8M Plus EVK (8MP) as the AP device and the i.MX8M Mini EVK (8MM) as the connected device.

802.15.4 wireless sniffers like the USB-KW41Z are capable of capturing over-the-air traffic. The captured packets are passed to a network protocol decoder like Wireshark over a network interface tunnel built by the Kinetis Protocol Analyzer.   Hardware  One USB-KW41Z preloaded with sniffer firmware ( instructions found at www.nxp.com/usb-kw41z )  Software Download & Install Thread Wireshark from wireshark.org which is an open-source network protocol analyzer capable of debugging over the air communication between Thread devices. Kinetis Protocol Analyzer is a software that provides a bridge between the USB-KW41 and Wireshark.  Wireshark Configuration  Open Wireshark from the Program Files Click Edit and select Preferences  Click Protocols to expand a list of protocols Select IEEE 802.15.4, click the Decryption Keys Edit... button Create a new key entry by pressing the plus button, then set the following values and click OK       Decryption key = 00112233445566778899aabbccddeeff      Decryption key index = 1      Key hash = Thread hash Find CoAP and configure it with CoAP UDP port number = 5683 Click Thread and select Decode CoAP for Thread  with Thread sequence counter = 00000000 as shown below At the 6LoWPAN preferences, add the Context 0 value of fd00:0db8::/64 Click OK and close Wireshark Configure Kinetis Protocol Analyzer  Connect the USB-KW41Z to one of the USB ports on your computer Open the device manager and look for the device connected port Open the "Kinetis Protocol Analyzer Adapter" program Make sure, you have a USB-KW41Z connected to your PC when opening the program because the Kinetis Protocol Adapter will start looking for kinetis sniffer hardware. Once the USB-KW41Z is detected, the previously identify COM port will be displayed Select the desired IEEE 802.15.4 channel to scan in the Kinetis Protocol Analyzer window. This guide selects channel 12 as an example  Click on the Wireshark icon to open Wireshark Network Protocol Analyzer An error may appear while opening Wireshark, click OK and continue Wireshark Sniffing Wireshark Network Analyzer will be opened. On the "Capture" option of the main window, select the Local Area Connection that was created by the Kinetis Protocol Analyzer, in this example, Kinetis Protocol Analyzer created "Local Area Connection 2", then click "Start" button. USB-KW41Z will start to sniff and upcoming data will be displayed in the "Capture" window of the Wireshark Network Protocol Analyzer.

This project is for Kinets L MCU Brazil challenge.Actually we don´t know if the project was registered. The goal of this project is to make Bluetooth communication between an android and  Freescale Freedom development kit FRDM-KL25Z. We will show the FRDM-KL25Z accelerometer status and the internal temperature sensor on android app. The android app requires version 4.x or above. Bluetooth module is connected to UART1.The embeddec code was created on CodeWarrior and exported to Keil MDK ARM.   http://youtu.be/-waEkfIuZCw

This document describes how to add additional cluster to the router application in the AN12061-MKW41Z-AN-Zigbee-3-0-Base-Device Application Note.   The Router application's main endpoint contains Basic, Groups, Identify and OnOff server. The steps below describe how to add two clusters to Router: Temperature Measurement server and OnOff client. Note that these changes only go as far as making the new clusters added and discoverable, no functionality has been added to these clusters. Router/app_zcl_cfg.h The first step is to update the application ZCL Configuration file to add the new clusters (OnOff Client, Temperature Measurement Server) to the Router application endpoint. The HA profile already contains few clusters but Temperature Measurement cluster was added:   /* Profile 'HA' */ #define HA_ILLUMINANCEMEASUREMENT_CLUSTER_ID (0x0400) #define HA_DEFAULT_CLUSTER_ID                (0xffff) #define HA_OTA_CLUSTER_ID                    (0x0019) #define HA_TEMPMEASUREMENT_CLUSTER_ID        (0x0402) Router/app_zcl_globals.c The OnOff client was already present in Router endpoint but made discoverable and the Temperature Measurement cluster was added and made discoverable into Router application endpoint.The clusters are added to the Input cluster list (Server side) and output cluster list (Client side) and made discoverable using DiscFlag only for the cluster list for which it is enabled. So, assuming you need to add OnOff cluster client, you would need to use add the cluster id (0x0006 for OnOff) into input cluster list (Server side of cluster) and output cluster list (Client side of the cluster) and make it discoverable for output cluster list as it is a client cluster. For temperature measurement, you need to make it discoverable for input Cluster list as below: PRIVATE const uint16 s_au16Endpoint1InputClusterList[6] = { 0x0000, 0x0004, 0x0003, 0x0006, HA_TEMPMEASUREMENT_CLUSTER_ID , 0xffff, }; PRIVATE const PDUM_thAPdu s_ahEndpoint1InputClusterAPdus[6] = { apduZCL, apduZCL, apduZCL, apduZCL, apduZCL, apduZCL, }; PRIVATE uint8 s_au8Endpoint1InputClusterDiscFlags[1] = { 0x1f }; PRIVATE const uint16 s_au16Endpoint1OutputClusterList[5] = { 0x0000, 0x0004, 0x0003, 0x0006, HA_TEMPMEASUREMENT_CLUSTER_ID, }; PRIVATE uint8 s_au8Endpoint1OutputClusterDiscFlags[1] = { 0x08 }; Now update Simple Descriptor structure (see the declaration of zps_tsAplAfSimpleDescCont and ZPS_tsAplAfSimpleDescriptor structures to understand how to correctly fill the various parameters) to reflect the input cluster and output cluster list correctly as below : PUBLIC zps_tsAplAfSimpleDescCont s_asSimpleDescConts[2] = { {    {       0x0000,       0,       0,       0,       84,       84,       s_au16Endpoint0InputClusterList,       s_au16Endpoint0OutputClusterList,       s_au8Endpoint0InputClusterDiscFlags,       s_au8Endpoint0OutputClusterDiscFlags,    },    s_ahEndpoint0InputClusterAPdus,    1 }, {    {       0x0104,       0,       1,       1,       6,       5,       s_au16Endpoint1InputClusterList,       s_au16Endpoint1OutputClusterList,       s_au8Endpoint1InputClusterDiscFlags,       s_au8Endpoint1OutputClusterDiscFlags,    },    s_ahEndpoint1InputClusterAPdus,    1 }, }; Router/zcl_options.h This file is used to set the options used by the ZCL. Enable Clusters The cluster functionality for the router endpoint was enabled: /****************************************************************************/ /*                             Enable Cluster                               */ /*                                                                          */ /* Add the following #define's to your zcl_options.h file to enable         */ /* cluster and their client or server instances                             */ /****************************************************************************/ #define CLD_BASIC #define BASIC_SERVER #define CLD_IDENTIFY #define IDENTIFY_SERVER #define CLD_GROUPS #define GROUPS_SERVER #define CLD_ONOFF #define ONOFF_SERVER #define ONOFF_CLIENT #define CLD_TEMPERATURE_MEASUREMENT #define TEMPERATURE_MEASUREMENT_SERVER Enable any optional Attributes and Commands for the clusters /****************************************************************************/ /* Temperature Measurement Cluster - Optional Attributes */ /* */ /* Add the following #define's to your zcl_options.h file to add optional */ /* attributes to the time cluster. */ /****************************************************************************/ #define CLD_TEMPMEAS_ATTR_TOLERANCE /****************************************************************************/ /* Basic Cluster - Optional Commands */ /* */ /* Add the following #define's to your zcl_options.h file to add optional */ /* commands to the basic cluster. */ /****************************************************************************/ #define CLD_BAS_CMD_RESET_TO_FACTORY_DEFAULTS /****************************************************************************/ /* OnOff Cluster - Optional Commands */ /* */ /* Add the following #define's to your zcl_options.h file to add optional */ /* commands to the OnOff cluster. */ /****************************************************************************/ #define CLD_ONOFF_CMD_OFF_WITH_EFFECT  Add the cluster creation and initialization into ZigBee Base device definitions The cluster functionality for some of the clusters (like OnOff Client) is already present on ZigBee Base Device. For Temperature Measurement cluster the functionality was added into ZigBee Base Device. <SDK>/middleware/wireless/Zigbee_3_0_6.0.6/core/ZCL/Devices/ZHA/Generic/Include/base_device.h The first step was including the Temperature Measurement header files into base device header file as shown below:  #ifdef CLD_TEMPERATURE_MEASUREMENT #include "TemperatureMeasurement.h" #endif The second step was adding cluster instance (tsZHA_BaseDeviceClusterInstances) into base device Instance as shown below: /* Temperature Measurement Instance */ #if (defined CLD_TEMPERATURE_MEASUREMENT) && (defined TEMPERATURE_MEASUREMENT_SERVER) tsZCL_ClusterInstance sTemperatureMeasurementServer; #endif The next step was to define the cluster into the base device structure (tsZHA_BaseDevice) as below: #if (defined CLD_TEMPERATURE_MEASUREMENT) && (defined TEMPERATURE_MEASUREMENT_SERVER) tsCLD_TemperatureMeasurement sTemperatureMeasurementServerCluster; #endif <SDK>/middleware/wireless/Zigbee_3_0_6.0.6/core/ZCL/Devices/ZHA/Generic/Include/base_device.c The cluster create function for Temperature Measurement cluster for server was called in ZigBee base device registration function:   #if (defined CLD_TEMPERATURE_MEASUREMENT) && (defined TEMPERATURE_MEASUREMENT_SERVER)    /* Create an instance of a Temperature Measurement cluster as a server */    if(eCLD_TemperatureMeasurementCreateTemperatureMeasurement(&psDeviceInfo->sClusterInstance.sTemperatureMeasurementServer,                                                    TRUE,                                                    &sCLD_TemperatureMeasurement,                                                    &psDeviceInfo->sTemperatureMeasurementServerCluster,                                                    &au8TemperatureMeasurementAttributeControlBits[0]) != E_ZCL_SUCCESS)   {       return E_ZCL_FAIL;    } #endif Router/app_zcl_task.c Temperature Measurement Server Cluster Data Initialization - APP_vZCL_DeviceSpecific_Init() The default attribute values for the Temperature Measurement clusters are initialized: PRIVATE void APP_vZCL_DeviceSpecific_Init(void) {    sBaseDevice.sOnOffServerCluster.bOnOff = FALSE;    FLib_MemCpy(sBaseDevice.sBasicServerCluster.au8ManufacturerName, "NXP", CLD_BAS_MANUF_NAME_SIZE);    FLib_MemCpy(sBaseDevice.sBasicServerCluster.au8ModelIdentifier, "BDB-Router", CLD_BAS_MODEL_ID_SIZE);    FLib_MemCpy(sBaseDevice.sBasicServerCluster.au8DateCode, "20150212", CLD_BAS_DATE_SIZE);    FLib_MemCpy(sBaseDevice.sBasicServerCluster.au8SWBuildID, "1000-0001", CLD_BAS_SW_BUILD_SIZE);    sBaseDevice.sTemperatureMeasurementServerCluster.i16MeasuredValue = 0;    sBaseDevice.sTemperatureMeasurementServerCluster.i16MinMeasuredValue = 0;    sBaseDevice.sTemperatureMeasurementServerCluster.i16MaxMeasuredValue = 0; }

Overview The Bluetooth specification defines 4 Generic Access Profile (GAP) roles for devices operating over a Low Energy physical transport [1]: Peripheral Central Broadcaster Observer The Bluetooth Low Energy Host Stack implementation on the Kinetis KW40Z offers devices the possibility to change between any of the 4 roles at run time. This article will present the interaction with the Bluetooth Low Energy Host API needed to implement a GAP multiple role device. General Procedure instructions Running the GAP roles requires the application to go through the following 3 steps: Configuration - Stack configuration for the desired GAP role The application needs to configure the stack parameters, e.g. advertising parameters, advertising data, scan parameters, callbacks. Note that configuration of the advertising parameters or scanning response and advertising data can be done only once if the values don’t change at runtime. The configuration is always made in the Link Layer Standby state. Start - Running the role The application needs to start advertising, scanning or initiate connection. Stop - Return to Standby state When changing between roles, the Link layer must always go through the Link Layer Standby state. Running as a GAP Broadcaster or GAP Peripheral The GAP Broadcaster or Peripheral sends advertising events. Additionally, the GAP Peripheral will accept the establishment of a LE link. This is why the GAP Observer will only support the Non Connectable Advertising mode (gAdvNonConnectable_c). Both roles requires configuration of advertising data, advertising parameters. The configuration (gAppAdvertisingData, gAppScanRspData and gAdvParams) usually resides in app_config.c. The confirmation events for setting these parameters is received in BleApp_GenericCallback. The confirmation event for the changing state of advertising is received in BleApp_AdvertisingCallback. Configuration /* Setup Advertising and scanning data */ Gap_SetAdvertisingData(&gAppAdvertisingData, &gAppScanRspData); /* Setting only for GAP Broadcaster role */ gAdvParams. advertisingType = gAdvNonConnectable_c; /* Set advertising parameters*/ Gap_SetAdvertisingParameters(&gAdvParams); Start App_StartAdvertising(BleApp_AdvertisingCallback, BleApp_ConnectionCallback); Stop Gap_StopAdvertising(); Running as a GAP Observer The GAP Observer receives advertising events. Unlike the GAP Peripheral or Broadcaster, it does not need to set scanning parameters separately. It passes the configuration with the start procedure. The configuration (gAppScanParams) usually resides in app_config.c. The confirmation event for the changing state of scanning is received in BleApp_ScanningCallback. Configuration and Start App_StartScanning(&gAppScanParams, BleApp_ScanningCallback); Stop Gap_StopScanning (); Running as a GAP Central The GAP Central initiates the establishment of the LE link. Like the GAP Observer, it passes the configuration with the start procedure. The configuration (gConnReqParams) usually resides in app_config.c. The confirmation event for the changing state of link is received in BleApp_ConnectionCallback. Configuration and Start Gap_Connect(&gConnReqParams, BleApp_ConnectionCallback); Stop Gap_Disconnect(deviceId); Example An out-of-the box example for multiple role is attached. The application named blood_pressure_multi_role implements a Blood Pressure GATT client and server and can switch between the following GAP roles: Peripheral, Observer and Central. The contents of the archive needs to be copied to the following location: <Installer Path>\KW40Z_Connectivity_Software_1.0.1\ConnSw\examples\bluetooth\ The application can be found at: <Install Path specified>\KW40Z_Connectivity_Software_1.0.1\ConnSw\examples\bluetooth\blood_pressure_multi_role\frdmkw40z\bare_metal\build\iar\blood_pressure_multi_role.eww Running as GAP Peripheral Press SW4. LED1 will start flashing and the console will show that the Link Layer enters Advertising. If the Link Layer was in a previous state, it will go through Standby. static void BleApp_Advertise(void) {     /* Ensure Link Layer is in Standby */     BleApp_GoToStandby();         shell_write(" GAP Role: Peripheral\n\r");     mGapRole = gGapPeripheral_c;         /* Start GAP Peripheral */     App_StartAdvertising(BleApp_AdvertisingCallback, BleApp_ConnectionCallback); } Running as GAP Observer Press SW3. A chasing LED pattern will start and the console will show that the Link Layer enters Scanning. If the Link Layer was in a previous state, it will go through Standby. static void BleApp_Scan(void) {     /* Ensure Link Layer is in Standby */     BleApp_GoToStandby();         shell_write(" GAP Role: Observer\n\r");     mGapRole = gGapObserver_c;         /* Start GAP Observer */     App_StartScanning(&gAppScanParams, BleApp_ScanningCallback); } Running as GAP Central If the Link Layer is in scanning and finds a Blood Pressure Sensor, it will go through Standby and initiate connection. static void BleApp_Connect(void) {     /* Ensure Link Layer is in Standby */     BleApp_GoToStandby();         shell_write(" GAP Role: Central\n\r");     mGapRole = gGapCentral_c;         /* Start GAP Central */     Gap_Connect(&gConnReqParams, BleApp_ConnectionCallback); } Returning to Standby Pressing SW3 for more than 2 seconds, brings the Link Layer back in Standby. static void BleApp_GoToStandby(void) {     /* Check if connection is on */     if (mPeerInformation.deviceId != gInvalidDeviceId_c)     {         /* Stop GAP Central or Peripheral */         Gap_Disconnect(mPeerInformation.deviceId);     }     if (mAdvOn)     {         /* Stop GAP Peripheral or Bradcaster */         Gap_StopAdvertising();     }         if (mScanningOn)     {         /* Stop GAP Observer */         Gap_StopScanning();     } } References [1] BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C], 2.2 PROFILE ROLES

Different 802.11 standards are used in Wi-Fi and they differ in terms of operating frequency and data rates. This post provides information about the different terms used in Wi-Fi, 802.11 standards and the three types of 802.11 MAC frames.   Wi-Fi Standard basic terms Station (STA): Stations comprise of all devices that are connected to the wireless LAN. Station is any device that contains 802.11-compliant MAC and PHY interface to the wireless medium. A station may be a laptop, desktop PC, Access Point (AP) or smartphone. A station may be fixed, mobile or portable. Access Point (AP): An access point is a device that creates a wireless local area network. It has station functionality and provides access to the distribution services via the wireless medium. An access point is a device that allows Wi-Fi clients and Wi-Fi enabled routers to connect to a wired network. Access point connects to a wired router, switch or hub via an Ethernet cable and projects Wi-Fi signal to the defined area. An access point receives data by wired Ethernet, and converts to a 2.4GHz or 5GHz wireless signal. It communicates with nearby wireless clients. In a Wi-Fi network, wireless client communicate to other wireless clients via the AP. Client: A device that connects to a Wi-Fi (wireless) network. Any device that transmits and receives Wi-Fi signals, such as a laptop, printer, smartphone is a Wi-Fi client. Basic Service Set (BSS): A group of stations that are successfully synchronized for 802.11 communications. BSS contains one AP and one or more client stations. In BSS, stations have layer 2 connection with AP and are known as associated. Basic Service Set Identifier (BSSID): All basic service sets can be identified by a 48-bit (6-octet) MAC address known as the Basic Service Set Identifier (BSSID). The BSSID address is the layer 2 identifier of each individual basic service set. Most often the BSSID address is the MAC address of the access point. Distribution System (DS): A system that interconnects a set of basic service sets and integrated Local Area Networks (LANs) to create an Extended Service Set (ESS). It is used to extend wireless network coverage. Extended Service Set (ESS): In extended service set, one or more basic service sets are connected. An extended service set is a collection of multiple access points and their associated clients. Independent Basic Service Set (IBSS): An IBSS consists only of client stations that do peer-to-peer communications. An IBSS is a self-contained network that does not have an access point. SSID/ESSID: The logical network name of an Extended Service Set (ESS) is often called a Service Set Identifier (SSID). This name allows stations to connect to the desired network when multiple independent networks operate in the same physical area. Roaming: It is a process of a client moving from one access point to another access point within the same Extended Service Set (ESS) without losing connection. It is described in detail in 802.11 connection disconnection process post: [802.11] Wi-Fi Connection/Disconnection process .   Below figure shows DS, AP, Station, BSS, SSID, BSSID and ESS. Figure 1. Overview of Distribution system   802.11 Standards / Wi-Fi Generations 802.11 standard defines an over the air communication interface between the wireless base station and clients. The 802.11 family has various specifications and it has been categorized in several versions as shown in table below. Details of Wi-Fi generations with 802.11 specifications   Table 1. Wi-Fi Generation Overview Generation Technology Operating Frequency Data rates - 802.11b 2.4 GHz 1 - 11 Mbps - 802.11a 5 GHz Up to 54 Mbps - 802.11g 2.4 GHz Up to 54 Mbps Wi-Fi 4 802.11n 2.4 and 5 GHz Up to 600 Mbps Wi-Fi 5 802.11ac 2.4 and 5 GHz Up to 3.5 Gbps Wi-Fi 6 802.11ax 2.4 and 5 GHz Up to 9.6 Gbps   802.11b: This technology is focused on achieving higher data rates within the 2.4GHz ISM band and that is achieved by using a different spreading/coding technique called Complementary Code Keying (CCK) and modulation methods using the phase properties of the RF signal. 802.11b devices support data rates of 1, 2, 5.5 and 11 Mbps. 802.11a: This technology uses 5GHz frequency band. It supports data rate up to 54Mbps with the use of a spread spectrum technology called Orthogonal Frequency Division Multiplexing (OFDM). 802.11a can coexist in the same physical space with 802.11b and 802.11g devices as these devices are using different frequency ranges (5GHz and 2.4GHz respectively). 802.11g: This Technology is an enhancement of 802.11b Physical layer to achieve the greater bandwidth yet remain compatible with 802.11 MAC. The technology that was originally defined by the 802.11g amendment is called Extended Rate Physical (ERP), So the term ERP can be used in the place of 802.11g. Data rate differs with different 802.11g PHY technology, there are two mandatory ERP PHYs and two optional ERP PHYs. The First mandatory PHY technology called Extended Rate Physical-OFDM (ERP-OFDM) is used to achieve data rate up to 54Mbps. Second mandatory PHY technology called Extended Rate Physical DSSS (ERP-DSSS/CCK) is used to maintain backward compatibility and achieve data rate up to 11Mbps. ERP-PBCC and DSSS-OFDM are the two optional PHYs. ERP-PBCC PHY offers same data rates as the ERP-DSSS/CCK physical layer. It is used to provide higher performance in the range (the 5.5 and 11 Mbps rates) by using DSSS technology with Packet Binary Convolution Code (PBCC) scheme. DSSS-OFDM PHY is a hybrid combination of DSSS and OFDM. The transmission of packet physical header is done by DSSS, whereas the transmission of packet payload is performed by OFDM. Usage of this physical layer is to cover interoperability aspects. 802.11n: This Technology is an improvement of the 802.11 standard to get the higher throughput. 802.11n has a new operation known as High Throughput (HT) which provides MAC and PHY enhancements to provide data rates up to 600Mbps. 802.11n supports Multiple-Input Multiple-Output (MIMO) technology in unison with OFDM technology. MIMO uses multiple radios and transmitting and receiving antennas called radio chains. It capitalizes on the effects of multipath as opposed to compensating for or eliminating them. Transmit Beamforming can be used in MIMO system to steer beams & provide greater range & throughput. 802.11ac: Wi-Fi certified 802.11ac devices are dual band, operating in both 2.4 GHz and 5 GHz. 802.11ac is built on the foundation of 802.11n. 802.11ac devices use the 5 GHz band, while 802.11n products use the 2.4 GHz frequency band, so 802.11b and 802.11g compatibility can be achieved with 802.11ac. 802.11ac provides high-performance through Multi-User Multiple Input Multiple Output (multi-user MIMO), wider channels, and support for four spatial streams. 802.11ax: Wi-Fi certified 802.11ax provides improved data rates, power efficiency and support for eight spatial streams. Target Wake Time (TWT) feature helps to improve battery performance.   802.11 Frame types 802.11 frames are used for wireless communication and is much more involved because the wireless medium requires several management features and corresponding frame types that are not found in wired networks. There are three major frame types that are discussed below. For details regarding 802.11 layer architecture, please refer to [802.x.x] IEEE 802.x.x and Wi-Fi basics.   Management Frames Management frames are used by wireless stations to join and leave the basic service set. 802.11 management frame is also called Management MAC Protocol Data Unit (MMPDU). It has a MAC header, a frame body, and a trailer. It doesn’t carry any upper layer information. There is no MAC Service Data Unit (MSDU) encapsulated in the MMPDU frame body, it carries only layer 2 information fields and information elements, it does not carry higher layer (Layer 3 to 7 of OSI model) data. A management frame must have fixed length information fields and it may have information elements that are variable in length. Management/MMPDU frame body content depends on the sub type field, based on the sub type field it has payload like Status/Reason code, device capability information etc. Few of the management frames i.e. Beacon, Authentication, Association are described in the Connection setup process post [802.11] Wi-Fi Connection/Disconnection process. Below figure shows management frame structure.   Figure 2. Management Frame structure   Type field available in frame control field, that is set to 00 for the management frame. Management frames have 24-bytes long MAC header and header contains three addresses. DA field is the destination address of the frame, it can be broadcast or unicast depending upon frame subtype. SA field is MAC address of the station transmitting the frame. BSSID is MAC address of AP. Frame body is variable size. Size and content of the body depend on the management frame subtype.   Figure 3. Management Frame   Table 2. Management Frame description Frame SubType SubType Value [B7 B6 B5 B4] Initiator (AP/Station) Association request 0 Station Association response 1 AP Reassociation request 10 Station Reassociation response 11 AP Probe request 100 Station Probe response 101 AP/Station Beacon 1000 AP Announcement Traffic Indication Message (ATIM) 1001 Station (IBSS) Disassociation 1010 AP Authentication 1011 Station Deauthentication 1100 AP/Station Action 1101 AP/Station Action no ack 1110 AP/Station   Control Frames Control frames are associated with the delivery of data and management frames, it does not have a frame body. Control frames contain PHY, preamble, layer 2 header and trailer. Control frames can be transmitted at different data rates as they perform many different functions. All control frames use the same Frame Control field that is shown in the figure below.   Figure 4. Control Frame structure   Figure 5. Control Frame   The type field value for the control frame is 01 and subtype fields identify the function of a frame. Table below shows the different types of control frames.   Table 3. Control Frame description Subtype description Subtype value [B7 B6 B5 B4] Reserved 0000 - 0110 Control wrapper 0111 Block ack request (BlockAckReq) 1000 Block ack (BlockAck) 1001 PS-Poll 1010 RTS 1011 CTS 1100 ACK 1101 CF-End 1110 CF-End and CF-Ack 1111   Data Frames Data frames carry the higher level protocol data in the frame body. Data frames are categorized according to function. Total 15 sub types of data frames are defined in 802.11 standard. Type field value for the data frames is 10. One such distinction is between frame that carries data and frame that does not carry data (perform management function). Figure below shows data frame structure.   Figure 6. Data Frame structure   Figure 7. Data Frame   Each bit of the SubType field available in the frame control field has specific meaning as below. Bit 4 (B4): Changing it from 0 to 1 indicates the data subtype includes +CF-Ack. Bit 5 (B5): Changing it from 0 to 1 indicates the data sub type include +CF-Poll. Bit 6 (B6): Changing it from 0 to 1 indicates that the frame contains no data, specifically, that it contains no Frame Body field. Bit 7 (B7): Changing it from 0 to 1 indicates Quality of Service (QoS) data frame.   Data frames that appear only in the contention-free period can never be used in an IBSS. Below is the list of data frames.   Table 4.Data Frame Details Frame SubType SubType Value B7 B6 B5 B4 Consists Data Contention Free Service Data (simple data frame) 0 Yes No Data + CF-Ack 1 Yes Yes Data + CF-Poll 10 Yes Yes(AP only) Data + CF-Ack + CF-Poll 11 Yes Yes(AP only) Null 100 No It can be contention based and free both CF-Ack 101 No Yes CF-Poll 110 No Yes(AP only) CF-Ack + CF-Poll 111 No Yes(AP only) QoS Data 1000 Yes No QoS Data + CF-Ack 1001 Yes Yes QoS Data + CF-Poll 1010 Yes Yes(AP only) QoS Data + CF-Ack + CF-Poll 1011 Yes Yes(AP only) Qos Null 1100 No It can be contention based and free both QoS CF-Poll 1110 No Yes(AP only) QoS CF-Ack + CF-Poll 1111 No Yes(AP only)   References 802.11 Specification: https://ieeexplore.ieee.org/document/7786995 Certified Wireless Analysis Professional: https://www.oreilly.com/library/view/cwap-certified-wireless/9781118075234/ Community posts [802.x.x] IEEE 802.x.x and Wi-Fi basics   [802.11] Wi-Fi Connection/Disconnection process

The Thread Low Power End Device is preconfigured to have both the MCU in low power state and the radio turned off most of the time to preserve battery life. The device wakes up periodically and polls its parent router for data addressed to it or optionally initiates sending data to the network by means of the parent router. The low-power module (LPM) from the connectivity framework simplifies the process of putting a Kinetis-based wireless network node into the low-power or sleep modes. For the MKW41Z there are six low-power modes available. By default, the Thread Low Power End Device uses Deep sleep mode 3, where: MCU in LLS3 mode. Link layers remain idle. RAM is retained. The wake-up sources are: GPIO (push buttons). DCDC power switch (In buck mode). LPTMR with the 32kHz oscillator as clock source. The LPTMR timer is also used to measure the time that the MCU spends in deep sleep to synchronize low-power timers at wake-up. See the Connectivity Framework Reference Manual and PWR_Configuration.h for more information about the sleep deep modes. To change the polling time on deep sleep mode 3, we need to understand two macros:    1. The cPWR_DeepSleepDurationMs macro in \framework\LowPower\Interface\MKW41Z\PWR_Configuration.h. #ifndef cPWR_DeepSleepDurationMs   #define cPWR_DeepSleepDurationMs                3000 #endif ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This macro determines how long the MCU will go to low power mode (deep sleep). The maximum value is 65535000 ms (18.2 h). 2. The THR_SED_POLLING_INTERVAL_MS macro in \source\config.h. /*! The default value for sleepy end device (SED) polling interval */ #ifndef THR_SED_POLLING_INTERVAL_MS     #define THR_SED_POLLING_INTERVAL_MS                     3000     /* Milliseconds */ #endif ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This macro determines how often the Low Power End Device will send a poll message to its parent. NOTE: This value does not determine how often the MCU wakes up. The polling interval should be a multiple of the Deep sleep duration value, otherwise the poll will be sent at the next deep sleep time out. As an example, let's say we configure the polling interval to 4000ms and the deep sleep duration to 3000ms. The MCU will wake up every 3000ms but the poll message will be sent every 2 deep sleep timeouts = 6000ms because the timers are synchronized when the MCU wakes up. The following figure shows the behavior of this example. It is recommended that the polling interval is the same as the deep sleep duration, so the MCU doesn't wake up unnecessarily. The following figure shows this behavior. Another macro to keep in mind is THR_SED_TIMEOUT_PERIOD_SEC in app_thread_config.h. #ifndef THR_SED_TIMEOUT_PERIOD_SEC     #define THR_SED_TIMEOUT_PERIOD_SEC                 ((4*THR_SED_POLLING_INTERVAL_MS)/1000 + 3) #endif ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This value is the timeout period used by the parent to consider a sleepy end device (SED) disconnected. By default, this value is configured to be 4 times the polling interval + 3s. It is recommended to leave this macro as it is. This value is sent to the parent node during the commissioning.

In developing a Zigbee application, certain static configuration is required before the application is built. Configuring the network size, adding a new cluster, making the device discoverable and adding a new endpoint can be done by changing parameters in the following files: app_zps_cfg.h app_zcl_cfg.h app_zcl_global.c These files are responsible for setting up network parameters like device type and associated parameters, mainly related to the APS and NWK layers of the ZigBee PRO stack. Network Configuration The ZigBee device can be configured to be a coordinator, router and end device. The following section details the way in which the user can configure each device type. The app_zps_cfg header file lets the user configure the ZPS ZDO parameters of the node. The following macros are necessary for the corresponding device types: For coordinator in a ZigBee network #define ZPS_COORDINATOR #define ZPS_ZDO_DEVICE_TYPE                              ZPS_ZDO_DEVICE_COORD For router in a ZigBee network #define ZPS_ROUTER #define ZPS_ZDO_DEVICE_TYPE                              ZPS_ZDO_DEVICE_ROUTER For enddevice in a ZigBee network #define ZPS_ENDDEVICE #define ZPS_ZDO_DEVICE_TYPE                              ZPS_ZDO_DEVICE_ENDDEVICE Other ZPS ZDO configurations which are defined using macro are explained in comments inside the header file (app_zps_cfg.h). These macros provide the user with the ability to configure the device according to their network needs. The type of security for the ZigBee network can also be configured by the macro ZPS_ZDO_NWK_KEY_STATE. The user can change the security type to no network security (ZPS_ZDO_NO_NETWORK_KEY), pre-configured link key security (ZPS_ZDO_PRECONFIGURED_LINK_KEY), distributed link key security (ZPS_ZDO_DISTRIBUTED_LINK_KEY) or pre-configured installation code security (ZPS_ZDO_PRCONFIGURED_INSTALLATION_CODE). /* Specify No network Security */ #define ZPS_ZDO_NWK_KEY_STATE                               ZPS_ZDO_NO_NETWORK_KEY The application allows through this header file to configure ZPS APS AIB parameters, like extended PANID (ZPS_APS_AIB_INIT_USE_EXTENDED_PANID) or channel mask (ZPS_APS_AIB_INIT_CHANNEL_MASK). /* NWK EXTENDED PANID (EPID) that the device will use.*/ #define ZPS_APS_AIB_INIT_USE_EXTENDED_PANID                 0x0000000000000000ULL /*! CHANNEL MASK : Define all channels from 11 to 26*/ #define ZPS_APS_AIB_INIT_CHANNEL_MASK                       0x07fff800UL User can also configure the simple descriptor table size (AF_SIMPLE_DESCRIPTOR_TABLE_SIZE) as part of the ZPS AF Layer configuration parameters.The value depends on number of endpoints defined in application, one endpoint is always reserved for ZDO . So, for a device with one endpoint, the value would be 2 (1 ZDO + 1 application endpoint) #define AF_SIMPLE_DESCRIPTOR_TABLE_SIZE                     2 Among other ZPS network configuration parameters that can be changed by the user are scan duration (ZPS_SCAN_DURATION), default permit joining time (ZPS_DEFAULT_PERMIT_JOINING_TIME) and the maximum number of simultaneous key requests (ZPS_MAX_NUM_SIMULTANEOUS_REQUEST_KEY_REQS). Also, NIB values can be changed, like for example, the maximum number of routers in the network (ZPS_NWK_NIB_INIT_MAX_ROUTERS), the maximum number of children for a node (ZPS_NWK_NIB_INIT_MAX_CHILDREN), the maximum network depth (ZPS_NWK_NIB_INIT_MAX_DEPTH) or the network security level (ZPS_NWK_NIB_INIT_SECURITY_LEVEL). Different ZigBee network table sizes can be adjusted by the user from this header file. The important tables are mentioned below: The active neighbor table size (ZPS_NEIGHBOUR_TABLE_SIZE). The neighbor discovery table size, used to keep a list of the neighboring devices associated with the node (ZPS_NEIGHBOUR_DISCOVERY_TABLE_SIZE). The network address map table size, which represents the size of the address map that maps 64-bit IEEE addresses to 16-bit network (short) addresses (ZPS_ADDRESS_MAP_TABLE_SIZE). The network security material set size (ZPS_SECURITY_MATERIAL_SETS). The broadcast transaction table size, which stores the records of the broadcast messages received by the node (ZPS_BROADCAST_TRANSACTION_TABLE_SIZE). The route record table size (ZPS_ROUTE_RECORD_TABLE_SIZE) for the table that records each route, storing the destination network address, a count of the number of relay nodes to reach the destination and a list of the network addresses of the relay nodes. The route discovery table size (ZPS_ROUTE_DISCOVERY_TABLE_SIZE), used by the node to store temporary information used during route discovery. The MAC address table size (ZPS_MAC_ADDRESS_TABLE_SIZE). The binding table size (ZPS_BINDING_TABLE_SIZE). The group table size (ZPS_GROUP_TABLE_SIZE). The number of supported network keys, known also as the security material sets (ZPS_KEY_TABLE_SIZE). The child table size (ZPS_CHILD_TABLE_SIZE), that gives the size of the persisted sub-table of the active neighbor table. The stored entries are for the node’s parent and immediate children. The trust center device table size (ZPS_TRUST_CENTER_DEVICE_TABLE_SIZE). ZCL Configuration The app_zcl_cfg header file is used by the application to configure the ZigBee Cluster library. This file contains the definition for the application profile and cluster ids. The default application profiles are ZDP, HA, ZLO, GP. The ZDP (ZigBee Device Profile) id is identified by the following line: #define ZDP_PROFILE_ID             (0x0000) ZDP provides services for the following categories as cluster Ids: Device discovery services (for example, ZDP_DISCOVERY_CACHE_REQ_CLUSTER_ID) Service discovery services (for example, ZDP_IEEE_ADDR_REQ_CLUSTER_ID) Binding services (for example, ZDP_BIND_RSP_CLUSTER_ID) Management services (for example, ZDP_MGMT_NWK_DISC_REQ_CLUSTER_ID) The HA (Home Automation) profile id is identified by the following line: #define HA_PROFILE_ID             (0x0104) HA provides services for the following categories as cluster Ids: Generic devices (for example, HA_BASIC_CLUSTER_ID) Lighting devices (for example, HA_LEVELCONTROL_CLUSTER_ID) Intruder Alarm System (IAS) devices (for example, HA_IASZONE_CLUSTER_ID) The ZLO (ZigBee Lighting and Occupancy) profile is not an application profile but devices in this collection use the same application profile id as for the Home Automation application profile. This ensures backward compatibility with applications for devices based on the Home Automation 1.2 profile. ZigBee Green Power (GP) is an optional cluster with the aim of minimizing the power demands on a network node in order to support: Nodes that are completely self-powered through energy harvesting Battery-powered nodes that require ultra-long battery life The GP profile id is identified by the following line: #define GP_PROFILE_ID               (0xa1e0) The Zigbee GP cluster ID is defined as following: #define GP_GREENPOWER_CLUSTER_ID    (0x0021) Depending on the application, the app_zcl_cfg header file also contains the defines for the node endpoints. For example, the occupancy_sensor application contains the following endpoints: /* Node 'Coordinator' */ /* Endpoints */ #define COORDINATOR_ZDO_ENDPOINT    (0) #define COORDINATOR_COORD_ENDPOINT    (1) /* Node 'OccupancySensor' */ /* Endpoints */ #define OCCUPANCYSENSOR_ZDO_ENDPOINT    (0) #define OCCUPANCYSENSOR_SENSOR_ENDPOINT    (1)   /* Node 'LightSensor' */ /* Endpoints */ #define LIGHTSENSOR_ZDO_ENDPOINT    (0) #define LIGHTSENSOR_SENSOR_ENDPOINT    (1)   /* Node 'LightTemperatureOccupancySensor' */ /* Endpoints */ #define LIGHTTEMPERATUREOCCUPANCYSENSOR_ZDO_ENDPOINT    (0) #define LIGHTTEMPERATUREOCCUPANCYSENSOR_SENSOR_ENDPOINT    (1) The source file app_zcl_globals.c is used to declare the cluster lists for each endpoint. These act as simple descriptors for the node. Each endpoint has two cluster lists, containing uint16_t data. One is for input and one for output. The sizes of these two lists must be equal. For example, for endpoint 0, the declared lists will be the following: PRIVATE const uint16 s_au16Endpoint0InputClusterList[16]  =  { 0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006 , 0x0007, \                                                               0x0008, 0x0010, 0x0011, 0x0012, 0x0012, 0x0013, 0x0014 , 0x0015}; PRIVATE const uint16 s_au16Endpoint0OutputClusterList[16] = { 0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006 , 0x0007, \                                                              0x0008, 0x0010, 0x0011, 0x0012, 0x0012, 0x0013, 0x0014 , 0x0015}; The input list must also have a corresponding cluster APDU list, matching in size. For the endpoint 0 example, this will look like: PRIVATE const PDUM_thAPdu s_ahEndpoint0InputClusterAPdus[16] = { apduZDP, apduZDP, apduZDP, apduZDP, apduZDP, apduZDP, apduZDP, apduZDP,\                                                                  apduZDP, apduZDP, apduZDP, apduZDP, apduZDP, apduZDP, apduZDP, apduZDP}; Each output and input cluster list has a corresponding cluster discovery enabled flags list. As each bit inside the Cluster Disc Flag corresponds to cluster , for 16 clusters declared in Input and Output cluster list, one needs 2 bytes for Discoverable flag. In this example, the declaration is the following: PRIVATE uint8 s_au8Endpoint0InputClusterDiscFlags[2] = {0x1F, 0x08}; PRIVATE uint8 s_au8Endpoint0OutputClusterDiscFlags[2] = {0x08, 0x1B}; These parameters are registered in the node’s endpoints simple descriptor structure. The declared variable for the structure is s_asSimpleDescConts and its size depends on the number of endpoints available on the node. For example, for two endpoints, the declaration will be as below: PUBLIC zps_tsAplAfSimpleDescCont s_asSimpleDescConts[2] = {     {         {             0x0000,             0,             0,             0,             84,             84,             s_au16Endpoint0InputClusterList,             s_au16Endpoint0OutputClusterList,             s_au8Endpoint0InputClusterDiscFlags,             s_au8Endpoint0OutputClusterDiscFlags,         },         s_ahEndpoint0InputClusterAPdus,         1     },     {         {             0x0104,             0,             0,             1,             6,             4,             s_au16Endpoint1InputClusterList,             s_au16Endpoint1OutputClusterList,             s_au8Endpoint1InputClusterDiscFlags,             s_au8Endpoint1OutputClusterDiscFlags,         },         s_ahEndpoint1InputClusterAPdus,         1     }, }; The AF Context definition is as below: typedef struct _zps_tsAplAfSimpleDescCont {     ZPS_tsAplAfSimpleDescriptor sSimpleDesc;     const PDUM_thAPdu *phAPduInClusters;     bool_t bEnabled; } zps_tsAplAfSimpleDescCont; And the endpoint simple descriptor has the following structure definition: typedef struct {     uint16 u16ApplicationProfileId;     uint16 u16DeviceId;     uint8  u8DeviceVersion;     uint8  u8Endpoint;     uint8  u8InClusterCount;     uint8  u8OutClusterCount;     const uint16 *pu16InClusterList;     const uint16 *pu16OutClusterList;     uint8 *au8InDiscoveryEnabledFlags;     uint8 *au8OutDiscoveryEnabledFlags; } ZPS_tsAplAfSimpleDescriptor;

With the release of the Bluetooth LE core erratum 10734, two new Host test cases (SM/SLA/KDU/BI-01-C and SM/MAS/KDU/BI-01-C) were added to the Test Case Reference List (TCRL) and are active since 24-Jan-19. This has an impact on new product qualifications based on Component (Tested) QDIDs that used an older TCRL when the test cases for this erratum were not required. Products that rely on NXP HOST QDIDs have 2 options for covering the erratum 10734 in order to complete the qualification: NXP provides a new qualification/QDID that includes these 2 tests. This is scheduled for later this year for QN908x, KW35/36 and KW41/31 products. NXP provides the test evidence/logs for these 2 tests and the test house reviews them before completing the product qualification. Right now, option 2 can be followed using the test evidence/logs provided by NXP. Later in the year, option 1 can be followed with an updated QDID. To obtain the test evidence/logs, please submit a support request.

Introduction This post guides you on migrating from MKW36Z512VHT4 to MKW36A512VFT4 MCUs. This example will make use of the "beacon" SDK example. SDK Download and Install 1- Go to MCUXpresso web page: MCUXpresso Web Page 2- Log in with your registered account. 3- Search for the "KW36A" device. Then click on the suggested processor and click on "Build MCUXpresso SDK"       4- The next page will be displayed. Select “All toolchains” in the “Toolchain / IDE” box and provide a name to identify the package. Then click on "Download SDK".     5- Accept the license agreement. Wait a few minutes until the system gets the package into your profile. Download the SDK clicking on "Download SDK Archive" as depicted in the following figure.     6- If MCUXpresso IDE is used, drag and drop the KW36A SDK zip folder in “Installed SDK’s” perspective to install the package.     At this point, you have downloaded and installed the SDK package for the KW36A device.   Software Migration in MCUXpresso IDE 1- Import the "beacon" example on the MCUXpresso workspace. Click on “Import SDK examples(s)…” option, a new window will appear. Then select "MKW36Z512xxx4" and click on the FRDM-KW36 image. Click on the "Next >" button.     2- Search beacon and select your project version (bm or freertos).     3- Go to Project/Properties. Expand C/C++ Build/MCU settings and select MKW36A512xxx4 MCU. Click Apply and Close button to save the configuration.     4- Rename MKW36Z folders as MKW36A, clicking the right mouse button and selecting "Rename". These are the following:   framework/DCDC/Interface -> MKW36Z framework/DCDC/Source -> MKW36Z framework/LowPower/Interface -> MKW36Z framework/LowPower/Source -> MKW36Z framework/XCVR -> MKW36Z4     5- Open the Project/Properties window in MCUXpresso IDE. Go to C/C++ Build/Settings and select MCU C Compiler/Includes folder in the Tool Settings window. Edit all paths related to MKW36 MCU, in according to MKW35 folders before created. The results must look similar as shown below:   ../framework/LowPower/Interface/MKW36A ../framework/LowPower/Source/MKW36A ../framework/DCDC/Interface/MKW36A ../framework/XCVR/MKW36A4     6- Select MCU Assembler/General folder in Tool Settings. Edit the paths related to MKW36 MCU. The results must look similar as shown below:   ../framework/LowPower/Interface/MKW36A ../framework/LowPower/Source/MKW36A ../framework/DCDC/Interface/MKW36A ../framework/XCVR/MKW36A4     7- Go to Project/Properties. Expand MCU C Compiler/Preprocessor window. Edit "CPU_MKW36Z512VHT4" and "CPU_MKW36Z512VHT4_cm0plus" symbols, rename it as "CPU_MKW36A512VFT4" and "CPU_MKW36A512VFT4_cm0plus" respectively. Save the changes.     8- Go to the workspace. Delete “fsl_device_registers, MKW36Z4, MKW36Z4_features, system_MKW36Z4.h and system_MKW36Z4.c” files located at CMSIS folder. Then, unzip the MKW35Z SDK package and search for “fsl_device_registers, MKW36A4, MKW36A4_features, system_MKW36A4.h and system_MKW36A4.c” files into this folder at the following paths:   <SDK_folder_root>/devices/MKW36A4/fsl_device_registers.h <SDK_folder_root>/devices/MKW36A4/MKW36A4.h <SDK_folder_root>/devices/MKW36A4/MKW36A4_features.h <SDK_folder_root>/devices/MKW36A4/system_MKW36A4.h <SDK_folder_root>/devices/MKW36A4/system_MKW36A4.c     9- Overwirte the “startup_mkw36z4.c” (located inthe startup folder) by the "startup_mkw36a4.c" located in the following path <SDK_folder_root>/devices/MKW36A4/mcuxpresso/startup_mkw36a4.c. You can simply drag and drop on the startup folder, and remove the older one.     10- Open "fsl_device_registers.h" file in CMSIS folder. Add"defined(CPU_MKW36A512VFT4)" in the following code (line 18 of the file):   /* * Include the cpu specific register header files. * * The CPU macro should be declared in the project or makefile. */ #if (defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VFT4) || defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36A512VFT4))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   11- Open "ble_config.h" file in bluetooth->host->config folder. Add "defined(CPU_MKW36A512VFT4)" in the following code (line 146 of the file):   /* The maximum number of BLE connection supported by platform */ #if defined(CPU_QN9080C) #define MAX_PLATFORM_SUPPORTED_CONNECTIONS 16 #elif (defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36A512VFT4) || \ defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW35A512VFP4) || \ defined(CPU_K32W032S1M2CAx_cm0plus) || defined(CPU_K32W032S1M2VPJ_cm0plus) || \ defined(CPU_K32W032S1M2CAx_cm4) || defined(CPU_K32W032S1M2VPJ_cm4) || \ defined(CPU_MKW38A512VFT4) || defined (CPU_MKW38Z512VFT4) || defined(CPU_MKW39A512VFT4) || \ defined(CPU_MKW37A512VFT4) || defined(CPU_MKW37Z512VFT4))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   12- Open "ble_controller_task.c" file in source->common folder. Add "defined(CPU_MKW36A512VFT4)" in the following code (line 272 of the file):    #elif (defined(CPU_MKW35A512VFP4) || defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VFT4) ||\ defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4)) /* Select BLE protocol on RADIO0_IRQ */ XCVR_MISC->XCVR_CTRL = (uint32_t)((XCVR_MISC->XCVR_CTRL & (uint32_t)~(uint32_t)( XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_MASK )) | (uint32_t)( (0UL << XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_SHIFT) ));‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   13-Build the project.   At this point, the project is already migrated.   Software Migration in IAR Embedded Workbench IDE 1- Open the beacon project located in the following path: 2- Select the project in the workspace and press Alt + F7 to open project options.   3- In the General Options/Target window click the icon next to the device name and select the appropriate device NXP/KinetisKW/KW3x/NXP MKW36A512xxx4, then click the OK button.   4- Create a new folder with the name MKW36A at following paths: <SDK_root>/middleware/wireless/framework_5.4.6/DCDC/Interface <SDK_root>/middleware/wireless/framework_5.4.6/DCDC/Source <SDK_root>/middleware/wireless/framework_5.4.6/LowPower/Interface <SDK_root>/middleware/wireless/framework_5.4.6/LowPower/Source <SDK_root>/middleware/wireless/framework_5.4.6/XCVR     5- Copy all files inside MKW36Z folders located at the above paths and paste in MKW36A folders.     6- Select the beacon project in the workspace and press Alt+F7 to open project options window. In C/C++ Compiler/Preprocessor window, rename the paths related to MKW36Z folders to MKW36A folders. Rename the CPU_MKW36Z512VHT4 macro as CPU_MKW36A512VFT4 in the defined symbols text box. The results must look similar as shown below: Click the OK button. $PROJ_DIR$/middleware/wireless/framework_5.4.2/LowPower/Interface/MKW36A $PROJ_DIR$/../../../../../../../devices/MKW36A4/drivers $PROJ_DIR$/../../../../../../../middleware/wireless/framework_5.4.2/DCDC/Interface/MKW36A $PROJ_DIR$/../../../../../../../middleware/wireless/framework_5.4.2/XCVR/MKW36A4 $PROJ_DIR$/../../../../../../../devices/MKW36A4 $PROJ_DIR$/../../../../../../../devices/MKW36A4/utilities     7- Expand the startup folder, select all files, click the right mouse button and select the “Remove” option. Click the right mouse button on the folder and select “Add/Add files”. Add the startup_MKW36A4.s located at this path: <SDK_root>/devices/MKW36A4/iar/startup_MKW36A4.s Also, add system_MKW36A4.c and system_MKW36A4.h into the startup folder. Both files are located at the next path: <SDK_root>/devices/MKW36A4   8- Open "ble_config.h" file in bluetooth->host->config folder. Add "defined(CPU_MKW36A512VFT4)" in the following code: /* The maximum number of BLE connection supported by platform */ #if defined(CPU_QN9080C) #define MAX_PLATFORM_SUPPORTED_CONNECTIONS 16 #elif (defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36A512VFT4) || \ defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW35A512VFP4) || \ defined(CPU_K32W032S1M2CAx_cm0plus) || defined(CPU_K32W032S1M2VPJ_cm0plus) || \ defined(CPU_K32W032S1M2CAx_cm4) || defined(CPU_K32W032S1M2VPJ_cm4) || \ defined(CPU_MKW38A512VFT4) || defined (CPU_MKW38Z512VFT4) || defined(CPU_MKW39A512VFT4) || \ defined(CPU_MKW37A512VFT4) || defined(CPU_MKW37Z512VFT4))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   9- Open "ble_controller_task.c" file in source->common folder. Add "defined(CPU_MKW36A512VFT4)" in the following code: #elif (defined(CPU_MKW35A512VFP4) || defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VFT4) ||\ defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4)) /* Select BLE protocol on RADIO0_IRQ */ XCVR_MISC->XCVR_CTRL = (uint32_t)((XCVR_MISC->XCVR_CTRL & (uint32_t)~(uint32_t)( XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_MASK )) | (uint32_t)( (0UL << XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_SHIFT) ));‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   10-Build the project.   At this point, the project is already migrated.

This application note describes the usage of the DC-DC Switching Mode Power Supply (SMPS) converter for the MKW39A/38A/37A/38Z/37Z families. This document covers operating voltages, types of circuit operation, hardware design guidelines, software configuration, and power capabilities. It's a complementary document from the AN5025. The DC-DC converter for MKW3x is a dual output converter that supports two operating modes: Bypass and Buck. In Bypass mode, the DC-DC converter is disabled and the supply pins of the microcontroller must be supplied externally. In Buck mode, the DC-DC converter is enabled and requires a DC supply in the range of 1.8 V to 4.2 V (during startup the minimum required is 2.1 V).

Introduction The FRDM-KW36 includes an RTC module with a 32 kHz crystal oscillator. This module generates a 32 kHz clock source for the MCU whilst running on very low power mode. This oscillator includes a set of programmable capacitors used as the C LOAD . Changing the value of these capacitors can modify the frequency the oscillator provides. This configurable capacitance ranges from 0 pF (capacitor bank disabled) to 30 pF in steps of 2 pF. These values are obtained by combining the enabled capacitors. The values available are 2 pF, 4 pF, 8 pF, and 16 pF. Any combination of these four can be done. It is recommended that these internal capacitors are disabled if the external capacitors are available (clearing SC2P, SC4P, SCS8, and SC16 bits in RTC Control Register SFR). To adjust the frequency provided by the oscillator, you must first be able to measure the frequency. Using a frequency counter would be ideal, as it provides a more precise measurement than an oscilloscope. You will also need to output the oscillator frequency. To output the oscillator frequency, using any of the Bluetooth demo applications as an example, you should do the following: Adjusting Frequency Example This example will make use of the Heart Rate Sensor demo (freertos version) from the Connectivity Software Stack and assumes that the developer has the knowledge of import or open projects from the SDK to IDE. Open or clone the Heart Rate Sensor project from your SDK. Find the board.c and board.h files in the board folder at the workspace.                                                                                Declare a void function on the board.h file as shown below. This function will be in order to mux the RTC clock out to the PTB3 and be able to measure the frequency.  /* Function to mux PTB3 to RTC_CLKOUT */ void BOARD_EnableRtcClkOut (void);‍‍ Develop the BOARD_EnableRtcClkOut function inside the board.c file as below. void BOARD_EnableRtcClkOut(void) { /* Enable PORTB clock gating */ CLOCK_EnableClock(kCLOCK_PortB); /* Mux the RTC_CLKOUT to PTB3 */ PORT_SetPinMux(PORTB, 3u, kPORT_MuxAlt7); /* Select the 32kHz reference for RTC_CLKOUT signal */ SIM->SOPT1 |= SIM_SOPT1_OSC32KOUT(1); } Call the BOARD_EnableRtcClkOut function in hardware_init function just after BOARD_BootClockRUN (board.c file). Find clock_config.c file in the board folder at the workspace. Add the following defines at the top of the file. #define RTC_OSC_CAP_LOAD_0 0x0U /*!< RTC oscillator, capacitance 0pF */ #define RTC_OSC_CAP_LOAD_2 0x2000U /*!< RTC oscillator, capacitance 2pF */ #define RTC_OSC_CAP_LOAD_4 0x1000U /*!< RTC oscillator, capacitance 4pF */ #define RTC_OSC_CAP_LOAD_6 0x3000U /*!< RTC oscillator, capacitance 6pF */ #define RTC_OSC_CAP_LOAD_8 0x800U /*!< RTC oscillator, capacitance 8pF */ #define RTC_OSC_CAP_LOAD_10 0x2800U /*!< RTC oscillator, capacitance 10pF */ #define RTC_OSC_CAP_LOAD_12 0x1800U /*!< RTC oscillator, capacitance 12pF */ #define RTC_OSC_CAP_LOAD_14 0x3800U /*!< RTC oscillator, capacitance 14pF */ #define RTC_OSC_CAP_LOAD_16 0x400U /*!< RTC oscillator, capacitance 16pF */ #define RTC_OSC_CAP_LOAD_18 0x2400U /*!< RTC oscillator, capacitance 18pF */ #define RTC_OSC_CAP_LOAD_20 0x1400U /*!< RTC oscillator, capacitance 20pF */ #define RTC_OSC_CAP_LOAD_22 0x3400U /*!< RTC oscillator, capacitance 22pF */ #define RTC_OSC_CAP_LOAD_24 0xC00U /*!< RTC oscillator, capacitance 24pF */ #define RTC_OSC_CAP_LOAD_26 0x2C00U /*!< RTC oscillator, capacitance 26pF */ #define RTC_OSC_CAP_LOAD_28 0x1C00U /*!< RTC oscillator, capacitance 28pF */ #define RTC_OSC_CAP_LOAD_30 0x3C00U /*!< RTC oscillator, capacitance 30pF */ Search the CLOCK_CONFIG_EnableRtcOsc call to a function inside the BOARD_BootClockRUN function (also in the clock_config.c file), and edit the argument by any of the defines above. Finally, disable the low power options and led support in the "preinclude.h" file located in the source folder of the project: #define cPWR_UsePowerDownMode 0 #define gLEDSupported_d 0 At this point, you can measure in PTB3 and play with the frequency adjust using your frequency counter. Each time that the board is programmed, you need to perform a POR to get the correct measure. The following table was obtained from an FRDM-KW36 board rev B and it can be used as a reference to adjust the frequency. Please note that the capacitance is not only composed of the enabled internal capacitance, but also the parasitic capacitances found in the package, bond wires, bond pad, and the PCB traces. So, while the reference measurements given below should be close to the actual value, you should also make measurements with your board, to ensure that the frequency is trimmed specifically to your board and layout.   Enabled Capacitors CLOAD Capacitance Definition Frequency - 0pF RTC_OSC_CAP_LOAD_0 (bank disabled) 32772.980Hz SC2P 2pF RTC_OSC_CAP_LOAD_2 32771.330Hz SC4P 4pF RTC_OSC_CAP_LOAD_4 32770.050Hz SC2P, SC4P 6pF RTC_OSC_CAP_LOAD_6 32769.122Hz SC8P 8pF RTC_OSC_CAP_LOAD_8 32768.289Hz SC2P, SC8P 10pF RTC_OSC_CAP_LOAD_10 32767.701Hz SC4P, SC8P 12pF RTC_OSC_CAP_LOAD_12 32767.182Hz SC2P, SC4P, SC8P 14pF RTC_OSC_CAP_LOAD_14 32766.766Hz SC16P 16pF RTC_OSC_CAP_LOAD_16 32766.338Hz SC2P, SC16P 18pF RTC_OSC_CAP_LOAD_18 32766.038Hz SC4P, SC16P 20pF RTC_OSC_CAP_LOAD_20 32765.762Hz SC2P, SC4P, SC16P 22pF RTC_OSC_CAP_LOAD_22 32765.532Hz SC8P, SC16P 24pF RTC_OSC_CAP_LOAD_24 32765.297Hz SC2P, SC8P, SC16P 26pF RTC_OSC_CAP_LOAD_26 32765.117Hz SC4P, SC8P, SC16P 28pF RTC_OSC_CAP_LOAD_28 32764.940Hz SC2P, SC4P, SC8P, SC16P 30pF RTC_OSC_CAP_LOAD_30 32764.764Hz

Introduction This document is to guide how to modify the OTAP Client software to the Low Power module. The starting point of this document is the OTAP Client example in the FRDM-KW36 SDK v2.2.2.   Deep Sleep Modes This section provides a base to understand how the developer should change between DSM1 (Deep Sleep Mode 1) and DSM3 (Deep Sleep Mode 3). The DSM6 does not need to be started by the developer, instead, the controller configures this mode automatically and returns to the latest mode after finished the radio activity.   DSM1 This low-power mode was designed to be used when the BLE stack is active, in other words when the LL is in advertising, scanning, or connection states. In this mode, the MCU enters LLS3 and BLE Link Layer enters deep sleep. The SoC wakes up from this mode by the on-board switches, by LPTMR timeout, or by BLE Link Layer wake-up interrupt (BLE_LL reference clock reaches wake up instance register) using LLWU module. The LPTMR timer is used to measure the time that the MCU spends in deep sleep to synchronize low-power timers at wakeup.   DSM3 This low-power mode was designed to be used when all stacks enabled for this platform are idle, in other words, when the LL stop advertising, scanning, or connection. In this mode, the MCU enters LLS3 and all enabled link layers remain idle. All RAM is retained. The SoC wakes up from this mode by the on-board switches, by DCDC power switch (when DCDC is in buck mode), or by LPTMR timeout using LLWU module. The LPTMR timer is also used to measure the time that MCU spends in deep sleep to synchronize low-power timers at wakeup.   DSM6 This low-power mode was developed to save some power while the radio is on. Its most common use case is with the radio in Rx waiting for a packet. Upon receiving the packet the radio wakes up the MCU. In this mode, the MCU enters STOP mode and the radio maintains its state. Any module capable of producing an interrupt can wake up the MCU, such as on-board switches, DCDC power switch (when DCDC is in buck mode), LPTMR timeout, Radio Interrupt, UART, and so on. The LPTMR timer is also used to measure the time that the MCU spends in deep sleep to synchronize low-power timers at wakeup.   For more information about DSM modes, you can inspect the “Connectivity Framework Reference Manual” chapter 3.15 Low-power library, it provides full information of Low Power modes and the usage on the NXP stack. It is available in your SDK at <FRDM-KW36 SDK root>\docs\wireless\Common.   Modifications on the Software In order to add low power on the OTAP Client (switching between DSM1, DSM3, and DSM6) two files must be modified: - app_preinclude.h - otap_client_att.c The following sections explain these changes.   app_preinclude.h This file is intended to contain the definitions that manage the behavior of the application. To include and enable the Low Power module you must add (or modify if the macro is already defined in this file) the following preprocessor directives.   1. Modify the AppPoolsDetails as following. /* Defines pools by block size and number of blocks. Must be aligned to 4 bytes.*/ #define AppPoolsDetails_c \ _block_size_ 32 _number_of_blocks_ 6 _eol_ \ _block_size_ 64 _number_of_blocks_ 4 _eol_ \ _block_size_ 88 _number_of_blocks_ 3 _eol_ \ _block_size_ 248 _number_of_blocks_ 2 _eol_ \ _block_size_ 312 _number_of_blocks_ 1 _eol_ \ _block_size_ 392 _number_of_blocks_ 1 _eol_‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 2. Set “cPWR_UsePowerDownMode” to 1 and keep the following directives in the “Framework Configuration” section as shown below. /* Check Low Power Timer */ #define cPWR_CheckLowPowerTimers 1 /* Enable/Disable Low Power Timer */ #define gTMR_EnableLowPowerTimers 1 /* Enable/Disable PowerDown functionality in PwrLib */ #define cPWR_UsePowerDownMode 1 /* Enable/Disable BLE Link Layer DSM */ #define cPWR_BLE_LL_Enable 1 /* Default Deep Sleep Mode*/ #define cPWR_DeepSleepMode 3 /* Enable/Disable MCU Sleep During BLE Events */ #define cMCU_SleepDuringBleEvents 1 /* Default deep sleep duration in ms */ #define cPWR_DeepSleepDurationMs 30000 /* Number of slots(625us) before the wake up instant before which the hardware needs to exit from deep sleep mode. */ #define cPWR_BLE_LL_OffsetToWakeupInstant 3 /* Enables / Disables the DCDC platform component */ #define gDCDC_Enabled_d 1 /* Default DCDC Mode used by the application */ #define APP_DCDC_MODE gDCDC_Mode_Buck_c /* Default DCDC Battery Level Monitor interval */ #define APP_DCDC_VBAT_MONITOR_INTERVAL 600000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3. Add the following directives in the “BLE Stack Configuration” section. Create the “Auto Configuration” section to disable LED support whenever Low Power is enabled. /*! ********************************************************************************* * BLE Stack Configuration ********************************************************************************** */ /* Time between the beginning of two consecutive advertising PDU's */ #define mcAdvertisingPacketInterval_c 0x02 /* 1.25 msec */ /* Offset to the first instant register. */ #define mcOffsetToFirstInstant_c 0x00 /* 625usec */ /*! ********************************************************************************* * Auto Configuration ********************************************************************************** */ /* Disable LEDs when enabling low power */ #if cPWR_UsePowerDownMode || gMWS_UseCoexistence_d #define gLEDSupported_d 0 #endif #if gMWS_UseCoexistence_d #undef gKBD_KeysCount_c #define gKBD_KeysCount_c 1 #endif‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 4. Modify the “Memory Pools Configuration” section as follows. /* Enable RNG seed storage in Flash */ #define gRngSeedStorageAddr_d ((uint32_t)FREESCALE_PROD_DATA_BASE_ADDR + 1024) /* Enable XCVR calibration storage in Flash */ #define gPreserveXcvrDacTrimValue_d 1 #define gXcvrDacTrimValueSorageAddr_d ((uint32_t)FREESCALE_PROD_DATA_BASE_ADDR + 1040) /* Application Connection sleep mode */ #define gAppDeepSleepMode_c 1 /* Application RAM usage configuration */ #define cPWR_RamRetentionInVLLS 2 /* 32K */ /* Disable unused LowPower modes */ #define cPWR_EnableDeepSleepMode_1 1 #define cPWR_EnableDeepSleepMode_2 0 #define cPWR_EnableDeepSleepMode_3 1 #define cPWR_EnableDeepSleepMode_4 0 #define cPWR_EnableDeepSleepMode_5 0 #define cPWR_EnableDeepSleepMode_7 0 #define cPWR_EnableDeepSleepMode_8 0 /* Warm-boot sequence will use the default stack which is used by ISRs on FreeRTOS */ #define USE_WARMBOOT_SP 0‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   otap_client_att.c This is the main source file at the application level. Here are managed all the procedures that the device performs, before, during, and after to create a connection. This allows you to get the state of the device any instant and, hence, the dedicated low power APIs that rule the application must be implemented here, in the callbacks contained in this file, for an easier switching among the low power states.   1. Include “PWR_Configuration.h” header in “Include” section: #if (cPWR_UsePowerDownMode) #include "PWR_Interface.h" #include "PWR_Configuration.h" #endif‍‍‍‍‍‍‍‍‍‍‍‍ 2. Locate the “BleApp_Config” function. This function is executed once, after POR (Power on reset) during the device setup. Here you can change the deep sleep mode to DSM3 and allow the device to sleep using “PWR_ChangeDeepSleepMode” and “PWR_AllowDeviceToSleep” APIs. When the device has finished the initialization, it goes to sleep since all stacks are idle. See the following example. static void BleApp_Config(void) { #if defined(MULTICORE_APPLICATION_CORE) && (MULTICORE_APPLICATION_CORE == 1) if (GattDbDynamic_CreateDatabase() != gBleSuccess_c) { panic(0,0,0,0); return; } #endif /* MULTICORE_APPLICATION_CORE */ /* Common GAP configuration */ BleConnManager_GapCommonConfig(); /* Register stack callbacks */ (void)App_RegisterGattServerCallback (BleApp_GattServerCallback);‍‍‍‍‍‍‍‍‍‍‍‍‍ mAdvState.advOn = FALSE; /* Start services */ basServiceConfig.batteryLevel = BOARD_GetBatteryLevel(); (void)Bas_Start(&basServiceConfig); (void)Dis_Start(&disServiceConfig); if (OtapClient_Config() == FALSE) { /* An error occurred in configuring the OTAP Client */ panic(0,0,0,0); } /* Allocate application timer */ appTimerId = TMR_AllocateTimer(); mBatteryMeasurementTimerId = TMR_AllocateTimer(); #if (cPWR_UsePowerDownMode) #if MULTICORE_APPLICATION_CORE #if gErpcLowPowerApiServiceIncluded_c PWR_ChangeBlackBoxDeepSleepMode(cPWR_DeepSleepMode); PWR_AllowBlackBoxToSleep(); #endif PWR_ChangeDeepSleepMode(cPWR_DeepSleepMode); PWR_AllowDeviceToSleep(); #else PWR_ChangeDeepSleepMode(cPWR_DeepSleepMode); PWR_AllowDeviceToSleep(); #endif #endif }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3. Locate the “BleApp_Start” function. This function is executed just after wake up by pressing the LLWU SW3 button. This action will trigger the advertising, so, you must change the deep sleep mode to DSM1 using “PWR_ChangeDeepSleepMode” API since the BLE stack is active. See the following example. void BleApp_Start(void) { Led1On(); if (mPeerDeviceId == gInvalidDeviceId_c) { /* Device is not connected and not advertising*/ if (!mAdvState.advOn) { #if gAppUseBonding_d if (gcBondedDevices > 0) { mAdvState.advType = whiteListAdvState_c; } else { #endif mAdvState.advType = advState_c; #if gAppUseBonding_d } #endif #if (cPWR_UsePowerDownMode) #if MULTICORE_APPLICATION_CORE #if gErpcLowPowerApiServiceIncluded_c PWR_ChangeBlackBoxDeepSleepMode(gAppDeepSleepMode_c); #endif #else PWR_ChangeDeepSleepMode(gAppDeepSleepMode_c); #endif #endif BleApp_Advertise(); } } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 4. Locate the “BleApp_AdvertisingCallback” function. This function is executed every time the advertising state changes. Change the deep sleep mode to DSM3 when “mAdvState.advOn” is false, in other words, when the device stops advertising. If you stop the advertising either using an application timer or a user button, KW36 will go to sleep until you start advertising again (pressing LLWU SW3 button), saving power when all stacks are idle. See the following example. static void BleApp_AdvertisingCallback (gapAdvertisingEvent_t* pAdvertisingEvent) { switch (pAdvertisingEvent->eventType) { case gAdvertisingStateChanged_c: { mAdvState.advOn = !mAdvState.advOn; if(mAdvState.advOn) { LED_StopFlashingAllLeds(); Led1Flashing(); } #if (cPWR_UsePowerDownMode) else { #if MULTICORE_APPLICATION_CORE #if gErpcLowPowerApiServiceIncluded_c PWR_ChangeBlackBoxDeepSleepMode(cPWR_DeepSleepMode); #endif #else PWR_ChangeDeepSleepMode(cPWR_DeepSleepMode); #endif } #endif } break; case gAdvertisingCommandFailed_c: { Led2On(); panic(0,0,0,0); } break; default: ; /* For MISRA compliance */ break; } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 5. Locate “BleApp_ConnectionCallback” function. It is executed every time the connection state changes. In “gConnEvtConnected_c” add the following code to change to DSM1, since the BLE stack is active. case gConnEvtConnected_c: { /* Advertising stops when connected */ mAdvState.advOn = FALSE; (void)TMR_StopTimer(appTimerId); /* Subscribe client*/ mPeerDeviceId = peerDeviceId; (void)Bas_Subscribe(&basServiceConfig, peerDeviceId); (void)OtapCS_Subscribe(peerDeviceId); OtapClient_HandleConnectionEvent (peerDeviceId); /* Start battery measurements */ (void)TMR_StartLowPowerTimer(mBatteryMeasurementTimerId, gTmrLowPowerIntervalMillisTimer_c, TmrSeconds(mBatteryLevelReportInterval_c), BatteryMeasurementTimerCallback, NULL); #if (cPWR_UsePowerDownMode) #if MULTICORE_APPLICATION_CORE #if gErpcLowPowerApiServiceIncluded_c PWR_ChangeBlackBoxDeepSleepMode(gAppDeepSleepMode_c); PWR_AllowBlackBoxToSleep(); #endif #else PWR_ChangeDeepSleepMode(gAppDeepSleepMode_c); PWR_AllowDeviceToSleep(); #endif #else /* UI */ LED_StopFlashingAllLeds(); Led1On(); #endif } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ In “gConnEvtDisconnected_c” add the following code to change to DSM3, since all stacks are idle. case gConnEvtDisconnected_c: { /* Unsubscribe client */ mPeerDeviceId = gInvalidDeviceId_c; (void)Bas_Unsubscribe(&basServiceConfig, peerDeviceId); (void)OtapCS_Unsubscribe(); /* UI */ LED_StopFlashingAllLeds(); Led1Flashing(); Led2Flashing(); Led3Flashing(); Led4Flashing();‍‍‍‍‍‍‍‍‍‍‍‍ OtapClient_HandleDisconnectionEvent (peerDeviceId); #if (cPWR_UsePowerDownMode) /* Go to sleep */ #if MULTICORE_APPLICATION_CORE #if gErpcLowPowerApiServiceIncluded_c PWR_ChangeBlackBoxDeepSleepMode(cPWR_DeepSleepMode); #endif #else PWR_ChangeDeepSleepMode(cPWR_DeepSleepMode); #endif #else /* Restart advertising*/ BleApp_Start(); #endif } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Power Consumption Profile of OTAP Client This section explains the behavior of the power consumption profile along the time. We can differ when DSM1 or DSM3 are used depending on the device state. If the device needs to advertise or is in connection state, it will use DSM1 because this sleep mode can predict when the device needs to handle the communication with others and wake up automatically through the BLE Link Layer wakeup interrupt. On the other hand, when no actions are in progress, it will use DSM3 and the wake up depends entirely on the LLWU SW3 button in this example. On the other hand, the DSM6 puts the MCU in STOP mode during the transmission and reception in BLE events, it does not need to be started manually, instead, the controller configures this mode automatically and returns to DSM1 mode after finished the radio activity.   The APIs that change the deep sleep mode to DSM1 are: • BleApp_Start: It starts advertising. • BleApp_ConnectionCallback – gConnEvtConnected_d: It notifies when the MCU has been connected to a peer device.   The APIs that change the deep sleep mode to DSM3 are: • BleApp_Config: It takes part of the initialization procedure after POR. All tasks are idle, the device is waiting for the LLWU SW3 button to wake up and start advertising. • BleApp_AdvertisingCallback – mAdvState is off: The device has to stopped advertising, so the MCU is idle. • BleApp_ConnectionCallback – gConnEvtDisconnected_d: It notifies when the device has been disconnected, so the MCU is idle.   Please let us know any questions or comments regarding this topic.

/*** 2024 July 4th latest disclaimers:  - KW47, MCX W72 is a direct derivative from KW4x - please bookmark this page for future update - this article is for early enablement based on KW45, K32W148, MCX W71 and is pending updates up to wider releases of new KW47 and MCX W72 ---- Datasheet and HW manufacturing files shared on request----  ***/ Please, find the important link to build a PCB using a KW47 or MCX W72 and all concerning the radio performances, low power and radio certification (CE/FCC/IC).     KW47 product NXP web page:  pending release of KW47/MCXW72  MCXW72 product NXP web page: pending release of KW47/MCXW72  KW-MCXW-EVK getting started NXP web page pending release of KW47/MCXW72    HW:     KW47-MCXW72-EVK HW guideline: Available on request        HVQFN48 package specification: SOT619-17(D)   pending release of SOT619-17(DD)       KW47-MCXW72-EVK User Manual pending release of KW47/MCXW72        Minimum BoM (attached file) >> KW45 applicable for KW47 waiting release of KW47/MCXW72      DCDC management guide (AN13831) : KW45/K32W148 - Power Management Hardware (nxp.com) KW45 applicable for KW47 waiting release of KW47/MCXW72      Design-In check list: see attached file at the bottom of this article     RF matching: S parameters (attached file) pending release of KW47/MCXW72    Information: “As RF behavior are dependent of PCB layout & manufacturing; PCB prototypes (based on NXP recommendations) will have to be fine-tuned to insure the expected qualified in RF is reached on the final productized platform.”   Radio:     RF report: KW45 and K32W148 RF System Evaluation Report for Bluetooth LE and K32W148 for 802.15.4 Applications ... pending release of KW47/MCXW72      Radio co-existence: Kinetis Wireless Family Products Bluetooth Low Energy Coexistence with Wi-Fi Application (nxp.com) pending release of KW47/MCXW72      Distance performances: refer to attached file pending release of KW47/MCXW72      Antenna:  Compact Planar Antennas for 2.4 GHz Communication Designs and Applications within NXP EVK Boards Antennas for Channel Sounding Applications     Generic FSK Link Layer Quick Start (attached file)     BLE connectectivity test binary file:  SDK_x_xx_x_KW45B41Z-EVK\boards\kw45b41zevk\wireless_examples\genfsk\connectivity_test\bm\iar\     pending release of KW47/MCXW72       Return loss (S11) measurement: How to measure the return loss of your RF matching (S11)                    part of the RF report (AN13728)     Loadpull: pending release of KW47/MCXW72   SW tools:     IoT Tool box (mobile application)     Connectivity test tool for connectivity products (part of the IoT toolbox)     DTM: How to use the HCI_bb on Kinetis family products a... - NXP Community https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-...   Crystal Article 1 :pending release of KW47/MCXW72     LowPower Estimator Tool https://community.nxp.com/t5/Wireless-Connectivity/Kinetis-KW35-38-KW45-amp-K32W1-MCXW71-Power-Profi... pending release of KW47/MCXW72       Low Power Consumption: https://www.nxp.com/docs/en/application-note/AN13230.pdf pending release of KW47/MCXW72     Certification: pending release of KW47/MCXW72