Thread is a secure, wireless, simplified IPv6-based mesh networking protocol developed by industry leading technology companies, including Freescale, for connecting devices to each other, to the internet and to the cloud. Before starting a Thread Network implementation, users should be familiar with some concepts and how they are related to Thread protocol. IPv6 Addressing Devices in the Thread stack support IPv6 addressing IPv6 addresses are 128-bit identifiers (IPv4 is only 32-bit) for interfaces and sets of interfaces.  Thread supports the following types of addresses: Unicast:  An identifier for a single interface.  A packet sent to a unicast address is delivered to the interface identified by that address. Multicast: An identifier for a set of interfaces (typically belonging to different nodes).  A packet sent to a multicast address is delivered to all interfaces identified by that address. NOTES There are no broadcast addresses in IPv6, their function being superseded by multicast addresses. Each device joining the Thread Network is also assigned a 16-bit short address as specified in IEEE 802.15.4. 6LoWPAN All Thread devices use 6LoWPAN 6LoWPAN stands for “IPv6 over Low Power Wireless Personal Networks”. 6LoWPAN is a set of standards defined by the Internet Engineering Task Force (IETF), which enables the efficient use of IPv6 over low-power, low-rate wireless networks on simple embedded devices through an adaptation layer and the optimization of related protocols. Its main goal is to send/receive IPv6 packets over 802.15.4 links. Next figure compares IP and 6LoWPAN protocol stacks: The following concepts would explain the transport layer. ICMP Thread devices support the ICMPv6 (Internet Control Message Protocol version 6) protocol and ICMPv6 error messages, as well as the echo request and echo reply messages. The Internet Control Message Protocol (ICMP) is an error reporting and diagnostic utility and is considered a required part of any IP implementation. ICMPs are used by routers, intermediary devices, or hosts to communicate updates or error information to other routers, intermediary devices, or hosts. For instance, ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.  The ICMPv6 messages have the following general format: The type field indicates the type of the message.  Its value determines the format of the remaining data. The code field depends on the message type.  It is used to create an additional level of message granularity. The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. ICMPv6 messages are grouped into two classes: error messages and informational messages.  Error messages are identified as such by a zero in the high-order bit of their message Type field values.  Thus,   error messages have message types from 0 to 127; informational messages have message types from 128 to 255. UDP The Thread stack supports UDP for messaging between devices. This User Datagram Protocol  (UDP)  is defined  to  make available  a datagram   mode of  packet-switched   computer communication  in  the environment  of an  interconnected  set  of  computer  networks, assuming that the Internet  Protocol (IP) is used as the underlying protocol. With UDP, applications can send data messages to other hosts on an IP network without prior communications to set up special transmission channels or data paths. UDP is suitable for purposes where error checking and correction is either not necessary or is performed in the application, avoiding the overhead of such processing at the network interface level. The UDP format is as follows: Source Port is an optional field, when meaningful, it indicates the port of the sending  process,  and may be assumed  to be the port  to which a reply should be addressed  in the absence of any other information.  If not used, a value of zero is inserted. Destination Port has a meaning within the context of a particular internet destination address. Length is the length in octets of this user datagram including this header and the data.   (This means the minimum value of the length is eight.) Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded  with zero octets at the end (if  necessary)  to  make  a multiple of two octets. References White papers available at http://threadgroup.org/ “6LoWPAN: The Wireless Embedded Internet” by Zach Shelby and Carsten Bromann RFC 4291, RFC 4944, RFC 4443 and RFC 768 from https://www.ietf.org

Brief Description NXP Tire Pressure Monitoring Sensors (TPMS) were preloaded the firmware libraries and test software for a variety of customer use cases. The preloaded TPMS bootloader provides wireless software update function for the aftermarket. This demo uses Kinetis KW01 and Low Frequency emitter to accomplish TPMS over-the-air software update.   Reference Picture   Block Diagram   Features 315 MHz RF 125 KHz LF FSK modulation Manchester Encoding Timer/PWM Modules IAR Embedded Workbench for ARM 7.40 CodeWarrior V6.3   NXP Parts Used MRB-KW019032 (MKW01Z128CHN) TPMS870911 (FXTH870911DT1) LF Emitter Board   Get Software MKW01_TPMS_bootloader.rar MPXY8702_TPMS_bootloader.rar TPMS-MKW01-IAR7v4-Project.zip   General Stage Prototype Launched for Alpha customers     Demo Setup   Hardware Requirements MRB-KW019032 x 2         MRB-KW019032 Board A: Connected with LF Emitter Board         MRB-KW019032 Board B: Standalone TPMS879011 x 1 LF Emitter Board x 1   Hardware Connection   Pin function MRB-KW019032 LF Emitter Board TPM1_CH0 PTB0 (J15-9) J5-20 TPM1_CH1 PTB1 (J14-8) J5-28 GND GND (J15-2) J6-4   Demo Description A prebuild TPMS870911 firmware is stored in MRB-KW019032 Board A and this firmware will be sent to TPMS870911 via 125kHz LF signal. After TPMS870911 completes the firmware update, TPMS870911 will send the information of pressure sensor to MRB-KW019032 Board B via 315 MHz RF signal.   Demo Procedure Download MKW01_TPMS_bootloader into MRB-KW019032 Board A with IAR 7.40 Download TPMS-MKW01-IAR7v4-Project into MRB-KW019032 Board B with IAR 7.40 Download MPXY8702_TPMS_bootloader into TPMS870911 with CodeWarrior V6.3 Connect USB cable between PC and both of MRB-KW019032 boards, and open the terminal with the following settings • 115200 baud rate • 8 data bits • No parity • One stop bit • No flow control    5. Press the reset button on both of MRB-KW019032 boards and then the demo message will be shown on the terminal.     6. Short Pin19 of J15 (PTD6) on MRB-KW019032 Board A as SW3 press to start TPMS870911 over-the-air software update. 7. After TPMS870911 completes software update, MRB-KW019032 Board B will print the received RF message which was sent from TPMS870911 on the terminal.                         Original Attachment has been moved to: TPMS-MKW01-IAR7v4-Project.zip Original Attachment has been moved to: MPXY8702_TPMS_bootloader.rar Original Attachment has been moved to: MKW01_TPMS_bootloader.rar

A network is basically a set of devices connected to one another and communicating using wired or wireless mediums. There are several standard network frameworks defined for wired and wireless communication by IEEE. This post provides information about the IEEE 802 standard and network modes.   802 Standard The 802 standard is a family of IEEE standards dealing with local and metropolitan area networks. The protocol specified in the 802 standard covers lower two layers of the OSI model that are Physical and Data Link layers. In the 802 standard, the Data link layer (Layer 2 of the OSI model) has been divided into two parts Logical Link Control (LLC) and Media Access Control (MAC) as shown in figure below.   Figure 1. Layer architecture   The active 802 standards are listed below.   Table 1. 802 standards description Standard Name Description 802.1 Internetworking It ensures the management of the Local Area Network (LAN) / Metropolitan Area Network (MAN) network and monitors network capabilities. MAC bridging, data encryption/encoding, and network traffic management services are also provided. 802.3 Ethernet Ethernet based technology that is primarily used for LAN, it can also be used for MAN and Wide Area Network (WAN).     802.3 defines the Physical and MAC sublayer of the Data Link layer that is used in wired networks. Uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD) for collision detection. Data rates can be from 10Mbps to 10Gbps. 802.11 WLAN, Wi-Fi Wireless LAN uses high radio frequencies instead of cables to connect the devices in the network. Portability and setup cost is cheaper compared to wired networks but speed and security are better in wired communication. It uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for collision avoidance. 802.15 WPAN This covers various protocol definitions for the personal area network like Bluetooth, ZigBee & sensors networks.   WLAN and Wi-Fi Introduction Wireless Local Area Network (WLAN) or Wireless LAN, is a network that links two or more devices using wireless communication to form a local area network within a limited area such as a home, campus, and office building. A WLAN can be built on various wireless technologies i.e. Wi-Fi, Infrared. Wi-Fi is a type of WLAN that follows IEEE 802.11 standards and one of the most commonly used WLAN today. Wi-Fi as a name for the standard is a trademark of the Wi-Fi Alliance. Wi-Fi or WLAN networks use radio waves to exchange information between devices. These radio waves are transmitted on specific frequencies - 2.4 GHz and 5 GHz, depending on the 802.11 standard (IEEE 802.11a/b/g/n/ac/ax) that the device uses. A Wi-Fi connection is established using a wireless adapter to create hotspots – areas in the vicinity of a wireless router that is connected to the network and allow users to access internet services. All Wi-Fi versions uses license free bands (ISM bands) across the globe.   Network Modes Ad-Hoc Mode In this mode wireless nodes communicate to peer nodes directly. It does not use Access Point (AP) instead it uses Mesh topology. It is also called peer to peer mode. An ad-hoc wireless network is more cost-effective than its alternative, since it does not require the installation of an AP to operate. In addition, it also needs less time to set up. Figure 2. Ad-Hoc mode   Infrastructure Mode In this mode, devices can communicate with each other first going through AP. In infrastructure mode, the wireless devices can communicate with each other or can communicate with a wired network as it’s communicating through AP. This mode is the most commonly used network mode. Compared to Ad-Hoc wireless networks, infrastructure mode offers the advantages of scale, centralized security management, and improved reach. Infrastructure mode has half throughput compared to Ad-Hoc mode.   Figure 3. Infrastructure mode   Repeater Mode When two wireless host devices have to be connected and the distance between them is long for the direct connection or obstruction is present, at that time repeater mode is used to bridge the gap. Repeater operates at the physical layer of the OSI model. As a Wireless Repeater, an AP node extends the range of the wireless network by repeating the wireless signal of the remote AP. The Ethernet MAC address of the remote AP is required for the AP to act as a wireless range extender. The repeater mode has certain drawbacks. Throughput is reduced by at least 50% as wireless interference is at least doubled. The bandwidth of any device connected to it is halved. This is due to the repeater receiving the signal, processing it, and then rebroadcasting it in both directions, from the router to the device and vice versa. The Repeater must be kept in the range of AP, but not too close to the AP. Distance between AP and repeater depends on the range of the AP and repeater should be kept in such a way that maximum possible area coverage can be achieved.   Figure 4. Repeater mode   Bridge Mode Bridge connects two or more networks to each other. It operates on the Data link layer of the OSI Model. Bridge mode allows the AP to communicate with another AP capable of point-to-point bridging. An example of this is connecting two buildings through a wireless connection.   Figure 5. Bridge mode

Many applications make use of 32 kHz clocks to keep tracking of real-time or to have a low power time reference for the system. Most of the systems might use a 32.768 kHz XTAL for this purpose. However, there might be some exceptions in which the application requires compensate the frequency of this clock due to temperature changes, aging, or just because the clock provides from a source which frequency is close to the ideal 32.768 kHz, but it presents some variations. QN908x devices require a 32 kHz clock source for some applications like running the BLE stack in low power. 32.768 kHz XTALs are more accurate so they are used to generate a 32 kHz source by compensating for the ppm difference. This provides us with tools to compensate for any external 32 kHz source by first obtaining the ppm difference from the ideal frequency. The solution consists in determining how off is the external clock input frequency from the ideal 32 kHz by making a comparison with a trusted clock in the system, typically the 32 MHz / 16 MHz XTAL. This process is executed in the background in an interrupt-based system so the application can initialize or run other processes in the meantime. Then, the results of the ppm calculation are reported to the main application to compensate for the changes and provide for a more accurate clock source. This example makes use of the following peripherals in the QN908x RTC Seconds Timer CTIMER DMA The RTC Seconds Timer uses the 32 kHz clock source as a reference. It contains an internal 32000 cycles counter that increases each 32 kHz clock period. On overflow, it rises the SEC_INT flag to indicate that one second has elapsed. The CTIMER makes use of the APB clock which derives from the 32 MHz / 16 MHz clock. This timer is used in free-running mode with a Prescaler value of 1 to count the number of APB pulses. The algorithm consists of counting the amount of APB pulses (trusted clock reference) elapsed by the time the RTC SEC_INT flag is set. Ideally, if both clocks are in the right frequency, the number of APB pulses must be equal to the reference clock frequency. For example, if the APB clock is 16 MHz, by the time the SEC_INT flag sets, the CTIMER counter must have a value of 16 x 10 6 counts. Assuming our reference clock is ideal, the difference between the CTIMER counter value and 16 x 10 6 can be used to obtain the ppm difference given the following formula. Where f 0 is the ideal APB frequency (16 MHz) and f 1 is the real measured frequency (CTIMER counter value). Since the pulses counted using the CTIMER correspond to the time it took to the RTC Seconds Timer to count one second, we can extrapolate the obtained ppm value as a difference in the 32 kHz clock source from the ideal 32 kHz. To prevent from any application or task servicing latency, the algorithm makes use of the DMA to automatically capture the CTIMER Counter value when the SEC_INT flag is set. The program flow is described in the diagram below. As a way of demonstrating this algorithm, two APIs were implemented to calculate the ppm value and apply the compensation to the system. Both APIs are included in the file fsl_osc_32k_cal .c and .h files. OSC_32K_CAL_GetPpm (osc_32k_cal_callback_t pCallbackFnc): Initializes the required timers and DMA and starts with the CTIMER capture. A callback is passed so it can be executed once the ppm calculation sequence completes. OSC_32_CAL_ApplyPpm (int32_t ppmMeasurement): Uses the previously calculated ppm passed as an input parameter to compensate the RTC and the BLE timer used during sleep mode. OSC_32K_CAL_GetPpm is called every time the ppm value of the 32 kHz source clock needs to be calculated. It takes around one second to complete (depending on how off the 32 kHz source clock is from the ideal frequency) and the application cannot enter into low power state during this time. The registered callback function is executed once the calculation is complete. The ppm calculation is performed into the DMA callback. It consists of obtaining the CTIMER counter difference and use it as f 1 in the formula shown before. The ppm values are calculated using floating point unit. /* Calculate PPMs */ ppmResult = (float)((float)1-((float)ApbClockFreq/(float)ApbCountDiff)); ppmResult *= (float)1048576;‍‍‍‍‍‍ Then OSC_32_CAL_ApplyPpm must be called using the ppm value obtained after calling OSC_32K_CAL_GetPpm. This API programs the necessary values in the RTCàCAL register and the BLE Sleep timer registers to compensate for the differences in the 32 kHz source clock. Finally, the user must account for all those other APIs that make use of the 32 kHz clock frequency and update the values accordingly. For the particular case of the NXP BLE Stack, there are two APIs that need to be updated to return the clock frequency after the calibration has been applied. uint32_t PWRLib_LPTMR_GetInputFrequency(void) { uint32_t result = 32000; int32_t ppm = 0; if ( RTC->CTRL & RTC_CTRL_CAL_EN_MASK) /* is calibration enabled ? */ { /* Get the current calibration value */ if (RTC->CAL & RTC_CAL_DIR_MASK) { /* Backward calibration */ ppm -= (int32_t) (RTC->CAL & RTC_CAL_PPM_MASK); } else { /* Forward calibration */ ppm += (int32_t) (RTC->CAL & RTC_CAL_PPM_MASK); } /* Obtain the uncalibrated clock frequency using the formula * fUncal = 32000 - (ppm*0.03125) where 0.03125 is the number * of Hz per PPM digit obtained from (768 Hz/0x6000 PPM) */ result -= (float) ppm * (float) 0.03125; } else { #if (defined(BOARD_XTAL1_CLK_HZ) && (BOARD_XTAL1_CLK_HZ == CLK_XTAL_32KHZ)) result = CLOCK_GetFreq(kCLOCK_32KClk); /* 32,768Khz crystal is used */ #else result = CLOCK_GetFreq(kCLOCK_32KClk); /* 32,000Khz internal RCO is used */ #endif } return result; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ uint32_t StackTimer_GetInputFrequency(void) { uint32_t prescaller = 0; uint32_t refClk = 0; uint32_t result = 0; #if FSL_FEATURE_SOC_FTM_COUNT refClk = BOARD_GetFtmClock(gStackTimerInstance_c); prescaller = mFtmConfig.prescale; result = refClk / (1 << prescaller); #elif FSL_FEATURE_RTC_HAS_FRC int32_t ppm = 0; (void)prescaller; /* unused variables */ (void)refClk; /* suppress warnings */ result = 32000; if ( RTC->CTRL & RTC_CTRL_CAL_EN_MASK) /* is calibration enabled ? */ { /* Get the current calibration value */ if (RTC->CAL & RTC_CAL_DIR_MASK) { /* Backward calibration */ ppm -= (int32_t) (RTC->CAL & RTC_CAL_PPM_MASK); } else { /* Forward calibration */ ppm += (int32_t) (RTC->CAL & RTC_CAL_PPM_MASK); } /* Obtain the uncalibrated clock frequency using the formula * fUncal = 32000 - (ppm*0.03125) where 0.03125 is the number * of Hz per PPM digit obtained from (768 Hz/0x6000 PPM) */ result -= (float) ppm * (float) 0.03125; } else { #if (defined(BOARD_XTAL1_CLK_HZ) && (BOARD_XTAL1_CLK_HZ == CLK_XTAL_32KHZ)) result = CLOCK_GetFreq(kCLOCK_32KClk); /* 32,768Khz crystal is used */ #else result = CLOCK_GetFreq(kCLOCK_32KClk); /* 32,000Khz internal RCO is used */ #endif } #elif FSL_FEATURE_SOC_CTIMER_COUNT refClk = BOARD_GetCtimerClock(mCtimerBase[gStackTimerInstance_c]); prescaller = mCtimerConfig[gStackTimerInstance_c].prescale; result = refClk / (prescaller + 1); #else refClk = BOARD_GetTpmClock(gStackTimerInstance_c); prescaller = mTpmConfig.prescale; result = refClk / (1 << prescaller); #endif return result; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

1.    Introduction   1.1 Document Purpose This post entry provides a detailed description of how to integrate the NFC Reader Library to a KW3x Bluetooth Low Energy application.   1.2 Audience The goal of this post is to serve as a guide for software developers who want to use, adapt and integrate the NFC Reader Library to an SDK wireless connectivity example.   1.3 References and Resources - NFC Reader Library:  nxp.com/pages/:NFC-READER-LIBRARY - NCF3320: nxp.com/products/:NCx3320  - CLRC663 plus: nxp.com/products/:CLRC66303HN - FRDM-KW36 board: nxp.com/demoboard/FRDM-KW36 - KW35/KW36 SDK: https://mcuxpresso.nxp.com/en/select - MCUXpresso IDE: nxp.com/products/: MCUXpresso-IDE   2. NFC Reader Library Overview   The NXP NFC Reader Library is a modular software library written in C language, which provides an API that enables customers to create their own software stack and applications for the NXP contactless reader ICs: - PN512; - CLRC633 family; - PN7462 family; - PN5180; This API facilitates the most common operations required in NFC applications such as: - reading or writing data into contactless cards or tags; - exchanging data with other NFC-enabled devices; - allowing NFC reader ICs to emulate cards. The NFC Reader Library is designed in a way to be easily portable to many different microcontrollers with a multi-layered architecture:   As main blocks, we have: - Application Layer (AL) - implements the command sets to interact with MIFARE cards and NFC tags. - NFC activity - implements a configurable Discovery loop for the detection of contactless cards, NFC tags or other NFC devices. - HCE and P2P components, for the emulation of Type 4 tags and P2P data exchange respectively. - Protocol abstraction layer (PAL) - contains the RF protocol implementation of the ISO14443, Felica, vicinity and NFC standards. - Hardware abstraction layer (HAL) - implements the drivers for controlling the NFC frontends RF interface and capabilities. - Driver Abstraction Layer (DAL) - implements the GPIO pinning, the timer configuration and the physical interface (BAL) between the host MCU and the reader IC. - OSAL module, in charge of abstracting the OS or RTOS specifics (tasks events, semaphores, and threads)   3. The KW3x Wireless Microcontroller Overview The KW3x wireless microcontrollers (MCU are highly integrated single-chip devices that enable Bluetooth Low Energy (Bluetooth LE) and Generic FSK connectivity for automotive, industrial and medical/healthcare embedded systems.   The KW36/35 Wireless MCU integrates an Arm® Cortex®-M0+ CPU with up to 512 KB flash and 64 KB SRAM and a 2.4 GHz radio that supports Bluetooth LE 5.0 and Generic FSK modulations. The Bluetooth LE radio supports up to 8 simultaneous connections in any master/slave combination. The KW36A/36Z includes an integrated FlexCAN module enabling seamless integration into an automotive or industrial CAN communication network, enabling communication with external control and sensor monitoring devices over Bluetooth LE.   For more details please refer to the NXP website information: https://www.nxp.com/products/wireless/bluetooth-low-energy:BLUETOOTH-LOW-ENERGY-BLE.   4. NFC Reader Library – integration with FRDM-KW36 The current NFC Reader Library v5.21.01 is not containing support for Kinetis KW3x MCU. We will use a reference the K82 NFC Reader Library package: www.nxp.com/pages/:NFC-READER-LIBRARY. The steps required to integrate the library are: - Hardware preparation (the connection between FRDM-KW36 and NFC reader board); - Setting up the development environment (SDK download, workspace); - Preparing adaptation files for FRDM-KW3x board; - Integrating NFC application to Wireless_UART Bluetooth LE example; - Running the demo;   4.1 Hardware preparation Hardware required: - NCF3320 Antenna v1.0 board as an NFC transceiver; - FRDM-KW36 board as host MCU, used to load and run the Bluetooth Low Energy Stack and NFC application logic;   The communication between the boards will be via the SPI communication using the following pin configuration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Master board (FRDM-KW36)         Connects to            Slave board (NCF3320 Antenna v1.0)           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PTB0  (J2-pin10)                                      -                    IRQ PTB1  (J2-pin9)                                         -                    Reset PTA16 (J2-pin1 - SPI1_Sout)                   -                    MOSI PTA17 (J1-pin5 - SPI1_Sin)                     -                    MISO PTA18 (J1-pin7 - SPI1_SCK)                   -                    SCK PTA19 (J2-pin3 - SPI1_CS)                     -                    CS GND   (J3-pin7)                                        -                    GND ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   4.2 Setting up the development environment   Install MCUXpresso IDE (for this example we are using v10.2.0 build 759)   - Go to MCUXpresso-IDE webpage and download the latest version of IDE: www.nxp.com/products/: MCUXpresso-IDE. - Install the IDE;     Get the latest NFC Reader Library release (for this example we are using v5.21.00) - Go to NXP NFC Reader Library webpage (www.nxp.com/pages/:NFC-READER-LIBRARY) - Go to the Downloads tab and click on the download button - Download the NFC Reader Library for Kinetis K82F package:     Generate a downloadable SDK package for FRDM-KW36 board (SDK_2.2.1_FRDM-KW36) - Navigate to https://mcuxpresso.nxp.com/en/select and select FRDM-KW36 board; - Select Build MCUXpresso SDK. - As toolchain, please make sure that the MCUXpresso IDE is selected. - Use Download SDK button to start downloading SDK package:   Create MCUXpresso workspace - Open MCUXpresso IDE and create a workspace; - Drag and drop the SDK_2.2.1_FRDM-KW36 into the installed SDKs tab of the MCUXpresso IDE;   - Import Wireless_Uart Example to the current workspace:     4.3 Preparing adaptation files for FRDM-KW3x board This chapter describes the Driver Abstraction Layer (DAL) changes required for FRDM-KW36: - unzip the NFC Reader Library and navigate to boards folder:   - Create an equivalent file for FRDM-KW36 (Board_FRDM_KW36FRc663.h) by setting the right configuration for GPIOs and handlers; - Below are the differences required for FRDM-KW36 board in comparation with a FRDM-K82F board:   - Add the FRMD-KW36 to …DAL\cfg\BoardSelection.h file:   #ifdef PHDRIVER_FRDM_KW36FRC663_BOARD #include <Board_FRDM_KW36FRc663.h> #endif   - In KinetisSDK folder, update the following dependencies: o PIT Driver IRQ name:   o Open drain and pin lock configuration: - phDriver_KinetisSDK.c:   - phbalReg_KinetisSpi.c:   - add PHDRIVER_FRDM_KW36FRC663_BOARD define to …\NxpNfcRdLib\types\ph_NxpBuild_Platform.h file to enable the right NFC transceiver:     4.4  Integrating NFC application to Wireless_UART Bluetooth LE example In this chapter we will integrate the BasicDiscoveryLoop NFC example to Wireless_UART Bluetooth LE application. For this, the following steps are required: - On the wireless_uart project location create an “nfc” folder:   - Copy from modified NFC Reader Library the DAL, NxpNfcRdLib and phOsal folders:   - On the wireless_uart project location, “source” folder create a new “nfc” subfolder to integrate the BasicDiscovery loop files:   - Some changes will be required on the BasicDiscoveryLoop files: o Main function renamed to NFC_BasicDiscoveryLoop_Start; o Removed drivers/OS initialization; (all the changes can be observed in the attachment) - Update MCUXpresso workspace by pressing F5 to see the latest changes:   - Update the linker information (Project Properties -> C/C++ Build -> Settings) and preprocessor defines (Project Properties -> C/C++ Build -> Preprocessor):     - Add dependencies: o PIT module/ PIT module initialization; o Update LED, SW configuration; o Increase heap size (gTotalHeapSize_c); o Add functionality for NFC in wireless_uart.c application; (all the changes can be observed in the attachment);   Considering the attached ZIP archive, we can be easily dragged and drop, frdmkw36_w_uart_ncf3320_basic_discovery.zip file, to the MCUXpresso workspace:       4.5 Running the demo - Create hardware connection based on chapter 4.1; - Open a serial terminal on the corresponding COM port for FRDM-KW36 board. The BaudRate used is 115200. - Press SW2 on FRDM-KW36 to start advertising. - Open Mobile APP - IOT toolbox - Wirreless UART.  The FDRM-KW36 board will be listed as NXP_WU:   - Create Bluetooth LE connection. The serial log will contain the log for Bluetooth LE operations:     - Use NFC Cards close to NCF3320 Antenna v1.0 board to initiate discovery demo. - Once the card is detected, an event is sent to the mobile application including technology and UUID of the card: (https://www.youtube.com/watch?v=wCCz5zDIwHE&feature=youtu.be)     Attached is the source code for this example application (frdmkw36_w_uart_ncf3320_basic_discovery).

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.

The connectivity software is an add-on of the Kinetis SDK, therefore the demos are referenced to a KSDK path variable named "KSDK_PATH" in IAR. The KSDK_PATH variable contains the path of the installation folder for the KSDK version in your PC. Taking as an example the MRB-KW01 SMAC Connectivity Software, we can realize that this variable is used to reference for libraries. In particular, this SMAC software for the MRB-KW01 works with KSDK 1.2, that is why you could have troubles if the variable is referenced to another KSDK version (for example KSDK 1.1). Follow the next steps to modify the KSDK_PATH variable in your computer: 1. Right click on "computer", then click "properties" 2. A Control Panel window will be opened. Click on "Advanced system settings" 3. A system Properties windows will be opened. Select the "Advanced" tab, then click "Environment Variables". 4. Select the KSDK_PATH variable and assure that it stores the correct path needed for your project. In case that you need to modify the variable, then click "Edit" 5. Finally click "Ok" to close all tabs and you will be able to run your connectivity software without problems. Best regards, Luis Burgos.

The FRDM-KW40Z 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 1 pF (which is effectively two 2 pF capacitors in series) all the way to 15 pF (30 pF capacitors in series). These values are obtained by combining the enabled capacitors. The values available are 2 pF, 4 pF, 8 pF and 16 pF. Any combination between these four can be done. It is recommended that these internal capacitors are disabled if the external capacitors are available. Figure 1. External capacitors for the 32 kHz crystal 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: 1. Since the RTC module is going to be used to output the oscillator frequency, the RTC_CLKOUT will be the output signal. The output pin for RTC_CLKOUT is PTB3. To configure PTB3 as the oscillator output use the function configure_rtc_pins(RTC instance). Port B clock must be enabled first. Figure 2. PTB3 pin mux   /* hardware_init.c */     /* enable clock for PORTs */   CLOCK_SYS_EnablePortClock(PORTA_IDX);   CLOCK_SYS_EnablePortClock(PORTB_IDX);   CLOCK_SYS_EnablePortClock(PORTC_IDX);   /* RTC CLKOUT */   configure_rtc_pins(0);     //This function changes the pin mux to select RTC_CLKOUT. It is included in the pin_mux.c file. 2.  Modify the System Options Register 1 (SIM_SOPT1) to select the clock source and to allow the selected clock source to be output in PTB3. The field you should change is OSC32KOUT. To select the clock source to be output on PTB3, use the function CLOCK_HAL_SetExternalRefClock32kSrc(). Remember to include the fsl_sim_hal.h file. Figure 3. SIM_SOPT1 register fields /* hardware_init.c */ /* RTC CLKOUT */ configure_rtc_pins(0); SIM_Type *simBase = g_simBase[0];     SIM_SOPT1 = SIM_SOPT1_OSC32KOUT(kClockRtcoutSrc32kHz);                // This field in register SIM_SOPT1 allows a clock source to be output to PTB3 CLOCK_HAL_SetExternalRefClock32kSrc(simBase, kClockEr32kSrcOsc0);     // This function chooses the clock source for the RTC 3.  Make sure the oscillator is enabled. The RTC external clock configurations can be found in the board.h file. This is also where the internal capacitors are enabled. /* board.h */ /* RTC external clock configuration. */ #define RTC_XTAL_FREQ                32768U #define RTC_SC2P_ENABLE_CONFIG       false      // 2 pF capacitors enable #define RTC_SC4P_ENABLE_CONFIG       false      // 4 pF capacitors enable #define RTC_SC8P_ENABLE_CONFIG       false      // 8 pF capacitors enable #define RTC_SC16P_ENABLE_CONFIG      false      // 16 pF capacitors enable #define RTC_OSC_ENABLE_CONFIG        true       // Oscillator enable 4.  You should now be able to measure the oscillator frequency through the PTB3 pin. Measurements should be done with a frequency counter, as change in the output can be very subtle, and an oscilloscope might not be able to pick it up. Remember that these capacitors give you the option to use the 32 kHz oscillator when you do not have the external capacitors. They are not supposed to be used when the external capacitors are being used. Now, to change the internal capacitance, you can simply change the macros contained in the board.h file (step 4). It is important that the oscillator is disabled before making any changes to the enabled capacitors. The fsl_clock_manager.c file already contains the function CLOCK_SYS_RtcOscInit() that configures the oscillator with the values established in the previously mentioned macros, however, the oscillator is not disabled before attempting to change the capacitors (and therefore, no changes are made). To fix this, you can use the RTC_HAL_SetOscillatorCmd() function to disable the oscillator before making changes with the capacitors. /* fsl_clock_manager.c */     // Disable the oscillator in case any changes are made to the capacitors RTC_HAL_SetOscillatorCmd(RTC, false);     // If the oscillator is not enabled and should be enabled. if ((!RTC_HAL_IsOscillatorEnabled(RTC)) && (config->enableOsc)) {     /* Enable the desired capacitors */     RTC_HAL_SetOsc2pfLoadCmd(RTC, config->enableCapacitor2p);     RTC_HAL_SetOsc4pfLoadCmd(RTC, config->enableCapacitor4p);     RTC_HAL_SetOsc8pfLoadCmd(RTC, config->enableCapacitor8p);     RTC_HAL_SetOsc16pfLoadCmd(RTC, config->enableCapacitor16p);         /* Re-enable the oscillator */     RTC_HAL_SetOscillatorCmd(RTC, config->enableOsc); } The fsl_clock_manager.c file can be found in: <KW40Z_connSw_install_dir>\KSDK_1.3.0\platform\system\src\clock Some reference measurements with different values for the internal capacitance: With external capacitors (internal capacitors disabled) Board Revision C LOAD Measured Frequency KW40Z – rev. C C46 & C47 32,769.03 Hz KW40Z – rev. B C46 & C47 32,769.27 Hz With internal capacitors (external capacitors removed) Enabled Capacitors C LOAD Measured Frequency SC2P 1 pF 32,773.21 Hz SC4P 2 pF 32,772.06 Hz SC2P, SC4P 3 pF 32,771.2 Hz SC4P, SC8P 6 pF 32,769.39 Hz SC2P, SC4P, SC8P 7 pF 32,769 Hz SC16P 8 pF 32,768.6 Hz SC2P, SC16P 9 pF 32,768.31 Hz SC4P, SC16P 10 pF 32,768.05 Hz SC2P, SC4P, SC16P 11 pF 32,767.83 Hz SC4P, SC8P, SC16P 14 pF 32,767.27 Hz SC2P, SC4P, SC8P, SC16P 15 pF 32,767.11 Hz 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 before 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.

Hello All, I designed a ultra low low cost evaluation board (ULC-Zigbee) based in Kinetis wireless MCUs, take a look at the attached PDF for the brief description.  I was able to build three of them at ~$10USD each. The ULC-Zigbee is covered under the GNU General Public License. The required files to build the board are attached, it measures 30 x 50mm. My partner AngelC   wrote a sample code. The software basically communicates wirelessly the ULC-Zigbee board with a USB-KW24D512. An FXOS8700 is externally connected through the prototype board connector and the magnetic and acceleration values are then wirelessly transmitted to the USB stick, then the values can be printed in a HyperTerminal. The attached zip file contains the following files: File name Description ULC-Zigbee-EBV_V10.pdf Brief description of the ULC-Zigbee board MKW2x_Eagle_library.lbr  Required EAGLE CADSOFT LIBRARY ULC-Zigbee-EBV_V10.brd EAGLE v6.5 Board ULC-Zigbee-EBV_V10.sch EAGLE v6.5 Schematic ULC-Zigbee-EBV_V10_SCH.pdf ULC-Zigbee board schematic ULC-Zigbee-EBV_V10_BOM.xlsx Bill of materials ULC-Zigbee-EBV_V10_GERBER_FILES.zip Gerber files WirelessUART_MKW2x_v1.3_eCompass_TX_v1.zip ULC-Zigbee board sample software WirelessUART_MKW2x_v1.3_eCompass_RX_v1.zip USB-KW24D512 sample software     Hope it helps!   -Josh   Este documento fue generado desde la siguiente discusión:Ultra Low Cost Zigbee Evaluation Board

This post explains the implementation to operate the KW36 MCU on VLPR when the clocking mode is BLPE or BLPI. It's also included the explanation on how to configure clocks for BLPE and BLPI modes. For this example, the beacon demo from the wireless examples of the FRDM-KW36 is used. FRDM-KW36 SDK can be downloaded from MCUXpresso webpage. A recommended option to configure clock modes is "Config Tools" from MCUXpresso. Config Tools is embedded to MCUXpresso IDE, or you can download Config Tools from this LINK if you are using other supported IDE for this tool. MCUXpresso IDE is used in this example. Configure BLPE or BLPI clocking modes Select your proyect on MCUXpresso IDE, then open the clocks configuration window from Config Tools by clicking the arrow next to Config Tools icon from your MCUXpresso IDE, and then select "Open Clocks" as shown in Figure 1. Figure 1. Open Clocks from Config Tools using MCUXpresso IDE. A clocks diagram window will be opened. To configure the clock modes just select your option "BLPI" or "BLPE" on MCG Mode as shown in Figure 2. Clock will be automatically configured. Figure 2. MCG Mode selection. Now let's configure the appropiate clocks for Core clock and Bus clock to run in VLPR. Figure 3 taken from KW36 Reference Manual shows achievables frequencies when MCU is on VLPR.  Figure 3. VLPR clocks. Core clock should be 4MHz for BLPE and BLPI clocking modes, and Bus clock should be 1MHz for BLPE and 800kHz for BLPI.  Figure 4 shows clocks distribution for BLPE and Figure 5 for BLPI to operate with discussed frequencies. Figure 4. Clock distribution - VLPR and BLPE. Figure 5. Clock distribution - VLPR and BLPI. Press "Update Project" (Figure 6) to apply your new clock configuration to your firmware, then change perspective to "Develop" icon on right corner up to go to your project (See Figure 7). Compile your project to apply the changes. Figure 6. Update Project button. Figure 7. Develop button. At this point your project is ready to work with BLPE or BLPI clocks modes. Now, let's configure MCU to go to VLPR power mode. Configure VLPR mode VLPR mode can be configured using Config Tools too, but you may have an error trying to configure it when BLPE mode, this is because CLKDIV1 register cannot be written when the device is on VLPR mode. For this example, let's configure MCU into VLPR mode by firmware. Follow next steps to configure KW36 into VLPR power mode: 1. Configure RF Ref Oscillator to operate in VLPR mode. By default, the RF Ref Osc it's configured to operate into RUN mode. To change it to operate on VLPR mode just change the bits RF_OSC_EN from Radio System Control from 1 (RUN) to 7 (VLPR). Figure 8 taken from KW36 Reference Manual shows RF_OSC_EN value options from Radio System Control.    Figure 8. RF_OSC_EN bits from Radio System Control register. Go to clock_config.c file in your MCUXpresso project and search for "BOARD_RfOscInit" function. Change the code line as shown in Figure 9 to configure RF Ref Osc to work into VLPR mode. You may see a window asking if you want to make writable the read-only file, click Yes. Figure 9. Code line to configure RF Ref Osc to work into VLPR mode Be aware that code line shown in Figure 9 may change with updates done in clocks using Config Tools. Note 2. Configure DCDC in continuous mode. According to KW36 Reference Manual, the use of BLPE in VLPR mode is only feasible when the DCDC is configured for continuous mode. First, let's define gDCDC_Enabled_d flag to 1 on preprocesor. With this implementation, the use of DCDC_Init function will be enabled, and it's where we going to add the code line to enable continuous mode. Right click on your project, select Properties, go to Settings under C/C++ Build, then Preprocessor under MCU C Compiler (Figure 10).   Figure 10. MCUXpresso Preprocessor   Click on add button from Defined symbols, write gDCDC_Enabled_d=1 and click OK to finish (Figure 11).  Re-compile your project. Figure 11. MCUXpresso Defined symbols   Now let's set VLPR_VLPW_CONFIG_DCDC_HP bits to 1 from DCDC_REG0 register. Figure 12 was taken from KW36 Reference Manual. Figure 12. VLPR_VLPW_CONFIG_DCDC_HP values. Go to DCDC_Init  function and add the next code line to enable continuous mode on DCDC: DCDC->REG0 |= DCDC_REG0_VLPR_VLPW_CONFIG_DCDC_HP_MASK; Figure 13 shows the previous code line implemented in firmware project inside of DCDC_Init function. Figure 13. Continuous mode for DCDC enabled. 3. Configure MCU into VLPR mode To finish, let's write the code to configure MCU into VLPR power mode. Copy and paste next code just after doing implementation described on step 1 and 2: #if (defined(FSL_FEATURE_SMC_HAS_LPWUI) && FSL_FEATURE_SMC_HAS_LPWUI) SMC_SetPowerModeVlpr(SMC, false); #else SMC_SetPowerModeVlpr(SMC); #endif while (kSMC_PowerStateVlpr != SMC_GetPowerModeState(SMC)) { } It may be needed to add the SMC library: #include "fsl_smc.h" The code is configuring MCU into VLPR mode with bits RUNM from SMC_PMCTRL register (Figure 14) and then check if it was correctly configured by reading status bits PMSTAT from SMC_PMSTAT register (Figure 15) Figure 14. RUNM bits from SMC_PMCTRL register. Figure 15. PMSTAT bits from  SMC_PMSTAT register. KW36 is ready to operate and BLPE or BLPI clocking modes with VLPR power mode.

The KW41Z has support for an external 26 MHz or 32 MHz reference oscillator. This oscillator is used, among other things, as the clock for the RF operation. This means that the oscillator plays an important role in the RF operation and must be tuned properly to meet wireless protocol standards. The KW41Z has adjustable internal load capacitors to support crystals with different load capacitance needs. For proper oscillator function, it is important that these load capacitors be adjusted such that the oscillator frequency is as close to the center frequency of the connected crystal (either 26 MHz or 32 MHz in this case). The load capacitance is adjusted via the BB_XTAL_TRIM bit field in the ANA_TRIM register of the Radio block. The KW41Z comes preprogrammed with a default load capacitance value. However, since there is variance in devices due to device tolerances, the correct load capacitance should be verified by verifying that the optimal central frequency is attained.  You will need a spectrum analyzer to verify the central frequency. To find the most accurate value for the load capacitance, it is recommended to use the Connectivity Test demo application. This post is aimed at showing you just how to do that.   In this case, the Agilent Technologies N9020A MXA Signal Analyzer was used to measure, configured with the following parameters: FREQ (central frequency): 2405 MHz (test will be conducted on channel 11) SPAN (x-axis): 100 KHz AMPTD (amplitude, y-axis): 5 dBm To perform the test, program the KW41Z with the Connectivity Test application. The project, for both IAR and KDS, for this demo application can be found in the following folder: <KW41Z_connSw_1.0.2_install_dir>\boards\frdmkw41z\wireless_examples\smac\connectivity_test\FreeRTOS NOTE:  If you need help programming this application onto your board, consult your Getting Started material for the SMAC applications.  For the FRDM-KW41Z, it is located here. Once the device is programmed, make sure the device is connected to a terminal application in your PC. When you start the application, you're greeted by this screen: Press 'ENTER' to start the application. Press '1' to select the continuous tests mode. Press '4' to start a continuous unmodulated transmission. Once the test is running, you should be able to see the unmodulated signal in the spectrum analyzer. Press 'd' and 'f' to change the XTAL trim value, thus changing the central frequency. Now, considering the test in this example is being performed in 802.15.4 channel 11, the central frequency should be centered exactly in 2.405 GHz, but on this board, it is slightly above (2.4050259 GHz) by default. In order to fix this, the XTAL trim value was adjusted to a value that moves the frequency to where it should be centered. Once the adequate XTAL trim value is found, it can be programmed to be used by default. This other post explains how to do this process.

Commissioner Authentication server for new Thread devices and the authorizer for providing the network credentials they require to join the network. A device capable of being elected as a Commissioner is called a Commissioner Candidate. Devices without Thread interfaces may perform this role, but those that have them may combine this role with all other roles except the Joiner. This device may be, for example, a cell phone or a server in the cloud, and typically provides the interface by which a human administrator manages joining a new device to the Thread Network. Commissioner Candidate A device that is capable of becoming the Commissioner, and either intends or is currently petitioning the Leader to become the Commissioner, but has not yet been formally assigned the role of Commissioner. Commissioner Credential A human-scaled passphrase for use in authenticating that a device may petition to become the commissioner of the network. This credential can be thought of as the network administrator password for a Thread Network. The first device in a network, typically the initial Leader, MUST be out-of-band commissioned to inject the correct user generated Commissioning Credential into the Thread Network, or provide a known default Commissioning Credential to be changed later. Joiner A device to be added by a human administrator to a commissioned Thread Network. This role requires a Thread interface to perform and cannot be combined with another role in one device. The Joiner does not have network credentials. Joiner Router An existing Thread router or REED (Router-Eligible End Device) on the secure Thread Network that is one radio hop away from the Joiner. The Joiner Router requires a Thread interface to operate, and may be combined in any device with other roles except the Joiner role. Information extracted from the Thread Whitepapers available at threadgroup.org

In this document we will be seeing how to create a BLE demo application for an adopted BLE profile based on another demo application with a different profile. In this demo, the Pulse Oximeter Profile will be implemented.  The PLX (Pulse Oximeter) Profile was adopted by the Bluetooth SIG on 14th of July 2015. You can download the adopted profile and services specifications on https://www.bluetooth.org/en-us/specification/adopted-specifications. The files that will be modified in this post are, app.c,  app_config.c, app_preinclude.h, gatt_db.h, pulse_oximeter_service.c and pulse_oximeter_interface.h. A profile can have many services, the specification for the PLX profile defines which services need to be instantiated. The following table shows the Sensor Service Requirements. Service Sensor Pulse Oximeter Service Mandatory Device Information Service Mandatory Current Time Service Optional Bond Management Service Optional Battery Service Optional Table 1. Sensor Service Requirements For this demo we will instantiate the PLX service, the Device Information Service and the Battery Service. Each service has a source file and an interface file, the device information and battery services are already implemented, so we will only need to create the pulse_oximeter_interface.h file and the pulse_oximeter_service.c file. The PLX Service also has some requirements, these can be seen in the PLX service specification. The characteristic requirements for this service are shown in the table below. Characteristic Name Requirement Mandatory Properties Security Permissions PLX Spot-check Measurement C1 Indicate None PLX Continuous Measurement C1 Notify None PLX Features Mandatory Read None Record Access Control Point C2 Indicate, Write None Table 2. Pulse Oximeter Service Characteristics C1: Mandatory to support at least one of these characteristics. C2: Mandatory if measurement storage is supported for Spot-check measurements. For this demo, all the characteristics will be supported. Create a folder for the pulse oximeter service in  \ConnSw\bluetooth\profiles named pulse_oximeter and create the pulse_oximeter_service.c file. Next, go to the interface folder in \ConnSw\bluetooth\profiles and create the pulse_oximeter_interface.h file. At this point these files will be blank, but as we advance in the document we will be adding the service implementation and the interface macros and declarations. Clonate a BLE project with the cloner tool. For this demo the heart rate sensor project was clonated. You can choose an RTOS between bare metal or FreeRTOS. You will need to change some workspace configuration.  In the bluetooth->profiles->interface group, remove the interface file for the heart rate service and add the interface file that we just created. Rename the group named heart_rate in the bluetooth->profiles group to pulse_oximeter and remove the heart rate service source file and add the pulse_oximeter_service.c source file. These changes will be saved on the actual workspace, so if you change your RTOS you need to reconfigure your workspace. To change the device name that will be advertised you have to change the advertising structure located in app_config.h. /* Scanning and Advertising Data */ static const uint8_t adData0[1] =  { (gapAdTypeFlags_t)(gLeGeneralDiscoverableMode_c | gBrEdrNotSupported_c) }; static const uint8_t adData1[2] = { UuidArray(gBleSig_PulseOximeterService_d)}; static const gapAdStructure_t advScanStruct[] = { { .length = NumberOfElements(adData0) + 1, .adType = gAdFlags_c, .aData = (void *)adData0 }, { .length = NumberOfElements(adData1) + 1, .adType = gAdIncomplete16bitServiceList_c, .aData = (void *)adData1 }, { .adType = gAdShortenedLocalName_c, .length = 8, .aData = "FSL_PLX" } }; We also need to change the address of the device so we do not have conflicts with another device with the same address. The definition for the address is located in app_preinclude.h and is called BD_ADDR. In the demo it was changed to: #define BD_ADDR 0xBE,0x00,0x00,0x9F,0x04,0x00 Add the definitions in ble_sig_defines.h located in Bluetooth->host->interface for the UUID’s of the PLX service and its characteristics. /*! Pulse Oximeter Service UUID */ #define gBleSig_PulseOximeterService_d         0x1822 /*! PLX Spot-Check Measurement Characteristic UUID */ #define gBleSig_PLXSpotCheckMeasurement_d      0x2A5E /*! PLX Continuous Measurement Characteristic UUID */ #define gBleSig_PLXContinuousMeasurement_d     0x2A5F /*! PLX Features Characteristic UUID */ #define gBleSig_PLXFeatures_d                  0x2A60 /*! Record Access Control Point Characteristic UUID */ #define gBleSig_RecordAccessControlPoint_d     0x2A52 We need to create the GATT database for the pulse oximeter service. The requirements for the service can be found in the PLX Service specification. The database is created at compile time and is defined in the gatt_db.h.  Each characteristic can have certain properties such as read, write, notify, indicate, etc. We will modify the existing database according to our needs. The database for the pulse oximeter service should look something like this. PRIMARY_SERVICE(service_pulse_oximeter, gBleSig_PulseOximeterService_d)     CHARACTERISTIC(char_plx_spotcheck_measurement, gBleSig_PLXSpotCheckMeasurement_d, (gGattCharPropIndicate_c))         VALUE_VARLEN(value_PLX_spotcheck_measurement, gBleSig_PLXSpotCheckMeasurement_d, (gPermissionNone_c), 19, 3, 0x00, 0x00, 0x00)         CCCD(cccd_PLX_spotcheck_measurement)     CHARACTERISTIC(char_plx_continuous_measurement, gBleSig_PLXContinuousMeasurement_d, (gGattCharPropNotify_c))         VALUE_VARLEN(value_PLX_continuous_measurement, gBleSig_PLXContinuousMeasurement_d, (gPermissionNone_c), 20, 3, 0x00, 0x00, 0x00)         CCCD(cccd_PLX_continuous_measurement)     CHARACTERISTIC(char_plx_features, gBleSig_PLXFeatures_d, (gGattCharPropRead_c))         VALUE_VARLEN(value_plx_features, gBleSig_PLXFeatures_d, (gPermissionFlagReadable_c), 7, 2, 0x00, 0x00)     CHARACTERISTIC(char_RACP, gBleSig_RecordAccessControlPoint_d, (gGattCharPropIndicate_c | gGattCharPropWrite_c))         VALUE_VARLEN(value_RACP, gBleSig_RecordAccessControlPoint_d, (gPermissionNone_c), 4, 3, 0x00, 0x00, 0x00)         CCCD(cccd_RACP) For more information on how to create a GATT database you can check the BLE Application Developer’s Guide chapter 7. Now we need to make the interface file that contains all the macros and declarations of the structures needed by the PLX service. Enumerated types need to be created for each of the flags field or status field of every characteristic of the service. For example, the PLX Spot-check measurement field has a flags field, so we declare an enumerated type that will help us keep the program organized and well structured. The enum should look something like this: /*! Pulse Oximeter Service - PLX Spotcheck Measurement Flags */ typedef enum {     gPlx_TimestampPresent_c                      = BIT0,     /* C1 */     gPlx_SpotcheckMeasurementStatusPresent_c     = BIT1,     /* C2 */     gPlx_SpotcheckDeviceAndSensorStatusPresent_c = BIT2,     /* C3 */     gPlx_SpotcheckPulseAmplitudeIndexPresent_c   = BIT3,     /* C4 */     gPlx_DeviceClockNotSet_c                     = BIT4 } plxSpotcheckMeasurementFlags_tag; The characteristics that will be indicated or notified need to have a structure type that contains all the fields that need to be transmitted to the client. Some characteristics will not always notify or indicate the same fields, this varies depending on the flags field and the requirements for each field. In order to notify a characteristic we need to check the flags in the measurement structure to know which fields need to be transmitted. The structure for the PLX Spot-check measurement should look something like this: /*! Pulse Oximeter Service - Spotcheck Measurement */ typedef struct plxSpotcheckMeasurement_tag {     ctsDateTime_t              timestamp;             /* C1 */     plxSpO2PR_t                SpO2PRSpotcheck;       /* M */     uint32_t                   deviceAndSensorStatus; /* C3 */     uint16_t                   measurementStatus;     /* C2 */     ieee11073_16BitFloat_t     pulseAmplitudeIndex;   /* C4 */     uint8_t                    flags;                 /* M */ }plxSpotcheckMeasurement_t; The service has a configuration structure that contains the service handle, the initial features of the PLX Features characteristic and a pointer to an allocated space in memory to store spot-check measurements. The interface will also declare some functions such as Start, Stop, Subscribe, Unsubscribe, Record Measurements and the control point handler. /*! Pulse Oximeter Service - Configuration */ typedef struct plxConfig_tag {     uint16_t      serviceHandle;     plxFeatures_t plxFeatureFlags;     plxUserData_t *pUserData;     bool_t        procInProgress; } plxConfig_t; The service source file implements the service specific functionality. For example, in the PLX service, there are functions to record the different types of measurements, store a spot-check measurement in the database, execute a procedure for the RACP characteristic, validate a RACP procedure, etc. It implements the functions declared in the interface and some static functions that are needed to perform service specific tasks. To initialize the service you use the start function. This function initializes some characteristic values. In the PLX profile, the Features characteristic is initialized and a timer is allocated to indicate the spot-check measurements periodically when the Report Stored Records procedure is written to the RACP characteristic. The subscribe and unsubscribe functions are used to update the device identification when a device is connected to the server or disconnected. bleResult_t Plx_Start (plxConfig_t *pServiceConfig) {         mReportTimerId = TMR_AllocateTimer();         return Plx_SetPLXFeatures(pServiceConfig->serviceHandle, pServiceConfig->plxFeatureFlags); } All of the services implementations follow a similar template, each service can have certain characteristics that need to implement its own custom functions. In the case of the PLX service, the Record Access Control Point characteristic will need many functions to provide the full functionality of this characteristic. It needs a control point handler, a function for each of the possible procedures, a function to validate the procedures, etc. When the application makes a measurement it must fill the corresponding structure and call a function that will write the attribute in the database with the correct fields and then send an indication or notification. This function is called RecordMeasurement and is similar between the majority of the services. It receives the measurement structure and depending on the flags of the measurement, it writes the attribute in the GATT database in the correct format. One way to update a characteristic is to create an array of the maximum length of the characteristic and check which fields need to be added and keep an index to know how many bytes will be written to the characteristic by using the function GattDb_WriteAttribute(handle, index, &charValue[0]). The following function shows an example of how a characteristic can be updated. In the demo the function contains more fields, but the logic is the same. static bleResult_t Plx_UpdatePLXContinuousMeasurementCharacteristic ( uint16_t handle, plxContinuousMeasurement_t *pMeasurement ) {     uint8_t charValue[20];     uint8_t index = 0;     /* Add flags */     charValue[0] = pMeasurement->flags;     index++;     /* Add SpO2PR-Normal */     FLib_MemCpy(&charValue[index], &pMeasurement->SpO2PRNormal, sizeof(plxSpO2PR_t));     index += sizeof(plxSpO2PR_t);         /* Add SpO2PR-Fast */     if (pMeasurement->flags & gPlx_SpO2PRFastPresent_c)     {       FLib_MemCpy(&charValue[index], &pMeasurement->SpO2PRFast, sizeof(plxSpO2PR_t));       index += sizeof(plxSpO2PR_t);     }        return GattDb_WriteAttribute(handle, index, &charValue[0]); } The app.c handles the application specific functionality. In the PLX demo it handles the timer callback to make a PLX continuous measurement every second. It handles the key presses and makes a spot-check measurement each time the SW3 pushbutton is pressed. The GATT server callback receives an event when an attribute is written, and in our application the RACP characteristic is the only one that can be written by the client. When this event occurs, we call the Control Point Handler function. This function makes sure the indications are properly configured and check if another procedure is in progress. Then it calls the Send Procedure Response function, this function validates the procedure and calls the Execute Procedure function. This function will call one of the 4 possible procedures. It can call Report Stored Records, Report Number of Stored Records, Abort Operation or Delete Stored Records. When the project is running, the 4 LEDs will blink indicating an idle state. To start advertising, press the SW4 button and the LED1 will start flashing. When the device has connected to a client the LED1 will stop flashing and turn on. To disconnect the device, hold the SW4 button for some seconds. The device will return to an advertising state. In this demo, the spot-check measurement is made when the SW3 is pressed, and the continuous measurement is made every second. The spot-check measurement can be stored by the application if the Measurement Storage for spot-check measurements is supported (bit 2 of Supported Features Field in the PLX Features characteristic). The RACP characteristic lets the client control the database of the spot-check measurements, you can request the existing records, delete them, request the number of stored records or abort a procedure. To test the demo you can download and install the nRF Master Control application by Nordic Semiconductor on an Android Smartphone that supports BLE. This app lets you discover the services in the sensor and interact with each characteristic. The application will parse known characteristics, but because the PLX profile is relatively new, these characteristics will not be parsed and the values will be displayed in a raw format. Figure 1. nRF Master Control app

Bluetooth® Low-Energy (BLE) RF PHY tests can be done by using the Direct Test Mode (DTM).  This document will help as a guide to perform the test using a device from the KW family.     Direct Test Mode Direct Test Mode (DTM) is used to control the Device Under Test (DUT) and provides a report with the results from the tests performed by the Tester.   There are two ways to perform those tests:   HCI Through a 2-wire UART interface   The packet format from the DTM is different from the HCI commands.   For further information of the commands and this type of tests, please refer to the Bluetooth Core Specifications, Vol 6, Part F: Direct Test Mode   Software This guide will use the KW41Z as example, but the same changes must be applicable for the rest of the devices Download and install the software SDK of the device to use by following the getting started in the device page. In this case the SDK of the KW41Z will be downloaded from the MCUXpresso Builder. Setup for DTM using HCI Import the hci_black_box example to the IDE according to the getting started of the device.   Download and open the latest version of the Test Tool available in the page of the device under Lab & Test Software in the Software and Tools Tab. Open the Command console of the board, please be sure that you have the correct baud rate set for the example (Default: 115200) Select one of the available commands to either start or finish tests    Setup for DTM using DTM pins You can choose from any example available while making sure that the pins chosen for DTM  are not occupied or used. Import the beacon example to the IDE according to the getting started of the device.   The DTM pins behave as a UART interface; in order to enable them in our KW devices there is the need to follow the next steps Look at the Reference manual of the device and locate the pins that support the DTM_TX and the DTM_RX. In this case, we will select the PTB1 and PTB2.  Set the ALT_MUX of the pin in the code to work as DTM   PORT_SetPinMux(PORTB, PIN1_IDX, kPORT_MuxAlt2);            /* PORTB1 (pin 17) is configured as DTM_RX */   PORT_SetPinMux(PORTB, PIN2_IDX, kPORT_MuxAlt3);            /* PORTB2 (pin 18) is configured as DTM_TX */‍‍‍‍‍‍‍‍‍‍ Configure the baud rate of the DTM pins, this can be achieved by writing to the DTM_2WIRE_CONFIG register. This register is not available in the header file by default, so there is the need to create a pointer to such address. To verify this data, you can check the chapter 45.2.3.1.4 Test and Debug Registers Descriptions for the Bluetooth Link Layer of the reference manual. #define DTM_2WIRE_CONFIG                0x580 #define BTLE_RF_DTM_2WIRE_CONFIG        (*(volatile uint16_t *) (BTLE_RF_BASE+DTM_2WIRE_CONFIG)) BTLE_RF_DTM_2WIRE_CONFIG = 0x0042;  /*Configure DTM pins baud rate of 115200*/‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Bluetooth Low Energy is a standard for Low Power Wireless Networks introduced in the Bluetooth specification 4.0. Its target application domains include medical, sports & fitness, home automation and others. The adoption and development rates of this technology are growing fast helped by the wide availability of hardware support in most modern mobile phones and mobile operating systems. The purpose of this application note is to show how the Freescale FRDM-KW40Z can board with BLE Controller software can be used with the hcitool from the Linux Bluetooth stack over the HCI interface. 1. Introduction The Bluetooth specification has a very well defined interface between the Controller and the Host called the HCI (Host Controller Interface). This interface is defined for and can be used with various transport layers including an asynchronous serial transport layer. A typical scenario of Bluetooth Low Energy hardware use is a development board which has a BLE Controller accessible via serial transport HCI connected to a device on which the BLE Host runs. The device which runs the BLE Host can be any type of embedded device or a PC. PCs running a Linux type OS can use the hcitool from the Linux Bluetooth Stack to interact with a BLE Controller via the HCI interface. The particular use case of  FRDM-KW40Z board with a serial transport HCI interface running over USB CDC and connected to a PC running the Linux Bluetooth stack is shown in the diagram below and will be detailed din the following sections. Figure 1FRDM-KW40Z (BLE Controller) connected to Linux PC (Bluetooth Host Stack) via HCI Serial Transport 2. Loading the HCI Application onto the FRDM-KW40Z First load the hci_app on the FRDM-KW40Z board. The hci_app aplication can be found in the <ConnectivitySwInstallationPath>\ConnSw\examples\bluetooth\hci_app folder. 3. Connecting the FRDM-KW40Z to the Computer via a Serial Port After the app is downloaded to the board plug the board into a free USB port of your Linux computer. The following instructions, commands and their output is typical to a Debian based Linux OS. After the board is plugged in run the following command to list the serial ports available. >> dmesg | grep tty [ 0.000000] console [tty0] enabled [ 2374.118201] cdc_acm 1-2:1.1: ttyACM0: USB ACM device In our example the FRDM-KW40Z board serial port is ttyACM0. To test the connection some HCI commands can be sent in hex format from any terminal application to the serial HCI on the FRDM-KW40Z board. In the figure below an HCI_Read_BD_ADDR command and its corresponding Command Complete Event are shown as they were sent and received in hexadecimal format from the moserial serial terminal GUI application. Figure 2: HCI command and response event in hexadecimal format (HCI UART Transport) 4. Connecting the HCI Serial Interface to the Bluetooth Stack To connect the Linux Bluetooth stack to a serial HCI interface the hciattach command must be run as shown below. >> hciattach /dev/ttyACM0 any 115200 noflow nosleep Device setup complete If the the HCI serial interface is successfully attached to the Bluetooth stack then the "Device setup complete" message is shown. The any parameter specifies a generic Bluetooth device. The 115200 parameter is the UART baudrate. The noflow parameter diasables serial flow control. The nosleep parameter disables hardware specific power managment. Run the hciconfig command with no parameters to check the HCI interface id of the newly attached HCI serial device. >> hciconfig hci1:    Type: BR/EDR  Bus: UART     BD Address: 00:04:9F:00:00:15  ACL MTU: 27:4 SCO MTU: 0:0     UP RUNNING     RX bytes:205 acl:0 sco:0 events:14 errors:0     TX bytes:112 acl:0 sco:0 commands:14 errors:0 hci0:    Type: BR/EDR  Bus: USB     BD Address: 90:00:4E:A4:70:97  ACL MTU: 310:10  SCO MTU: 64:8     UP RUNNING     RX bytes:595 acl:0 sco:0 events:37 errors:0     TX bytes:2564 acl:0 sco:0 commands:36 errors:0 In this example the FRDM-KW40Z is assigned the hci1 interface as can be seen from the bus type (Type: BR/EDR  Bus: UART). The hci0 interface is the example shown corresponds to the on-board Bluetooth module from the machine. On some systems the interface might need to be manually started by using the hciconfig interfaceId up command. hciconfig hci1 up 5. Configuring the Bluetooth Device and Listing its Capabilities The hciconfig command offers the possibility of configuring the device and listing the device capabilities. To find all commands supported by the hciconfig tool type the following command. >> hciconfig –h ...display supported commands... Each individual hciconfig command must be addressed to the correct HCI interface as reported above. In our example we use the hci1 interface. Some hciconfig commands require root privileges and must be run with sudo (the "Operation not permitted(1)" error will be returned if a command needs to be run with root privileges). Some useful hci config commands: >> hciconfig hci1 version    -> lists hci device verison information >> hciconfig hci1 revision    -> lists hci device revision information >> hciconfig hci1 features    -> lists the features supported by the device >> hciconfig hci1 commands    -> lists the hci commands supported by the device >> sudo hciconfig hci1 lestates    -> lists the BLE states supported by the device >> sudo hciconfig hci1 lerandaddr 11:22:33:44:55:66    -> set a random address on the device >> sudo hciconfig hci1 leadv 3    -> enable LE advertising of the specified type >> sudo hciconfig hci1 noleadv    -> disable LE advertising Now the newly connected board with a serial HCI is attached to a HCI interface of the Bluetooth stack and is ready to use. 6.    Controlling the Bluetooth Device using the hcitool The hcitool can be used to send HCI commands to the Bluetooth device. A command is available which lists all available hcitool actions. >> hcitool -h ...display supported commands... To target a specific HCI interface use the -i hciX option for an hcitool command. We will use -i hci1 in our examples. The hcitool supports commands for common BLE HCI operations some of which are shown below and also supports sending generic HCI commands using a dedicated option which uses hexadecimal numbers for the OGF (Command Group), OCF (Command Code) and the parameters. The 6 bit OGF and the 10 bit OCF compose the 16 bit HCI Command Opcode. The command parameters are specific to each command. 6.1.  Listing Devices Available to the hcitool An hcitool command can list all available device interfaces. >> hcitool dev Devices: hci1    00:04:9F:00:00:15 hci0    90:00:4E:A4:70:97 The device we are working with is connected to the hci1 interface as seen from the output of the hciconfig command used above. 6.2.  Scanning for Advertising LE Devices The hcitool can be used to perform a LE Device scan. This command requires root privileges. Press Ctrl+C to stop the scan at any time. >> sudo hcitool -i hci1 lescan LE Scan ... 00:04:9F:00:00:13 (FSL_OTAC) ^C A list of addresses and device names will be shown if advertised (<<Shortened Local Name>> or <<Complete Local Name>> as define din the specification). 6.3.  Obtaining Remote LE Device Information Using the hcitool To obtain information about a remote LE device a special hcitool command can be used. The hcitool leinfo command creates a connection, extracts information from the remote device and then disconnects. The remote device information is shown at the command prompt. >> sudo hcitool -i hci1 leinfo 00:04:9F:00:00:13 Requesting information ...        Handle: 32 (0x0020)        LMP Version: 4.1 (0x7) LMP Subversion: 0x113        Manufacturer: Freescale Semiconductor, Inc. (511)        Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 In this example information about a device previously discovered using the hcitool lescan command is shown. 6.4.  Connecting and Disconnecting from a Remote LE Device Connecting to a remote LE device is done using the hcitool lecc command. >> sudo hcitool -i hci1 lecc 00:04:9F:00:00:13 Connection handle 32 As before a previously discovered device address is used. If the connection is successful then the Connection Handle is returned and in our case the Connection Handle is 32. The hcitool con command shows active connections information: address, connection handle, role, etc. >> hcitool con Connections: < LE 00:04:9F:00:00:13 handle 32 state 1 lm MASTER To end a LE connection the hcitool ledc command can be used. It must be provided with the Connection Handle to be terminated, and optionally the reason. The device handle obtained after the connection and shown in the connected devices list is used. >> hcitool –I hci1 ledc 32 >> Listing the connections after all connections are terminated will show an empty connection list. >> hcitool con Connections: >> 6.5.  Sending Arbitrary HCI Commands To send arbitrary HCI commands to a device using the Command CopCode (OGF and OCF) the hcitool cmd command can be used. As an example the HCI_Read_BD_ADDR command is used which has the 0x1009 OpCode (OGF=0x04, OCF=0x009) and no parameters. It is the same command shown in the direct serial port to HCI communication example above. hcitool -i hci0 cmd 0x04 0x0009 < HCI Command: ogf 0x04, ocf 0x0009, plen 0 > HCI Event: 0x0e plen 10   01 09 10 00 15 00 00 9F 04 00 The OpCode OGF (0x04) and OCF (0x009) and no parameters are passed to the hcitool cmd command all in hexadecimal format. The parameters length (plen) is 0 for the command. The response is a Command Complete event (0x03) with the parameters length (plen) 10. The parameters are 01 09 10 00 15 00 00 9F 04 00: 01 is the Num_HCI_Command_Packets parameter 09 10 is the Command OpCode for which this Command Complete Event is returned (in little endian format) 00 is the status – Success in this case 15 00 00 9F 04 00 is the BD_ADDR of the device as listed by the hcitool dev command

KW01 demo code for 315/434MHz application is ready. The demo code located in the "software Development Tools" FXTH87|Tire Pressure Monitor Sensor|Freescale

Hello community, This time I bring to you a document which explains how to run a demo from BeeKit and how to sniff it. Before to start you need to install the BeeKit Wireless Connectivity Toolkit.     I hope you find this guide useful. Enjoy this guide! Any feedback is welcome. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

Introduction This document describes the steps needed to enable System View tool emphasizing in connectivity software stack for the QN9080CDK MCU.   Software Requirements QN908XCDK SDK 2.2.0 SystemView Software J-Link Software and Documentation Pack     Hardware Requirements QN9080CDK Board with J-Link debug interface   Enabling SystemView in IAR Embedded Workbench IDE   1. Unzip your QN908XCDK SDK. Open your desired project from:<SDK_install_path>/boards/qn908xcdk/wireless_examples/<Choose_your_project>/freertos/iar/<Your_project.eww>   2. Select the project in the workspace, press the right mouse button and select “Add->Add Group...” option       3. Create a new group called “SEGGER”, click on the “OK” button. Repeat the step 1 and create other groups called “Config” and “FreeRTOS_SEGGER”.     The workspace will be updated as shown below       4. Create folders called “SEGGER”, “Config” and “FreeRTOS_SEGGER” in the Windows directory at the following path:     <QN9080_SDK_root>/boards/qn908xcdk/wireless_examples/bluetooth/<your_example>/freertos       5. Add the following files in the recently created folders (SEGGER, Config and FreeRTOS_SEGGER) on Windows directory (the default SysView installation path is C:\Program Files (x86)\SEGGER\SystemView_V252c):   For the SEGGER folder:        All files located at <SysView_installation_path>\Src\SEGGER   For the Config folder:       All files located at <SysView_installation_path>\Src\Config   For the FreeRTOS_SEGGER folder:       <SysView_installation_path>\Src\Sample\FreeRTOSV9\SEGGER_SYSVIEW_FreeRTOS.c       <SysView_installation_path>\Src\Sample\FreeRTOSV9\SEGGER_SYSVIEW_FreeRTOS.h       <SysView_installation_path>\Src\Sample\FreeRTOSV9\Config\SEGGER_SYSVIEW_Config_FreeRTOS.c     6. Go to the workspace and click the right mouse button on “SEGGER”, “Config” and “FreeRTOS_SEGGER” groups, then select “Add->Add Files...” option. Add the following files:   For the SEGGER group:         All files in <QN9080_SDK_root>/boards/qn908xcdk/wireless_examples/bluetooth/<your_example>/freertos/SEGGER folder    For the Config group:        All files in <QN9080_SDK_root>/boards/qn908xcdk/wireless_examples/bluetooth/<your_example>/freertos/Config folder   For the FreeRTOS_SEGGER group:        All files in <QN9080_SDK_root>/boards/qn908xcdk/wireless_examples/bluetooth/<your_example>/freertos/FreeRTOS_SEGGER folder   The workspace will be updated as shown in the picture below       7. Select the project in the workspace and press Alt + F7. Go to “C/C++ Compiler” window and select “Preprocessor”. Include in “Additional include directories” view the following paths:   $PROJ_DIR$ /../Config $PROJ_DIR$ /../FreeRTOS_SEGGER $PROJ_DIR$ /../SEGGER       8. Go to “Assembler”, click on “Preprocessor”. Include the last paths on “Additional include directories” view as shown below. Click the OK button.     9. Replace the following files in the workspace with the files attached in this post (IAR files.zip). Make sure that each new file is located on the same path as the respectively last one.   freertos/FreeRTOS.h freertos/task.h freertos/tasks.c freertos/portable/portasm.s freertos/portable/port.c freertos/portable/portmacro.h   10. Add #include "SEGGER_SYSVIEW_FreeRTOS.h" at the end of the FreeRTOSConfig.h file located at source/FreeRTOSConfig.h in the workspace.       11. Search the “SEGGER_SYSVIEW_Config_FreeRTOS.c” file at FreeRTOS_SEGGER folder in the workspace. Modify the SYSVIEW_RAM_BASE value to the lowest RAM address (default 0x20000000 in QN9080) and add an extern declaration to the SystemCoreClock variable: extern uint32_t SystemCoreClock;‍‍       12. Search the “fsl_os_abstraction_free_rtos.c” file at framework/OSAbstraction folder in the workspace. Add #include "SEGGER_SYSVIEW.h" at the top of the file. Search the main function and add the following call to function inside:   SEGGER_SYSVIEW_Conf(); SEGGER_SYSVIEW_Start();‍‍‍‍‍‍‍‍‍‍        13. Build and run your example. Run SystemView in your PC.     Enabling SystemView in MCUXpresso IDE 1. Install your QN908XCDK SDK in MCUXpresso IDE and import any freertos example from "wireless_examples" folder.  2. Select the project in the workspace, press the right mouse button and select "New->Source Folder" option     3. Create a new folder called “SEGGER”, click on the “Finish” button. Repeat the step 1 and create other folders called “Config” and “FreeRTOS_SEGGER”.     The workspace will be updated as shown below     4. Add the following files in the SEGGER, Config and FreeRTOS_SEGGER folders on the workspace dragging and dropping (the default SysView installation path is C:\Program Files (x86)\SEGGER\SystemView_V252c):   For the SEGGER folder:        All files located at <SysView_installation_path>\Src\SEGGER   For the Config folder:       All files located at <SysView_installation_path>\Src\Config   For the FreeRTOS_SEGGER folder:       <SysView_installation_path>\Src\Sample\FreeRTOSV9\SEGGER_SYSVIEW_FreeRTOS.c       <SysView_installation_path>\Src\Sample\FreeRTOSV9\SEGGER_SYSVIEW_FreeRTOS.h       <SysView_installation_path>\Src\Sample\FreeRTOSV9\Config\SEGGER_SYSVIEW_Config_FreeRTOS.c   When dragging and dropping, a new window will appear. Select "Copy files" in the button group and click "OK".       5. Select the project in the workspace, then go to "Project->Properties". The project properties window will be deployed.       6. Go to "C/C++ Build->Settings->Tool Settings->MCU C Compiler->Includes" view. Click on the "Green plus icon" in the "Include paths" view. A new window will appear, click on "Workspace..." button.       7. Select SEGGER, Config and FreeRTOS_SEGGER folders and click "OK", then click "Apply and Close" in the Project Properties window.   .   8. Replace the following files in the workspace with the files attached in this post (MCUXpresso files.zip).   freertos/FreeRTOS.h freertos/task.h freertos/tasks.c freertos/port.c freertos/portmacro.h   9. Add #include "SEGGER_SYSVIEW_FreeRTOS.h" at the end of the FreeRTOSConfig.h file located at source/FreeRTOSConfig.h in the workspace.     10. Search the “SEGGER_SYSVIEW_Config_FreeRTOS.c” file at FreeRTOS_SEGGER folder in the workspace. Modify the SYSVIEW_RAM_BASE value to the lowest RAM address (default 0x20000000 in QN9080) and add an extern declaration to the SystemCoreClock variable: extern uint32_t SystemCoreClock;‍‍   11. Search the “fsl_os_abstraction_free_rtos.c” file at framework/OSAbstraction/Source folder in the workspace. Add #include "SEGGER_SYSVIEW.h" at the top of the file. Search the main function and add the following call to function inside: SEGGER_SYSVIEW_Conf(); SEGGER_SYSVIEW_Start();‍‍‍‍‍‍‍‍‍‍‍‍   12. Build and run your example. Run SystemView in your PC.

By default, FRDM-KW36 board includes a 32MHz XTAL (YI) as shown in Figure 1 but there are cases where a 26MHz XTAL is needed instead of 32MHz XTAL for FRDM-KW36 or a custom KW36 board.   Figure 1. 32MHz XTAL from FRDM-KW36 schematics Wireless connectivity demos from FRDM-KW36 Sofware Development Kit are configured to run with a 32MHz XTAL by default, but it's very easy to modify the software to operate with a 26MHz XTAL. Follow next steps to configure a FRDM-KW36 wireless connectivity demo to operate with a 26MHz XTAL: 1. In clock_config.h file, change BOARD_XTAL0_CLK_HZ define from 32000000U to 26000000U as shown in Figure 2.   Figure 2. BOARD_XTAL0_CLK_HZ define in clock_config.h 2. Add RF_OSC_26MHZ=1 line in preprocessor: If using IAR IDE: Right click on your project, then click options (Figure 3). Figure 3. IAR project options Go to C/C++ Compiler tab, then Preprocessor, and add RF_OSC_26MHZ=1 line in defined symbols window (Figure 4). Figure 4. IAR Preprocessor If using MCUXpresso IDE: Right click on your project, select Properties, go to Settings under C/C++ Build, then Preprocessor under MCU C Compiler (Figure 5). Figure 5. MCUXpresso Preprocessor Click on add button from Defined symbols, write RF_OSC_26MHZ=1 and click OK to finish (Figure 6). Figure 6. MCUXpresso Defined symbols To finish, re-compile your project and it will be ready to operate with a 26MHz XTAL. FRDM-KW36 SDK can be downloaded from the MCUXpresso webpage.

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;