ワイヤレス接続に関するナレッジベース

ディスカッション

Hello community, This time I bring to you a document which explains how easy is to add a new endpoint and a new cluster to a ZigBee device in the BeeStack in BeeKit. This document is based in the MC1323x MCUs but the procedure applies to the Kinetis devices. Before to start you need to install the BeeKit Wireless Connectivity Toolkit. If you are interested about what an endpoint is, the document ZigBee Endpoints Reserved could be useful for you. I hope you find this guide useful. Enjoy this guide, enjoy ZigBee! Any feedback is welcome. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

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;

This post covers the below details. Introduction to Framework Serial Communication Interface (FSCI). BLE Server. Useful Commands to create a GATT database. Demonstrate the heart rate sensor profile using the FSCI black box application with Test Tool. Framework Serial Communication Interface The Framework Serial Communication Interface (FSCI) is a software module and a protocol that supports interfacing the Protocol Host Stack (i.e. BLE, Thread, and ZigBee) with a host or a PC tool (Test Tool for Connectivity Products) using a serial communication interface (e.g. UART, USB, SPI, and I2C). The below figure shows interaction between different layers. Figure 1. System Overview The Host Processor (Application layer and control for Connectivity Stack) The Black Box application (APIs to interact with the Connectivity Stack) The below figure illustrates Interfacing between the host processor and black box application. Figure 2. Protocol stack separation The Test Tool software for the connectivity products is an example of a host processor that can communicate with FSCI black boxes at various layers. The figure below shows FSCI based application structure. Figure 3. FSCI based Application Structure The FSCI module executes in the context of the Serial Manager task. For more details regarding FSCI and Serial Manager module refer to the ‘Connectivity Framework Reference Manual.pdf’ document available inside SDK Documentation at location <SDK_Documentation\docs\wireless\Common>. The detailed description of the Bluetooth Low Energy Host Stack serial commands, communication packet structure, and usage of the Framework Serial Communication Interface is provided inside the ‘Bluetooth Low Energy Host Stack FSCI Reference Manual.pdf’ document available inside SDK Documentation at location <SDK_Documentation\docs\wireless\Bluetooth>. The detail about FSCI Host is described here. An example of FSCI based BLE temperature sensor application is described in AN12896. Bluetooth Low Energy Server Bluetooth Low Energy allows exchange of information using the Generic Attribute Profile (GATT), GATT defines below two roles: Server: Device that stores the information. Client: Device that request for information from the server. Going forward, this post describes how to implement a BLE Server using the FSCI black box application with Test Tool. The server device can implement the GATT Database using below two methods. Static database: MACROs are used to add services, characteristics, etc. Dynamic database: APIs are used to add services, characteristics, etc. It is useful when runtime database update is required. This is the approach used by FSCI for the management of GATT databases. The below figure shows an example of database hierarchy. Figure 4. GATT Database Service: It is a set of information. i.e., sensor location, sensor read value, etc. Bluetooth SIG has defined universally unique identifier (UUID) for various services and characteristics. This UUID will be useful to add services and characteristics to the database. Heart Rate, Battery Information, Device Information are examples of the service. Characteristic and value: It is the actual entity where information and its value are stored when the characteristic and value are added into the database. i.e., Device information service can have characteristics like manufacturer name, model string, Hardware version, etc. Descriptor: It is used to provide additional information regarding the characteristic and its value, e.g. format, scale, unit, etc. Client Characteristic Configuration Descriptor (CCCD): It is a descriptor used by the client device to enable or disable the notifications or indications. When the specific component is added using GATT_DB APIs, the stack will assign a handle to that component to index it in the database. Useful commands to create GATT database FSCI provides a set of commands for the management of the GATT Database. The most used ones are described below. Table 1 Some of the Basic GATT_DB Command Command Description No. of Handle assigned GATTDBDynamic-AddPrimaryServiceDeclaration.Request To add the primary service. 1 GATTDBDynamic-AddCharacteristicDeclarationAndValue.Request To add the characteristic and its value. It will be added as part of previously added service. 2 GATTDBDynamic-AddCharacteristicDescriptor.Request To add the descriptor for the previously added characteristic. 1 GATTDBDynamic-AddCccd.Request To add the CCCD for the previously added characteristic. 1 The attached Test Tool macro file demonstrates steps and setup required to implement a Heart Rate Sensor profile. The steps to execute it are described in the attached lab guide.

简介：当 OTAP 客户端（接收软件更新的设备，通常为 Bluetooth LE 外围设备）从 OTAP 服务器（发送软件更新的设备，通常为 Bluetooth LE Central）请求软件更新时，您可能希望保留一些数据，例如绑定信息，系统振荡器的匹配值或您的应用程序的 FlexNVM 非易失数据。本文档指导您在执行 OTAP 更新时，如何保留您感兴趣的闪存数据内容。本文档适用于熟悉 OTAP 定制 Bluetooth LE 服务的开发人员，有关更多基础信息，您可以阅读以下文章：使用 OTAP 客户端软件对 KW36 设备进行重新编程。 OTAP 标头和子元素 OTAP 协议为软件更新实现了一种格式，该格式由标题和定义数量的子元素组成。 OTAP 标头描述了有关软件更新的一般信息，并且其定义的格式如下图所示。有关标题字段的更多信息，请转至 SDK 中的<SDK_2.2.X_FRDM-KW36_Download_Path> \ docs \ wireless \ Bluetooth 中的《 Bluetooth Low Energy Application Developer's Guide》文档的 11.4.1 Bluetooth Low Energy OTAP 标头一章。每个子元素都包含用于特定目的的信息。您可以为您的应用程序实现专有字段（有关子元素字段的更多信息，请转至 SDK 中的<SDK_2.2.X_FRDM-KW36_Download_Path> \ docs \ wireless \ Bluetooth 中的《 Bluetooth Low Energy Application Developer's Guide》文档的 11.4.1 Bluetooth Low Energy OTAP 标头一章。 OTAP 包含以下子元素：镜像文件子元素值字段长度（字节）描述升级镜像变化该子元素包含实际的二进制可执行镜像，该镜像将被复制到 OTAP 客户端设备的闪存中。该子元素的最大大小取决于目标硬件。扇区位图 32 该子元素包含目标设备闪存的扇区位图，该位图告诉引导加载程序哪些扇区应被覆盖，哪些扇区保持完整。该字段的格式是每个字节的最低有效位在前，最低有效字节和位代表闪存的最低存储部分。镜像文件CRC 2 是在镜像文件的所有元素（此字段本身除外）上计算的 16 位 CRC。该元素必须是通过空中发送的镜像文件中的最后一个子元素。 OTAP 扇区位图子元素 KW36 闪存分为：一个 256 KB 程序闪存（ P-Flash）阵列，最小单元为 2 KB 扇区，闪存地址范围为 0x0000_0000 至 0x0003_FFFF。一个 256 KB FlexNVM 阵列，最小单元为 2 KB 扇区，闪存地址范围为 0x1000_0000 至 0x1003_FFFF，同时它也会被映射到地址范围为 0x0004_0000 至 0x0007_FFFF 的空间。位图子元素的长度为 256 位，就 KW36 闪存而言，每个位代表 2KB 扇区，覆盖从 0x0- 0x0007_FFFF 的地址范围（P-Flash 到 FlexNVM 映射地址范围），其中 1 表示该扇区应被擦除， 0 表示应保留该扇区。 OTAP 引导加载程序使用位图字段来获取在使用软件更新对 KW36 进行编程之前应擦除的地址范围，因此必须在发送软件更新之前对其进行配置，以使包含您的数据的内存的地址范围保持不变。仅擦除将被软件更新覆盖的地址范围。例如：假设开发人员想要保留 0x7D800-0x7FFFF 之间的地址范围和 0x0-0x1FFF 之间的地址范围，并且必须擦除剩余的存储器。 0x7D800-0x7FFFF 之间的地址范围对应于前 5 个闪存扇区， 0x0-0x1FFF 之间的地址范围是最低的 4 个扇区。因此，这意味着应将 256 和 252 之间的位（256、 255、 254、 253 和 252）以及 4 和 1 之间的位（4、 3、 2 和 1）设置为 0，这样本示例的 OTAP 位图为： 0x07FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0 使用 NXP 测试工具配置 OTAP 位图以保护地址范围在恩智浦网站上下载并安装用于连接产品的测试工具在 PC 上打开 NXP Test Tool 12 软件。转到“ OTA 更新-> OTAP 蓝牙 LE”，然后单击“浏览...”按钮加载用于软件更新的映像文件（NXP 测试工具仅接受.bin 和.srec 文件）。您可以配置 OTAP 位图，选择“覆盖扇区位图”复选框，并通过新的位图值更改默认值。配置位图后，选择“保存...”。然后，将显示一个窗口，用于选择保存.bleota 文件的目的地，保存文件可以自行取名。您可以将此文件与 Android 和 iOS 的 IoT Toolbox App 一起使用，以使用 OTAP 更新软件。这个新的.bleota 文件包含位图，该位图告诉 OTAP 引导加载程序哪些扇区将被擦除，哪些扇区将被保留。

Introduction The FRDM-KW36 includes an RSIM (Radio System Integration Module) module with an external 32 MHz crystal oscillator. This clock source reference is mainly intended to supply the Bluetooth LE Radio peripheral, but it can be used as the main clock source of the MCU as well. This oscillator includes a set of programmable capacitors to support crystals with different load capacitance needs. Changing the value of these capacitors can modify the frequency the oscillator provides, that way, the central frequency can be tuned to meet the wireless protocol standards. This configurable capacitance range is from C1: 5.7pF - C2: 7.1pF to C1: 22.6pF - C2: 28.2pF and it is configured through the BB_XTAL_TRIM field at the ANA_TRIM. The KW36 comes preprogrammed with a default load capacitance value. However, since there is variance in devices due to tolerances and parasite effects, the correct load capacitance should be checked by verifying that the optimal central frequency is attained. You will need a spectrum analyzer to measure the central frequency. To find the most accurate value for the load capacitance, it is recommended to use the Connectivity Test demo application. Adjusting Frequency Example Program the KW36 Connectivity Test software on the device. This example can be found in wireless_examples -> genfsk -> conn_test folder from your SDK package. Baremetal and FreeRTOS versions are available. In case that FRDM-KW36 board is being used to perform the test, you should move the 10pF capacitor populated in C55 to C57, to direct the RF signal on the SMA connector. Connect the board to a serial terminal software. When you start the application, you will be greeted by the NXP logo screen: Press the enter key to start the test. Then press "1" to select "Continuous tests": Finally, select "6" to start a continuous unmodulated RF test. At this point, you should be able to measure the signal in the spectrum analyzer. You can change the RF channel from 0 to 127 ("q" Ch+ and "w" Ch- keys), which represents the bandwidth from 2.360GHz to 2.487GHz, stepping of 1MHz between two consecutive channels. To demonstrate the trimming procedure, this document will make use of channel 42 (2.402GHz) which corresponds to the Bluetooth LE channel 37. In this case, with the default capacitance value, our oscillator is not exactly placed at the center of the 2.402GHz, instead, it is slightly deflected to 2.40200155 GHz, as depicted in the following figure: The capacitance can be adjusted with the "d" XtalTrim+ and "f" XtalTrim- keys. Increasing the capacitance bank means a lower frequency. In our case, we need to increase the capacitance to decrease the frequency. The nearest frequency of 2.402 GHz was 2.40199940 GHz Once the appropriate XTAL trim value has been found, it can be programmed as default in any Bluetooth LE example, changing the mXtalTrimDefault constant located in the board.c file: static const uint8_t mXtalTrimDefault‍ = 0x36;‍‍‍

The purpose of this document is to communicate known issues with the FRDM-KW41Z development platform. This document applies to all revisions of the FRDM-KW41Z development platform. However, items are divided among their respective revisions and each item may or may not apply to all revisions. Revision A The known issues, which may cause confusion for new customers, for revision A are as follows: 1) Incorrect default jumper configuration Issue: Jumper, J24, shunt connector does not shunt pins 1 and 2, as noted in the schematic notes. Impact: Customers will not, by default, be able to put the OpenSDA circuit into bootloader mode. Workaround: There is currently only one workaround for this issue. Move shunt connector on jumper, J24, to shunt pins 1 and 2. 2) Default OpenSDA application may lose serial data Issue: In certain situations, the serial to USB bridge portion of the default OpenSDA application may not correctly forward serial data. This problem typically only occurs after a POR of a development platform. Impact: Customers may experience data loss when using the serial to USB converter functionality in their application. Workaround: There is currently one workaround for this issue. Update to the latest JLink OpenSDA firmware. To update to this firmware, consult sections 2.1 and 2.2 of the OpenSDA User Guide (found here: http://cache.freescale.com/files/32bit/doc/user_guide/OPENSDAUG.pdf ). The latest JLink OpenSDA firmware can be found here: SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace . (Note: Be sure to select the correct development platform.) 3) Unable to measure correct IDD current when operating in buck mode and P3V3_BRD is disconnected Issue: When configured for buck mode operation and J8 does not have a shunt connector, it is expected that P3V3_BRD will not be powered and thus, board peripherals will not be powered (thermistor, I2C line pull-ups, SPI Flash, Accelerometer, etc,). However it should be noted that in this configuration, P3V3_BRD will be back-powered through resistor R90. R90 is a 180kOhm resistor that connects directly to the MCU reset pin. This R90 also connects to V_TGTMCU which is directly connected to P3V3_BRD through shorting trace SH500. The internal pull-up on the reset pin will, in this case, power P3V3_BRD. Impact: Customers will not be able to isolate the MCU IDD current from the board peripherals when measuring current in the buck mode configuration. This is a problem mostly when attempting to achieve datasheet IDD current numbers for low power modes in buck mode. Workaround: There are currently three (3) workarounds for this issue. Remove resistor R90. Cut shorting trace SH500. Customers should exercise caution when using this workaround. After cutting this short trace, the OpenSDA interface buffers would no longer be powered. Therefore, OpenSDA programming and serial communication will not be possible even when J8 shorting jumper is placed. Disable the reset pin in the FOPT field then configure the pin, PTA2, for GPIO output functionality driven low. Customers should exercise caution when implementing this option. The pin, PTA2, could be used as a GPIO in the end application in this configuration, but you would not want to drive PTA2 high while SW1 was directly connected to PTA2 through pins 2 and 3 of jumper J24. In this situation, you potentially short VDD and VSS inadvertently by pressing SW1. If using this workaround, it is recommended to ensure the shorting jumper of J24 is either removed or connected to pins 1 and 2. 4) Incorrect routing of SWD clock for stand-alone debugger configuration Issue: The signal SWD_CLK_TGTMCU is incorrectly routed to pin 1 of connector J12 instead of pin 4 of the SWD connector, J9. Impact: With this routing, when the OpenSDA circuit is configured as a stand-alone debugger for debugging other targets (i.e., when J12's shorting trace is cut), the OpenSDA SWD clock will not be able to be present on pin 4 of connector J9. Therefore, the FRDM-KW41Z cannot act as a stand-alone debugger to facilitate debugging other systems. Workaround: There is currently only one workaround for this issue. The workaround is a hardware workaround that requires a cutting tool (such as a modeler's knife), soldering iron, solder, and a spare wire. To implement the workaround, follow these instructions. Cut trace J12. Cut the trace next to pin 2 and 4 of J9 that connects J9, pin 4 to J12, pin 2. Once this is done, be sure to use a multimeter and ensure there is no electrical connection between J12, pin 2, and J9, pin 4. Solder one end of a spare wire to J9, pin 4, and the other end of the spare wire to J12, pin 1. This should be done on the bottom of the board.

Matter support in Visual Studio Code (VS Code) is now open to all developers. MCUXpresso extension for VS Code v24.12.71 integrates the Matter toolchain for development on Windows, macOS and Linux. It can be installed by visiting Microsoft’s Marketplace for VS Code. The following steps will set up your Windows system to develop Matter on NXP devices. This Getting Started process takes ~1 hour. This is similar time it takes with flawless CLI setup. Import Matter repo takes ~30 minutes (Clone Matter repo; run bootstrap setup script) Import first project for a board takes @~10 minutes (SDK repo download - 1st time every board) Additional projects can then be quickly imported/built. 1. Install Pigweed Project Automation Tool Pigweed is used for easier automation of building, testing, and linting GN and CMake projects. Matter uses GN, so Pigweed is used by the maintainers of the project. Complete the following to allow the Matter Bootstrap to properly modify/install the repository. Launch a Terminal in Administrator mode to allow operations to complete successfully. Ensure that Developer Mode is enabled. This can also be done by running the following command as an administrator: REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\AppModelUnlock /t REG_DWORD /v AllowDevelopmentWithoutDevLicense /d 1 /f\"" Enable long file paths. This can be done using regedit or by running the following command as an administrator: REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f Enable Git symlinks: git config --global core.symlinks true For more information on these settings visit Get started with Pigweed - Pigweed 2. Install Visual Studio Code (VS Code) Microsoft allows users to quickly install VS Code from https://code.visualstudio.com/download. The link allows the user to select the appropriate download for their OS. The following instructions are for a Windows installation. However, most of the following steps also apply to Mac and Linux users. It can be helpful for new users to directly install VS Code and the NXP extension. This can be done by sharing one of two links: vscode:extension/NXPSemiconductors.mcuxpresso https://marketplace.visualstudio.com/items?itemName=NXPSemiconductors.mcuxpresso If VS Code exists on the system, the user will be taken to the NXP MCUXpresso for VS Code extension in the Microsoft Marketplace. If VS Code is NOT installed on the system the user will be guided through the install of VS Code. At this point the VS Code application should be installed on the laptop. 3. Install MCUXpresso for VS Code Extension The user can install or update the MCUXpresso for VS Code extension from within VS Code. The following steps outline how. A short clip is included to show the steps. Open VS Code. Launch program from desktop. Open the Extensions Marketplace. Click on Icon of 4 blocks in left navigation or use Ctrl-Shft-X. Search "NXP" or "Mcuxpresso" in the Extension search window at the top left. MCUXpresso for VS Code extension will be displayed. Click on listing. Click on blue Install button in the Extension Overview that is opened in the editor. The Extension is properly installed when the following NXP icon is shown in left navigation. At this point the VS Code application now includes the NXP MCUXpresso extension. 4. Run MCUXpresso Installer for Tool Dependencies It is now necessary to install other tool dependencies to properly use VS Code for MCUXpresso, Zephyr and/or Matter. NXP provides the MCUXpresso Installer utility to simplify properly meeting these tool dependencies. The following steps list how to use the installer for a Matter system. A short clip is included to show the steps. Click on "Open MCUXpresso Installer" found under Quickstart Panel in upper left. The MCUXpresso Installer will launch if already installed. NOTE: If the Installer is not found, the user should select the blue "Download" button in the bottom right notification. Select the following from the MCUXpresso Installer list of available tools: Matter Developer Arm GNU Toolchain Standalone Toolchain Add-ons LinkServer Click the blue "Install" button and wait until installation progress shows complete Restart VS Code so that new settings are active At this point the VS Code application now includes the NXP MCUXpresso extension, and the laptop has any other tools required to begin Matter installation. 5. Import NXP Matter Repository The MCUXpresso for VS Code extension simplifies how the user can add Matter to their workspace. The repository import wizard automates most of the steps required for a user to get started with Matter. The following steps show how to add Matter Repository. 2 short clips are included to show the steps. Click on "Import Repository" found under Quickstart Panel in upper left. Click Repository found in the wizard's Remote tab. Select "NXP Matter". This automatically targets the NXP/Matter repo found on GitHub. Enter a desired location to clone/store the NXP Matter repository. Closer to C:/ is better. Select "release/v1.4.0" listed as an available version under Revision: Click Import The import process can take ~30 minutes depending on network bandwidth and IT software. NOTE: This is similar amount of time when using CLI in a terminal. After the repo is cloned, the Matter Bootstrap script is used to setup matter environment. At this point the user laptop has a valid Matter workspace. The workspace is now capable of importing and building Matter projects. 6. Import First Matter Project The MCUXpresso for VS Code extension includes an Import Example wizard that simplifies adding Matter projects to a workspace. The following instructions show how to import a project from the NXP Matter repository. A short clip is included to show the steps. Click "Import Example from Repository" from the Quickstart Panel in the upper left. Select the Matter Repository from the drop-down options for Repository. Select the desired Toolchain from the drop-down options for Toolchain. A GNU Toolchain should be available from previous MCUXpresso Installer steps. Select the target board from the drop-down options for Board. The listed boards are supported in the NXP Matter repo. Select the desired project from the Template drop-down options. Currently there are "contact-sensor-app" and "lighting-app". Click Create blue button. At this point there is a Matter project in the workspace. The project can be explored with the provided project properties and file explorer views. 7. Build Matter Project Building the project is the final step for Getting Started with a Matter project in VS Code. The extension has properly setup the project toolchain and will build successfully. The NXP extension reduces the setup time by not importing the SDK for all supported boards. The board SDK is automatically imported/cloned when it is not located on the 1st build for a board. Successive projects for the same board will not require this additional step/delay. The following steps show how to build a matter project in the workspace. A short clip is included to show the steps. Select the Matter project listed under the Projects pane located in the primary left sidebar. When selected, project control icons are revealed to the left of the project name. Click on the Build icon. Verify the build was successful by viewing the binary files with File Explorer. Click the File Explorer icon to the right of project name or in the upper left of the side bar navigation. The binary is found under the project's \out\debug folder. This exercise on "Getting Started with Matter" is completed. At this point the Matter project imported to the workspace was successfully built.

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

This document describes the Persistent Data Manager (PDM) module which handles the storage of stack context data and application data in Non-Volatile Memory (NVM). For the KW41Z devices, this memory is internal Flash and this document will therefore refer to Flash. Tip: In this document, a cold start refers to either a first-time start or a re-start without memory (RAM) held. A warm start refers to a re-start with memory held (for example following sleep with memory held). 1. Overview If the data needed for the operation of a network node is stored only in on-chip RAM, this data is maintained in memory only while the node is powered and will be lost during an interruption to the power supply (e.g. power failure or battery replacement). This data includes context data for the network stack and application data. In order for the node to recover from a power interruption with continuity of service, provision must be made for storing essential operational data in Non-Volatile Memory (NVM), such as Flash. This data can then be recovered during a re-boot following power loss, allowing the node to resume its role in the network. The storage and recovery of operational data in KW41Z Flash can be handled using the Persistent Data Manager (PDM) module, as described in the rest of this document, which covers the following topics: Initializing the PDM module - see Section 2 Managing data in Flash - see Section 3 PDM features like record searching by record ID – see Section 4 The PDM can be used with ZigBee PRO and IEEE802.15.4 wireless networking protocols. 2. Initializing the PDM and Building a File System Using the Kinetis NVM framework requires that the user must register the necessary data sets for NVM writing. This is done by calling function NVM_RegisterDataSet(). This function registers the given data set to be written in the NVM_TABLE section from Flash. The PDM module must be initialized by the application following a cold or warm start, irrespective of the PDM functionality used (e.g. context data storage or counter implementation). PDM initialization is performed using the function PDM_eInitialise(). This function requires the following information to be specified: The number of Flash sectors to be used by PDM (a zero value means use all segments) Once the PDM_eInitialise() function has been called, the PDM module builds a file system in RAM containing information about the sectors that it manages in Flash. The PDM reads the header data from each Flash sector and builds the file system. Application records are grouped and initialized in function InitAplRecords(), while network stack records are grouped and initialized in function InitNwkRecords(). For ZigBee PRO, the PDM is used in its most general form, as described above. 3. Managing Data in Flash This section describes use of the PDM module to persist data in Flash in order to provide continuity of service when the KW41Z device resumes operation after a cold start or a warm start without memory held. Data is stored in Flash in terms of ‘records’. A record occupies at least one Flash sector but may be larger than a sector and occupy multiple sectors. Any number of records of different lengths can be created, provided that they do not exceed the Flash capacity. The records are created automatically for stack context data and by the application (as indicated in Section 3.1) for application data. Each record is identified by a unique 16-bit value which is assigned when the record is created - for application data, this identifier is user-defined. The stack context data which is stored in Flash includes the following: Application layer data: AIB members, such as the EPID and ZDO state Group Address table Binding table Application key-pair descriptor Trust Centre device table Network layer data: NIB members, such as PAN ID and radio channel Neighbor table Network keys Address Map table On performing a KW41Z cold start or warm start without RAM held, the PDM must be initialized in the application as described in Section 2. If this is the first ever cold start, there will be no stack context data or application data preserved in the Flash. If it is a cold or warm start following previous use (such as after a reset), there should be stack context data and application data preserved in the Flash. On start-up, the PDM builds a file system in RAM and scans the Flash for valid data. If any data is found, it is incorporated in the file system. Saving and recovering application data in Flash are described in the subsections below. 3.1 Saving Data to Flash Application data and stack context data are saved from RAM to Flash as described below. Note: During a data save, if the Flash needs to be defragmented and purged, this will be performed automatically resulting in all records being re-saved. Application data You should save application data to Flash when important changes have been made to the data in RAM. Application data in RAM can be saved to an individual record in Flash using the function PDM_eSaveRecordData(). A buffer of data in RAM is saved to a single record in Flash (a record may span multiple Flash sectors). The records are created when calling PDM_eInitialise(). These records are traced by a unique 16-bit identifier assigned by the application - this identifier is subsequently used to reference the record. The value used must not clash with those used by the NXP libraries - the ZigBee PRO stack libraries use values above 0x8000. Subsequently, in performing a re-save to the same record (specified by its 16-bit identifier), the original Flash sectors associated with the record will be overwritten but only the sector(s) containing data changes will be altered (if no data has changed, no write will be performed). This method of only making incremental saves improves the occupancy level of the size-restricted Flash. Stack Context Data The NXP ZigBee PRO stack automatically saves its own context data from RAM to Flash when certain data items change. This data will not be encrypted. 3.2 Recovering Data from Flash Application data and stack context data are loaded from the Flash to RAM as described below. Application Data During a cold start or a warm start without memory held, once the PDM module has been initialized (see Section 2.2), PDM_eReadDataFromRecord() must be called for each record of application data in Flash that needs to be copied to RAM. Stack Context Data The function PDM_eReadDataFromRecord(), described above, is not used for records of stack context data. Loading this data from the Flash to RAM is handled automatically by the stack (provided that the PDM has been initialized). 3.3 Deleting Data in Flash All records (application data and stack context data) in the Flash can be deleted using the function PDM_vDeleteAllDataRecords(). Caution: You are not recommended to delete records of ZigBee PRO stack context data by calling PDM_vDeleteAllDataRecords() before a rejoin of the same secured network. If these records are deleted, data sent by the node after the rejoin will be rejected by the destination node since the frame counter has been reset on the source node. For more information and advice, refer to the “Application Design Notes” appendix in the ZigBee 3.0 Stack User Guide. 4. PDM Features PDM offers a function that can be used to search for a specific record by using the 16-bit record ID. This function is called PDM_GetNVMTableEntry() and the required parameters are the record ID and an output pointer for the found entry. Another available PDM feature is providing a mechanism to safely write the data to NVM. This is done by calling the function PDM_vCompletePendingOperations(), which calls the appropriate NVM function that is used to complete all writings to NVM before any other operation. As an example, user can use this function to make sure that the data is written to the NVM before a reset.

The KW40Z has support for a 32 MHz reference oscillator. This oscillator is used, among other things, as the clock for the RF operation. To properly adjust the frequency provided by this oscillator, there is a register that can be written, and this register (XTAL_TRIM) adjusts the capacitance provided by the internal capacitor bank to which the oscillator is connected. The KW40Z comes preprogramed with a default value (0x77) in the XTAL_TRIM register. However, since there is probably some variance when using different HW, the central frequency should be verified using a spectrum analyzer. Depending on the value measured, the XTAL_TRIM register can be modified to adjust the frequency. The Connectivity Test application provided here was modified, adding support to change the XTAL_TRIM register. In this case, the Agilent Technologies N9020A MXA Signal Analyzer was used, 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 KW40Z device with the Connectivity Test application, using the provided .bin file, or using IAR and replacing the files in the project with the ones provided. To replace the files, unzip the provided .zip file in the KW40Z Connectivity Software folder and when asked, select to replace the existing files with the new ones. To measure and adjust the trimming, run the Connectivity Test application. 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. Use D and F to change the XTAL_TRIM value, thus changing the central frequency. Now, considering the test is being performed in channel 11, the central frequency should be centered exactly in 2.405 GHz, but on this board, for example, it is slightly above (2.4050259 GHz) by default. In order to fix this, you will need to adjust the value of the XTAL_TRIM register. As you change the XTAL_TRIM value, the central frequency changes too. Adjust the trim value until you find a value that moves the frequency to where it should be centered. For this particular board, a trimming value of 189 (0xBD) was used. Once you have found the trimming value that best adjusts the frequency, you can use it in other projects using the following function, included in the KW4xXcvrDrv.h file: XcvrSetXtalTrim(<YOUR 8 BIT XTAL_TRIM VALUE>)‍‍‍‍‍‍

从 MKW36Z512VHT4 到 MKW36A512VFT4 的软件移植指南 URL：https://community.nxp.com/docs/DOC-345487 由 Edgar Eduardo Lomeli Gonzalez 于 2020-09-14 创建的文档引言这篇文章将指导您如何从 MKW36Z512VHT4 移植到 MKW36A512VFT4 MCU。本示例将使用 “信标（beacon）” SDK 示例程序。 SDK 的下载和安装 1- 前往 MCUXpresso 网页：MCUXpresso 网页 2- 使用您的注册帐户登录。 3- 搜索“ KW36A”设备。单击建议的处理器型号，然后单击“Build MCUXpresso SDK”。 4- 点击后将显示另一页面。在“Toolchain / IDE”框中选择“All toolchains”，并提供名称以标识软件包。然后点击“Download SDK”。 5- 接受许可协议。等待几分钟直到系统将软件包放入您的配置文件中。单击“下载 SDK 存档”（Download SDK Archive），下载 SDK，如下图所示。 6- 如果使用了 MCUXpresso IDE，请在“ Installed SDK’s”视图中拖放 KW36A SDK 压缩文件夹来安装软件包。至此，您已经下载并安装了 KW36A 芯片的 SDK 软件包。 MCUXpresso IDE 中的软件迁移 1- 在 MCUXpresso 工作区上导入“信标（beacon）”示例。单击“Import SDK examples(s)…” 选项，将出现一个新窗口。然后选择“ MKW36Z512xxx4”，单击 FRDM-KW36 图像。点击 “Next >”按钮。 2- 搜索信标例程并选择您的项目版本（裸机的 bm 或带 freertos 操作系统）。 3- 转到 Project/Properties。展开 C / C ++ Build / MCU 设置，然后选择 MKW36A512xxx4 MCU。单击“Apply and Close”按钮以保存配置。 4- 将 MKW36Z 文件夹重命名为 MKW36A，单击鼠标右键并选择“重命名”。这些是以下内容： framework/DCDC/Interface -> MKW36Z framework/DCDC/Source -> MKW36Z framework/LowPower/Interface -> MKW36Z framework/LowPower/Source -> MKW36Z framework/XCVR -> MKW36Z4 5- 在 MCUXpresso IDE 中打开“Project/Properties”窗口。转到 C / C ++ Build / Settings，然后在 Tool Settings 窗口中选择 MCU C Compiler / Includes 文件夹。在创建之前，根据 MKW35 文件夹，编辑与 MKW36 MCU 相关的所有路径。结果类似如下所示： ../framework/LowPower/Interface/MKW36A ../framework/LowPower/Source/MKW36A ../framework/DCDC/Interface/MKW36A ../framework/XCVR/MKW36A4 6- 在工具设置中选择 MCU Assembler/General 文件夹。编辑与 MKW36 MCU 相关的路径。结果类似如下所示： ../framework/LowPower/Interface/MKW36A ../framework/LowPower/Source/MKW36A ../framework/DCDC/Interface/MKW36A ../framework/XCVR/MKW36A4 7- 转到 Project/Properties。展开 MCU CCompiler/Preprocessor 窗口。编辑 “ CPU_MKW36Z512VHT4”和“ CPU_MKW36Z512VHT4_cm0plus”符号，分别将其重命名为 “ CPU_MKW36A512VFT4”和“ CPU_MKW36A512VFT4_cm0plus”。保存更改。 8- 转到工作区。删除位于 CMSIS 文件夹中的“ fsl_device_registers，MKW36Z4， MKW36Z4_features，system_MKW36Z4.h 和 system_MKW36Z4.c”文件。然后解压缩 MKW35Z SDK 软件包并在以下路径中搜索“ fsl_device_registers，MKW36A4，MKW36A4_features， system_MKW36A4.h 和 system_MKW36A4.c”文件到该文件夹中： <SDK_folder_root>/devices/MKW36A4/fsl_device_registers.h <SDK_folder_root>/devices/MKW36A4/MKW36A4.h <SDK_folder_root>/devices/MKW36A4/MKW36A4_features.h <SDK_folder_root>/devices/MKW36A4/system_MKW36A4.h <SDK_folder_root>/devices/MKW36A4/system_MKW36A4.c 9- 通过位于路径<SDK_folder_root> /devices/MKW36A4/mcuxpresso/startup_mkw36a4.c 中的“ startup_mkw36a4.c”覆盖“ startup_mkw36z4.c”（位于启动文件夹中）。您只需拖放启动文件夹，然后删除较旧的文件夹即可。 10- 在 CMSIS 文件夹中打开“ fsl_device_registers.h”文件。在以下代码（文件的第 18 行）中添加“ defined（CPU_MKW36A512VFT4）”： 11- 在 bluetooth->host->config 文件夹中打开“ ble_config.h”文件。在以下代码中添加 “ defined（CPU_MKW36A512VFT4）”（文件的第 146 行）： 12- 在 source-> common 文件夹中打开“ ble_controller_task.c”文件。在以下代码（文件的第 272 行）中添加“ defined（CPU_MKW36A512VFT4）”： 13-生成项目。至此，该项目已经在 MCUXpresso IDE 环境中移植完成。 IAR Embedded Workbench IDE 中的软件移植 1- 打开位于以下路径的信标项目： 2- 在工作区中选择项目，然后按 Alt + F7 打开项目选项。 3- 在 General Options/Target”窗口中，单击器件名称旁边的图标，再选择合适的器件 NXP / KinetisKW / KW3x / NXP MKW36A512xxx4，然后单击“确定”按钮。 4- 在以下路径中创建一个名为 MKW36A 的新文件夹： <SDK_root>/middleware/wireless/framework_5.4.6/DCDC/Interface <SDK_root>/middleware/wireless/framework_5.4.6/DCDC/Source <SDK_root>/middleware/wireless/framework_5.4.6/LowPower/Interface <SDK_root>/middleware/wireless/framework_5.4.6/LowPower/Source <SDK_root>/middleware/wireless/framework_5.4.6/XCVR 5- 复制位于上述路径的 MKW36Z 文件夹内的所有文件，然后粘贴到 MKW36A 文件夹中。 6- .在工作区中选择信标项目，然后按 Alt + F7 打开项目选项窗口。在“ C/C++ Compiler/Preprocessor”窗口中，将所有路径里的 MKW36Z 文件夹重命名为 MKW36A 文件夹。在已定义的符号文本框中，将 CPU_MKW36Z512VHT4 宏重命名为 CPU_MKW36A512VFT4。结果如下图所示：单击确定按钮。 7- 展开启动文件夹，选择所有文件，单击鼠标右键，然后选择“Remove”选项。在文件夹上单击鼠标右键，然后选择““Add/Add files”。添加位于以下路径的 startup_MKW36A4.s： <SDK_root>/devices/MKW36A4/iar/startup_MKW36A4.s 另外，将 system_MKW36A4.c 和 system_MKW36A4.h 添加到启动文件夹中。这两个文件都位于如下的路径中： 8- 在 bluetooth->host->config 文件夹中打开“ ble_config.h”文件。在以下代码中添加 “ defined（CPU_MKW36A512VFT4）”： 9- 在 source-> common 文件夹中打开“ ble_controller_task.c”文件。在以下代码中添加 “ defined（CPU_MKW36A512VFT4）”： 10-生成项目。至此，该项目已经在 IAR Embedded Workbench IDE 环境中移植完成。

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

Introduction This document provides guidance to load a new software image in a KW35 device through OTAP (Over The Air Programming) bootloader for KW35. This article also provides the steps needed to download and install the SDK used in the tutorial. Software Requirements IAR Embedded Workbench IDE or MCUXpresso IDE. SDK MKW36A512xxx4 RC4 or further. Hardware Requirements MKW35A512xxx4 device. KW35 Flash Memory Used for the OTAP Software Deployment The KW35 Flash is partitioned into: 2x256 KB Program Flash (P-Flash) array divided into 2 KB sectors with a flash address range from 0x0000_0000 to 0x0007_FFFF. The statements to comprehend how the OTAP Client software and his features works are: The OTAP Client software is split into two parts, the OTAP bootloader and the OTAP client service. The OTAP bootloader verifies if there is a new image already available to reprogram the device. The OTAP client service software provides the Bluetooth LE custom services needed to communicate with the server that contains the new image file. Therefore, before to start the test, the device has been programmed twice, first with the OTAP bootloader then with the OTAP client service project. The mechanism used to have two different software in the same device is to store each one in different memory regions and this is implemented by the linker file. In the KW35 device, the bootloader application has reserved a 16KB slot of memory starting from the 0x0 address (0x0 to 0x3FFF) thus, the left memory of the first P-Flash memory bank is reserved, among other things, by the OTAP client service application. To create a new image file for the client device, the developer needs to specify to the linker file that the code will be stored with an offset of 16KB since the first addresses are reserved for the bootloader. At connection event, the server sends all the chunks of code to the client via Bluetooth LE. The client stores the code at the second P-Flash memory bank but is not able to run yet. When the broadcast has finished, and all chunks were sent, the OTAP bootloader detects this situation and triggers a command to reprogram the device with the new application. Due the new application was built with an offset of 16KB, the OTAP bootloader program the device starting from the 0x3FFF address and the OTAP client service application is overwritten by the new image. Then the OTAP bootloader triggers the new application, starting the execution of the code. Software Development Kit download and install Go to MCUXpresso web page. Log in with your registered account. Search for “MKW36A” device. Then click on the suggested processor and click on “Build MCUXpresso SDK” The next page is displayed. Select “All toolchains” in the “Toolchain / IDE” combo box and provide the name to identify the package. Click on “Add software component”, then deploy the combo box and click on “Select All” option. Save the changes. Click on “Download SDK” button and accept the license agreement. If MCUXpresso IDE is used, drag and drop the SDK zip folder in “Installed SDK’s” perspective to install the package. Preparing the software to test the OTAP for KW35 device using IAR Embedded Workbench This section provides the steps needed to test the OTAP software on the KW35. Program the OTAP bootloader on the KW35. 1.1 Open the OTAP_bootloader project located at the following path: <SDK_download_root>\boards\virtual-board-kw35\wireless_examples\framework\bootloader_otap\bm\iar\bootloader_otap_bm.eww 1.2 Flash the project (Ctrl + D). Stop the debug session (Ctrl + Shift + D). Program the OTAP client application on the KW35. 2.1 Open the OTAP client project located in the path below. <SDK_download_root>\boards\frdmkw36\wireless_examples\bluetooth\otac_att\freertos\iar\otac_att_freertos.eww 2.2 Follow the steps 2 to 12 described in the “4.1. Changes Required in Project Options and Settings” section of the AN12252 “Migration Guide from MKW36Z512xxx4 to MKW35Z512xxx4” application note. 2.3 Open the app_preinclude.h file under the source directory in the workspace. Find the “gEepromType_d” definition and update the value to “gEepromDevice_InternalFlash_c” as shown below. #define gEepromType_d gEepromDevice_InternalFlash_c‍‍‍‍‍ 2.4 Save the MKW35Z512xxx4_connectivity.icf file located at: <SDK_download_root>\middleware\wireless\framework_5.4.4\Common\devices\MKW35Z4\iar Into the folder of the OTAP Client ATT project: <SDK_download_root>\boards\frdmkw36\wireless_examples\bluetooth\otac_att\freertos\iar 2.5 Open the project options window (Alt+F7). In Linker/Config window click the icon next to linker path and select the linker configuration file “MKW35Z512xxx4_connectivity.icf”. Set the "gUseInternalStorageLink_d” flag to 1. 2.6 Click the OK button in the project options window to save the new configuration. 2.7 Flash the project (Ctrl + D). Stop the debug session (Ctrl + Shift + D). Preparing the software to test the OTAP for KW35 device using MCUXpresso IDE This section provides the steps needed to test the OTAP software on the KW35. Program the OTAP bootloader on the KW35. 1.1 Open MCUXpresso IDE. Click on “Import SDK example(s)” option in the “Quickstart Panel” view. 1.2 Click on virtual-board-kw35 SDK icon. 1.3 Deploy the wireless_examples\framework\bootloader_otap folders and select bm project. Click Finish button. 1.4 Select “Debug” option in the Quickstart Panel. Once the project is already loaded on the device, stop the debug session. 2. Program the OTAP client application on the KW35. 2.1 Open MCUXpresso IDE. Click on “Import SDK example(s)” option in the “Quickstart Panel” view. 2.2 Click twice on the frdmkw36 icon. 2.3 Type “otac_att” in the examples textbox and select the freertos project at wireless_examples\bluetooth\otac_att\freertos. Finally, click on Finish button. 2.4 Follow the steps 5 to 17 described in the “5.1. Changes Required in Project Options and Settings” section of the AN12252 “Migration Guide from MKW36Z512xxx4 to MKW35Z512xxx4” application note. 2.5. Open the app_preinclude.h file under the source directory in the workspace. Find the “gEepromType_d” definition and update the value to “gEepromDevice_InternalFlash_c” as shown below. #define gEepromType_d gEepromDevice_InternalFlash_c‍‍‍‍‍ 2.6 Save the MKW35Z512xxx4_connectivity.ld file located at: <SDK_download_root>\middleware\wireless\framework_5.4.4\Common\devices\MKW35Z4\gcc Into the source folder in the workspace. 2.7 Open the Project/Properties window. Next, go to the MCU Linker/Managed Linker Script perspective and edit the Linker Script name to “MKW35Z512xxx4_connectivity.ld”. 2.8 Go to MCU Linker/Miscellaneous view. Press the icon below, a new window will be deployed. Add the following definition in the “Other options” box: --defsym=gUseInternalStorageLink_d=1. 2.9 Click the “Apply and Close” button in the project options window to save the new configuration. 2.10 Select “Debug” option in the Quickstart Panel. Once the project is already loaded on the device, stop the debug session. Running OTAP demo with the IoT Toolbox App Save the S-Record file created with the steps in Appendix A or Appendix B in your smartphone at a known location. Open the IoT Toolbox App and select OTAP demo. Press “SCAN” to start scanning for a suitable advertiser. Perform a falling edge on the PTB18 in the KW35 to start advertising. Create a connection with the founded device. Press “Open” and search the S-Record file. Press “Upload” to start the transfer. Once the transfer is complete, wait a few seconds until the bootloader has finished programming the new image. The new application will start automatically. Appendix A. Creating an S-Record image file for KW35 client using IAR Embedded Workbench Open the connectivity project that you want to program using the OTAP bootloader from your SDK. This example will make use of the glucose sensor project. <SDK_download_root>\boards\frdmkw36\wireless_examples\bluetooth\glucose_s\freertos\iar\glucose_s_freertos.eww Follow the steps 2 to 12 described in the “4.1. Changes Required in Project Options and Settings” section of the AN12252 “Migration Guide from MKW36Z512xxx4 to MKW35Z512xxx4” application note. Save the MKW35Z512xxx4_connectivity.icf file located at: <SDK_download_root>\middleware\wireless\framework_5.4.4\Common\devices\MKW35Z4\iar In the containing folder of your project. <SDK_download_root>\boards\frdmkw36\wireless_examples\bluetooth\glucose_s\freertos\iar Open the project options window (Alt+F7). In Linker/Config window click the icon next to linker path and select the linker configuration file MKW35Z512xxx4_connectivity.icf. Then, enable “gUseBootloaderLink_d” macro in the “Configuration file symbol definitions” textbox. Go to the “Output Converter” window. Deselect the “Override default" checkbox, expand the “Output format” combo box and select Motorola S-records format. Click OK button. Rebuild the project. Search the S-Record file in the following path: <SDK_download_root>\boards\frdmkw36\wireless_examples\bluetooth\glucose_s\freertos\iar\debug Appendix B. Creating an S-Record image file for KW35 client using MCUXpresso IDE Open the connectivity project that you want to program using the OTAP bootloader from MCUXpresso IDE This example will make use of the glucose sensor project Follow the steps 5 to 17 described in the “5.1. Changes Required in Project Options and Settings” section of the AN12252 “Migration Guide from MKW36Z512xxx4 to MKW35Z512xxx4” application note. Save the MKW35Z512xxx4_connectivity.ld file located at: <SDK_download_root>\middleware\wireless\framework_5.4.4\Common\devices\MKW35Z4\gcc Into the source folder in the workspace. Open the Project/Properties window. Next, go to the MCU Linker/Managed Linker Script perspective and edit the Linker Script name to “MKW35Z512xxx4_connectivity.ld”. Go to MCU Linker/Miscellaneous view. Press the icon below, a new window will be deployed. Add the following definition in the “Other options” box: --defsym=gUseBootloaderLink_d=1. Click the “Apply and Close” button. Build the project. Deploy the “Binaries” icon in the workspace. Click the right mouse button on the “.axf” file. Select “Binary Utilities/Create S-Record” option. The S-Record file will be saved at “Debug” folder in the workspace with “.s19” extension.

This article will describe in detailed steps how to generate, build and test a Bluetooth low energy Heart Rate Sensor project on the FRDM-KW41Z evaluation board by using the Bluetooth Developer Studio (BDS) and the NXP Kinetis BDS Plug-in. Getting Started To use this plug-in and test its output, the following programs are required: - Bluetooth Developer Studio v1.1.306 or newer: Bluetooth Developer Studio & Plugins | Bluetooth Technology Website - NXP Semiconductors Kinetis Plug-in v1.0.0: Link - Kinetis SDK 2.0 with support for MKW41Z and Bluetooth Stack version 1.2.2: Link - Kinetis SDK 2.0 add-on for BDS (found in the same package as the plug-in) - Kinetis BLE Toolbox Android or iOS mobile application To enable the NXP Kinetis BDS Plug-in in the Bluetooth Developer Studio, follow please the installation details in the readme.txt document included in the downloaded plug-in archive. Creating the project with BDS Create a new project by clicking FILE-> NEW PROJECT. Add project location, name and namespace as detailed below: Drag and drop an adopted Heart Rate Profile from the right hand side list. Your device should import the following services: Next step will be to configure the GAP layer. Click on the GAP button. First tab will be the Advertising Data. Enter desired values and check which AD types you want to include in the advertising packets. A bar below will show you how much bytes your data uses. Make sure you do not use more than the 32 bytes available. Next step is to configure the GAP properties. Make sure you check at least one advertising channel and a reasonable advertising interval range, as presented below: Click TOOLS->GENERATE CODE. Select Server as GATT side to be generated and NXP Semiconductors Kinetis v1.0.0 as the plug-in. BDS will prompt you to enter a location for the exported files. After generating the files, another window with the results log will appear. If no error messages appear, the generation is successful. Check the “Open output location when finished” box and hit the “Finish” button. A folder with the following content will open: Using the generated code Copy the contents inside the following folder: "<SDK 2.0 installation folder>\middleware\wireless\bluetooth_1.2.2\examples\bds_template_app". To generate the “bds_template_app” embedded project and test it, follow the instructions detailed in the Bluetooth Quick Start Guide document from the SDK. Seeing the application in action Before compiling the application add the following code snippet in app.c inside BleApp_HandleKeys: case gKBD_EventPressPB2_c: { mUserData.cRrIntervals = 0; mUserData.expendedEnergy = 100; Hrs_RecordHeartRateMeasurement(service_heart_rate, 120, &mUserData); break; } This will allow the board to send heart rate data of 120 bpm while in a connection and when pressing button SW3 on the FRDM-KW41Z board. The value can be seen when using Kinetis BLE Toolbox, as shown below:

Introduction This document is a quick start guide to load a new software image in a KW36 device through FSCI (Freescale Serial Communication Interface) bootloader software. Also, it contains all the steps needed to install the software required in a Windows host to handle the FSCI communication protocol. Software Requirements IAR Embedded Workbench IDE or MCUXpresso IDE. FRDM-KW36 SDK. Hardware Requirements FRDM-KW36 board. Downloading the SDK When downloading the SDK, select your specific IDE or simply choose all toolchains as shown below. In the option "Add software component", ensure to select all middleware components as depicted below. Installing FSCI Host in Windows OS The host software for the Windows OS was designed to work in a Python environment. The following steps are to download and install the software needed to use FSCI in a Windows OS. Visit the Python web site and download the latest Python 2.7.x MSI installer package for Windows OS. Open the MSI installer package. When customizing the installation options, check "Add python.exe to Path" as shown below Complete the rest of the steps for the Python installation process. Unzip the FRDM-KW36 SDK. Depending on your Python environment architecture, copy the HSDK.dll from <SDK_root>\tools\wireless\host_sdk\sdk-python\lib\<x86_or_x64> to <Python_directory>\DLLs (default in C:\Python27\DLLs). Download and install Visual C++ Redistributable Packages for Microsoft Visual Studio 2013 depending on the Windows architecture (vcredist_x86.exe or vcredist_x64.exe) from the Microsoft web site. Download and install the Microsoft Visual C++ Compiler for Python 2.7 from the following web site. To run Python scripts from the Command Prompt of Windows, we must create a system variable named PYTHONPATH. Search “System” in the Windows browser. Go to Advanced system settings -> Environment Variables… -> System variables. Click on the “New…” button and create the PYTHONPATH variable with the following value: <SDK_root>\tools\wireless\host_sdk\hsdk-python\src. Programming the FSCI bootloader on FRDM-KW36 board Attach the FRDM-KW36 board to your PC. Drag and drop the “bootloader_fsci_frdmkw36.bin” from the previously unzipped SDK file, you can find this file in: <SDK_root>\tools\wireless\binaries to your board. Like a common USB device. Creating a binary image to reprogram the device IAR Embedded Workbench Open the connectivity project that you want to program through the FSCI bootloader from your SDK. This example will make use of the heart rate sensor project, located at the following path: <SDK_root>\boards\frdmkw36\wireless_examples\bluetooth\hrs\freertos\iar\hrs_freertos.eww. Open the project options window (Alt+F7). In Linker -> Config window, edit the “Configuration file symbol definitions” add the “gUseBootloaderLink_d=1” linker flag as shown below. Go to the “Output Converter” window and ensure that the output file is in binary format (.bin), otherwise, deselect the “Override default” checkbox, expand the “Output format” combo box and select “Raw binary. Click the OK button. Rebuild the project. The binary will be saved at: <SDK_root>\boards\frdmkw36\wireless_examples\bluetooth\hrs\freertos\iar\debug MCUXpresso IDE Import your FRDM-KW36 SDK to MCUXpresso. Drag and drop your SDK on the "installed SDK's" toolbar. (In this step, it is not necessary to unzip the package). Open any connectivity project that you want to program through the FSCI bootloader from your SDK. This example will make use of the heart rate sensor project. Go to Project -> Properties, a new window will appear. Then, open the C/C++ Build -> Settings -> Linker -> Miscellaneous. Press the icon below, a new window will be deployed. Add “--defsym=gUseBootloaderLink_d=1”. Click on “Apply and Close”. Build the project. Deploy the “Binaries” icon in the workspace. Click the right mouse button on the “.axf” file. Select “Binary Utilities -> Create binary” option. The binary file will be saved at “Debug” folder in the workspace with “.bin” extension. Reprogramming an FRDM-KW36 board using the FSCI bootloader The following steps are to test the FSCI bootloader in a Windows OS. Search "Command Prompt" in the Windows browser. Run the "fsci_bootloader.py" Python script. Type the “python.exe” path in the console (default C:\Python27\python.exe). Drag and drop the “fsci_bootloader.py” from: <SDK_root>\tools\wireless\host_sdk\hsdk-python\src\com\nxp\wireless_connectivity\test\bootloader on the command prompt screen. Search the COM Port of your FRDM-KW36 board and type in the console. You can find it typing ‘Device manager’ from windows home and then search it in Ports (COM & LPT) toolbar. As you can see in this example the port may change depending on each case. Search the binary image file (created in the last section). Drag and drop on the screen. Press “Enter” to start the firmware update trough FSCI bootloader. Automatically the KW36 device will trigger to run the new software. To see all your process running, you can download the ‘IoT Toolbox’ from the app store to your smartphone and connect your device with the board to verify the random data that the heart rate sensor example generates.

ワイヤレス接続に関するナレッジベース

Wireless Connectivity Knowledge Base

ディスカッション

KW39 KW38 KW37 Radio certification documents

How to add an endpoint and a cluster to a ZigBee device in the BeeStack

Configuration of Zigbee 3.0 device on KW41Z

KW20 KW30 KW40 Radio certification documents

BLE Server Demonstration using FSCI application with Test Tool

KW36-创建保留存储器内容的OTAP镜像

KW36 - Trimming adjust of 32MHz XTAL external oscillator

FRDM-KW41Z Development Platform Errata

Getting Started with MCUXpresso for VS Code: Matter on Windows (24.12.71)

Using tcpdump tool to capture packets From 88W8987 WIFI On Linux Platform

Implementing Multiple GAP Roles on the Kinetis KW40Z Wireless Microcontroller

Persistent Data Manager (PDM) for Zigbee application on KW41Z

Adjusting XTAL trim to modify central frequency in the KW40

RF High Power Model Kit 2020 Rev2.1 Installation Questions(ADS 2015)

从MKW36Z512VHT4到MKW36A512VFT4的软件移植指南

KW36 - Low Power Support on OTAP Client Software

KW35 - Reprogramming a KW35 device using the OTAP Client Software

Creating a Heart Rate Sensor Using the Bluetooth Developer Studio and the Kinetis BLE Stack

KW36 - Reprogramming a KW36 device using the FSCI bootloader

Porting Guideline for Zigbee 3.0 application from JN516x to KW41Z