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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Wireless Connectivity Knowledge Base

ディスカッション

ソート順:
The MCX W71 Wireless Microcontroller features a 96 MHz Arm® Cortex®-M33 core coupled with a multiprotocol radio subsystem supporting Matter™, Thread®, Zigbee® and Bluetooth® Low Energy. The independent radio subsystem, with a dedicated core and memory, offloads the main CPU, preserving it for the primary application and allowing firmware updates to support future wireless standards. The MCX W71x also offers advanced security with an integrated EdgeLock® Secure Enclave Core Profile and will be supported by NXP's EdgeLock 2GO cloud services for credential sharing. The MCX W71x family supports industrial and IoT devices as a single chip solution or by acting as a coprocessor in a hosted architecture.   MCX W71 Block Diagram   Documents MCX W71 Reference Manual MCX W71 Data Sheet Errata Secure Reference manual** Certifications   Evaluation boards FRDM-MCXW71 Page FRDM-MCXW71 Schematic FRDM-MCXW71 Design Files FRDM-MCXW71 User Manual FRDM-MCXW71 Getting Started   Application Notes   Software, Hardware and Peripherals: AN14398: How to use RTC on FRDM-MCXW71 This application note describes how to configure and use the RTC peripheral in a BLE demo. AN14416: Enabling Watchdog Timer Module on FRDM-MCXW71 Bluetooth Low Energy Connectivity Stack This application note describes the process to implement the WDOG timer in a Connectivity Stack demo.  AN14396: MCX W71 Integrating the OTAP Client Service into a Bluetooth LE Peripheral Device This Application note provides the steps and process for integrating the Over the Air Programming Client Service into a BLE peripheral device. AN14394: Creating Firmware Update Image for MCX W71 using OTAP tool This application note provides the steps to create and upgrade the image on the MCX W71 board via OTAP.  AN14645: How to use Random Static Device Address for Bluetooth Application This document introduces how to enable Random Static Device Address for a Bluetooth Low Energy application. The default device address type in the SDK is Public Device Address. Power Management: AN14391: MCX W71 Loadpull Report This application note describes measurement methodology and associated results on the load-pull characteristics. AN14389: MCXW71 Bluetooth LE Power Consumption Analysis This application note provides information about the power consumption of MCXW71 wireless MCXs, the hardware design and optimized for low power operation.  AN14387: MCXW71 Power Management Hardware This application note describes the usage of the different modules dedicated to power management in the MCXW71 MCU. RF: AN14399: MCXW71 Connectivity test for 802.15.4 Application This application note describes how to use the connectivity test tool to perform MCXW71 802.15.4 RF performance. AN14374: FRDM-MCXW71 RF System Evaluation Report for Bluetooth LE and IEEE 802.15.4 Applications This application note provides the radio frequency evaluation test results of the FRDM-MCXW71 board for BLE (2FSK modulation) and for IEEE 802.15.4 (OQPSK modulation) applications. Also describes the setup and tools that can be used to perform the tests.  AN14514: MCX W71 RF System Evaluation for IEEE 802.15.4 Applications with Interferer Coexistence The document describes test setup and provides steps to perform the RF system evaluation test of NXP MCX W71 MCU for IEEE 802.15.4 applications with coexistence of these interferers: noise, sinewave, Bluetooth audio, and Wi-Fi. AN14515: FRDM-MCXW71 RF System Evaluation Report for Bluetooth Low Energy Applications with interferer Coexistence The document describes test setup and provides steps to perform the RF system evaluation test of FRDM-MCXW71 for Bluetooth LE applications (2FSK modulation) with coexistence of the following interferers: noise, Sinewave, Bluetooth audio, and Wi-Fi. AN2731: Compact Planar Antennas for 2.4 GHz Communication This document is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays. Also, several popular antennas are presented as possible solutions for some of the IEEE 802.15.4 and Bluetooth low energy applications AN14476: NXP Dual PAN Feature and Performance Results This document provides a comprehensive exploration of the Dual Personal Area Network (Dual-PAN) feature on NXP Wireless Connectivity products implementing IEEE 802.15.4 low rate wireless protocol area network standard   Security: AN14427: MCXW71 In-System Programming Utility This application note provides steps to boot MCXW71 MCU in ISP mode and establish various serial connections to communicate with the MCU. AN14397: Programming the MCXW71 Flash for Application and Radio Firmware via Serial Wire Debug during mass production This application note describes the steps to write, burn and programming all the necessary settings via SWD in mass production.  AN14370: MCXW71 Flash Encryption using NPX This application note uses the Secure Provisioning SDK (SPSDK) which is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. AN14371: MCXW71 Secure Boot using SEC Tool This application note describes how to configure an image for secure boot and updates using the Secure Provisioning GUI Tool. AN14373: Secure Boot for MCXW71 Secure boot guarantees that unauthorized code cannot be executed on a given product AN14568: Debug Authentication on MCXW71 This application note describes the steps for debug authentication using the Secure Provisioning SDK tool. AN14379: Managing Lifecycles on MCXW71 The purpose of this application note is to describe the lifecycle stages that are available to the user, how to access them, the limitations of the lifecycles, and how to transition to the next lifecycle AN14544: EdgeLock 2GO Services for MPU and MCU This application note introduces various methods that the EdgeLock 2GO service can be used with MCU and MPU devices and the features available for each method. AN14624: EdgeLock 2GO Provisioning via Secure Provisioning Tool (SEC) for MCUs EdgeLock 2GO is a fully managed cloud platform operated by NXP that provides secure provisioning services for easy deployment and maintenance of IoT devices that integrate NXP MCU, MPU, and EdgeLock SE05x secure elements. AN14670: EdgeLock 2GO Provisioning via SPSDK for MCUs EdgeLock 2GO is a fully managed cloud platform operated by NXP that provides secure provisioning services for easy deployment and maintenance of IoT devices that integrate NXP MCU, MPU, and EdgeLock SE05x secure elements.   Zigbee Protocol Zigbee 3.0 Getting Started: This Application Note provides guidance towards the best starting point for the development of your own Zigbee 3.0 device firmware. Zigbee 3.0 Base Device Template: This Application Note provides example applications to demonstrate the features and operation of the Base Device in a Zigbee 3.0 network that employs the NXP DK006 Zigbee 3.0 microcontrollers. Zigbee 3.0 Developing Devices: This Application Note describes how to develop a Zigbee 3.0 On/Off Sensor using the Base Device Template End Device application as a starting point. The On/Off Sensor described in this Application Note is based on Zigbee device types from the Zigbee Lighting and Occupancy (ZLO) Device Specification Zigbee 3.0 Light Bulbs: This Application Note provides example applications for light bulbs in a Zigbee 3.0 network that employs the NXP DK006 wireless microcontrollers. Zigbee 3.0 IoT Control Bridge: This guide provides information to allow users to connect to the Control Bridge using a Graphical User Interface (GUI), which simulates a host, to operate the Zigbee network. It also describes the serial protocol used to interface with the Control Bridge, as well as the payloads of all relevant commands and responses. Zigbee 3.0 Green Power Devices: This Application Note provides guidance towards the best starting point for the development of your own Zigbee 3.0 device firmware. Zigbee 3.0 Sensors: This Application Note provides example applications for sensors in a Zigbee 3.0 network that employs the NXP DK006 Zigbee 3.0 wireless microcontrollers. Zigbee 3.0 Controller and Switch: his Application Note provides example applications for a controller and a switch in a Zigbee 3.0 network that employs the NXP DK006 wireless microcontrollers. The Application Note also includes an example of a typical Zigbee Green Power (GP) Energy Harvesting switch in a Zigbee 3.0 network. Zigbee 3.0Developing Clusters: This Application Note describes how to develop a Zigbee 3.0 Window Covering Device using the Base Device Template Router Device application as a starting point. This Application Note can be used in two ways: As a starting point for creating a Window Covering device using the functional example created in the final step. As a guide to creating devices and clusters not included in the NXP ZCL implementation including manufacturer-specific devices and cluster. Support If you have questions regarding MCX W71, please leave your question in our Wireless MCU Community! here   Useful Links Clock Measuring using the Signal Frequency Analyzer (SFA) module for KW45/KW47/MCXW71/MCXW72 - NXP Community : this community provides the steps on how to use the Signal Frequency Analyzer  The best way to build a PCB first time right with KW45 (Automotive) or K32W1/MCXW71 (IoT/Industrial) - NXP Community : In this community provides the important link to build a PCB using a KW45 or K32W148 and MCXW71 and all concerning the radio performances, low power and radio certification (CE/FCC/ICC) How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide : This article describes a simple process for enabling the user controls the radio through serial commands.   Training MCX W71 Training, Secure MCUs for Matter, Zigbee, BLE MCX W Series Training - NXP Community   Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Development Tools  NXP MCUXpresso: MCUXpresso IDE offers advanced editing, compiling and debugging features with the addition of MCU-Specific debugging. Supports connections with all general-purpose Arm Cortex-M.  VSCode: MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. Zephyr RTOs  NXP Application Code Hub: Application Code Hub (ACH) repository enables engineers to easily find microcontroller software examples, code snippets, application software packs and demos developed by our in-house experts. This space provides a quick, easy and consistent way to find microcontroller applications. NXP SPSDK: Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool: The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool: Is an application that helps the user to perform an over the air firmware update of an NXP development board.   **For secure files is necessary to request additional access. 
記事全体を表示
Aiming to increase the reach of card and mobile payment, Europay, Mastercard and Visa (EMV) point of sale (POS) terminals are getting more lightweight, replacing hardware security with software and back-end security. Off-the-shelf mobile devices, like your smart phone, can become an acceptance point for payment cards, a so-called SoftPOS.
記事全体を表示
MIFARE DESFire EV1 supports the APDU message structure according to ISO/IEC 7816-4 for an optional wrapping of the native MIFARE DESFire EV1 APDU format and for the additionally implemented 7816-4 commands from a practical point of view.
記事全体を表示
 Introduction The KW45-EVK & FRDM-MCX W71 include an RSIM (Radio System Integration Module) module with an external 32 MHz crystal oscillator and 32kHz external oscillator. 32MHz 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 C: 3.74pF to C: 10.67pF and it is configured through the RFMC Register XO_Test field at the CDAC. The KW45 comes preprogrammed with a default load capacitance value (0x1Eh). 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. 32kHz clock source reference is mainly intended to run in low power when the 32MHz clock is switched off. This 32kHz clock enable to leave the low power mode and enter in Bluetooth LE events. Adjusting 32MHz Frequency Example   Program the KW45 /MCX W71 Connectivity Test software on the device. This example can be found in SDK_2_15_000_KW45B41Z-EVK_MR5\boards\kw45b41zevk\wireless_examples\genfsk\connectivity_test folder from your SDK package. Baremetal and FreeRTOS versions are available. In case that KW45-EVK board is being used to perform the test, you should move the 15pF capacitor populated in C3 to C4, to direct the RF signal on the SMA connector.                                   3. 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":          5. 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:         6. 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        7. Once the appropriate XTAL trim value has been found, it can be programmed as default in any Bluetooth LE example, changing the BOARD_32MHZ_XTAL_CDAC_VALUE constant located in the board_platform.h file:   Adjusting 32kHz Frequency Example   You could adjust the capacitor bank on the 32kHz oscillator. You need to observe the 32kHz frequency at pin 45 (PTC7) using an spectrum analyzer or a frequency meter. Inserting this below code in the main(void) in your application: Hello_world application in this example. 32kHz frequency is not active by default on pin45(PTC7). You need to configure the OSC32K_RDY at 1 in the CCM32K register Status Register (STATUS) field to observe the 32kHz frequency at pin 45 (PTC7). Configure the CAP_SEL, XTAL_CAP_SEL and EXTAL_CAP_SEL field available in the CCM32K register 32kHz Oscillator Control Register (OSC32K_CTRL).       XTAL_CAP_SEL and EXTAL_CAP_SEL values are from 0pF (0x00h) to 30pF (0x0Fh). You could configure those 2 registers in the clock_config.c file. Default values are 8pF for both registers.        
記事全体を表示
Some users want to use SDIO signals on M.2 connector for WiFi card. In default linux bsp, there is no problem using imx8mp-evk-usdhc1-m2.dts, usdch1 driver can normally loaded, and detect WiFi module, But default android bsp doesn't support it, even if using corresponding device tree, usdch1 driver can NOT be loaded correctly, Because default android bsp doesn't load pwrseq_simple.ko, which is used by usdhc1 node. Detailed steps on enabling usdhc1 in the attached document, hope it can help users who wants to use M.2 SDIO WiFi card. [Note] For other android bsp version, users can also refer to the steps in attached document.   Thanks! Regards, Weidong Sun
記事全体を表示
The QN9090 is a Bluetooth Low Energy device that achieves ultra-low-power consumption and integrates an Arm ® Cortex ® -M4 CPU with a comprehensive mix of analog and digital peripherals. If the developer is working with the Development platform for QN9090 wireless MCUs for the first time, it is recommended to follow the QN9090-DK Development kit Getting Started (this guide can be found in QN9090DK Documentation section). This Quick Start document provides an overview about the QN9090 DK and its software tools and lists the steps to install the hardware and the software. For this document, Temperature Sensor and Temperature Collector examples will be used to demonstrate the implementation of a custom profile (both examples can be found in the SDK). This article will explain how to add the Humidity Profile and how to modify the code to get the Humidity Sensor and Collector working.   Introduction   Generic Attribute Profile (GATT) GATT defines the way that profile and user data are exchanged between devices over a BLE connection. GATT deals with actual data transfer procedures and formats. All standard BLE profiles are based on GATT and must comply with it to operate correctly, making it a key section of the BLE specification since every single item of data relevant to applications and users must be formatted, packed and sent according to the rules. There are two GATT roles that define the devices exchanging data: GATT Server This device contains a GATT Database and stores the data transported over the Attribute Protocol (ATT). The Server accepts ATT requests, commands and confirmations sent by the Client; and it can be configured to send data on its own through notifications and indications. GATT Client This is the “active” device that accesses data on the remote GATT Server via read, write, notify, or indicate operations. Notify and indicate operations are enabled by the client but initiated by the server, providing a way to push data to the client. Notifications are unacknowledged, while indications are acknowledged. Notifications are therefore faster, but less reliable. GATT Database establishes a hierarchy to organize attributes and is a collection of Services and Characteristics exposing meaningful data. Profiles are high level definitions that define how Services can be used to enable an application; Services are collections of Characteristics. Descriptors define attributes that describe a characteristic value.   Server (Sensor)   The Temperature Sensor project will be used as base to create our Humidity Custom Profile Server (Sensor). BLE SIG profiles Some Profiles or Services are already defined in the specification, and we can verify this in the Bluetooth SIG profiles document. Also, we need to check in the ble_sig_defines.h files (${workspace_loc:/${ProjName}/bluetooth/host/interface}) if this is already declared in the code. In this case, the Service is not declared, but the Characteristic of the humidity is declared in the specification. Then, we need to check if the Characteristic is already included in ble_sig_defines.h. Since the characteristic is not included, we define it as shown: /*! Humidity Characteristic UUID */ #define gBleSig_Humidity_d                   0x2A6FU GATT Database The Humidity Sensor will act as GATT Server since it will be the device containing all the information for the GATT Client. Temperature Sensor demo already implements the Battery Service and Device Information, so we only have to change the Temperature Service to Humidity Service.   In order to create the demo, we need to define a Service that must be the same as in the GATT Client, this is declared in the gatt_uuid128.h. If the new service is not the same, Client and Server will not be able to communicate each other. All macros, functions or structures in the SDK have a common template which helps the application to act accordingly. Hence, we need to define this service in the gatt_uui128.h as shown next: /* Humidity */ UUID128(uuid_service_humidity, 0xfe, 0x34, 0x9b, 0x5f, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x02, 0x00, 0xfa, 0x10, 0x10) Units All the Services and Characteristics are declared in gatt_db.h. Descriptor are declared after the Characteristic Value declaration, but before the next Characteristic declaration. In this case the permission is the CharPresFormatDescriptor that have specific description by the standard. The Units for Humidity Characteristic is Percentage, defined in the Bluetooth SIG profiles document as 0x27AD. Descriptor Client Characteristic Configuration Descriptor (CCCD) is a descriptor where Clients write some of the bits to activate Server notifications and/or indications. PRIMARY_SERVICE_UUID128(service_humidity, uuid_service_humidity)        CHARACTERISTIC(char_humidity, gBleSig_Humidity_d, (gGattCharPropNotify_c))              VALUE(value_humidity, gBleSig_Humidity_d, (gPermissionNone_c), 2, 0x00, 0x25)              DESCRIPTOR(desc_humidity, gBleSig_CharPresFormatDescriptor_d, (gPermissionFlagReadable_c), 7, 0x0E, 0x00, 0xAD, 0x27, 0x00, 0x00, 0x00)              CCCD(cccd_humidity) Humidity service and interface Create a folder named “humidity” in path ${workspace_loc:/${ProjName}/bluetooth/profiles}. In the same path you can find the “temperature” folder; copy the temperature_service.c file and paste it inside the “humidity” folder with another name (humidity_service.c). After this, go back to the “temperature” folder and copy the temperature_interface.h file; paste it inside the “humidity” folder and rename it (humidity_interface.h). You will need to include the path of the created folder. Go to Project properties > C/C++ Build > Settings > Tool Settings > MCU C Compiler > Includes: Humidity Interface The humidity_interface.h file should include the following code, where the Service structure contains the Service handle and the initialization value: /*! Humidity Service - Configuration */ typedef struct humsConfig_tag {        uint16_t serviceHandle;        int16_t initialHumidity; } humsConfig_t; /*! Humidity Client - Configuration */ typedef struct humcConfig_tag {        uint16_t hService;        uint16_t hHumidity;        uint16_t hHumCccd;        uint16_t hHumDesc;        gattDbCharPresFormat_t humFormat; } humcConfig_t; Humidity service At minimum, humidity_service.c file must contain the following code: /*! Humidity Service - Subscribed Client*/ static deviceId_t mHums_SubscribedClientId; The Service stores the device identification for the connected client. This value is changed on subscription and non-subscription events. Initialization Initialization of the Service is made by calling the start procedure. This function is usually called when the application is initialized. In this case, this is done in the BleApp_Config() function. bleResult_t Hums_Start(humsConfig_t *pServiceConfig) {     mHums_SubscribedClientId = gInvalidDeviceId_c;     /* Set the initial value of the humidity characteristic */     return Hums_RecordHumidityMeasurement(pServiceConfig->serviceHandle,                                             pServiceConfig->initialHumidity); } Stop & Unsubscribe On stop function, the unsubscribe function is called. bleResult_t Hums_Stop(humsConfig_t *pServiceConfig) {     /* Stop functionality by unsubscribing */     return Hums_Unsubscribe(); } bleResult_t Hums_Unsubscribe(void) {     /* Unsubscribe by invalidating the client ID */     mHums_SubscribedClientId = gInvalidDeviceId_c;     return gBleSuccess_c; } Subscribe The subscribe function will be used in the main file to subscribe the GATT client to the Humidity Service. bleResult_t Hums_Subscribe(deviceId_t clientDeviceId) {     /* Subscribe by saving the client ID */     mHums_SubscribedClientId = clientDeviceId;     return gBleSuccess_c; } Record Humidity Depending on the complexity of the Service, the API will implement additional functions. For the Humidity Sensor will only have one Characteristic. The measurement will be saved on the GATT Database and send the notification to the Client. This function will need the Service handle and the new value as input parameters. bleResult_t Hums_RecordHumidityMeasurement(uint16_t serviceHandle, int16_t humidity) {        uint16_t handle;        bleResult_t result;        bleUuid_t uuid = Uuid16(gBleSig_Humidity_d);        /* Get handle of Humidity characteristic */        result = GattDb_FindCharValueHandleInService(serviceHandle,                      gBleUuidType16_c, &uuid, &handle);        if (result == gBleSuccess_c)        {              /* Update characteristic value */              result = GattDb_WriteAttribute(handle, sizeof(uint16_t), (uint8_t *)&humidity);              if (result == gBleSuccess_c)              {                     /* Notify the humidity value */                     Hts_SendHumidityMeasurementNotification(handle);              }        }        return result; } Remember to add/update the prototype for Initialization, Subscribe, Unsubscribe, Stop and Record Humidity Measurement functions in humidity_interface.h. Send notification After saving the measurement on the GATT Database by using the GattDb_WriteAttribute function, we can send the notification. To send this notification, first we have to get the CCCD and check if the notification is active after that; if it is active, then we send the notification. static void Hts_SendHumidityMeasurementNotification (              uint16_t handle ) {        uint16_t hCccd;        bool_t isNotificationActive;        /* Get handle of CCCD */        if (GattDb_FindCccdHandleForCharValueHandle(handle, &hCccd)                     != gBleSuccess_c)              return;        if (gBleSuccess_c == Gap_CheckNotificationStatus                     (mHums_SubscribedClientId, hCccd, &isNotificationActive) &&                     TRUE == isNotificationActive)        {              GattServer_SendNotification(mHums_SubscribedClientId, handle);        } } Remember to add or modify the prototype for Send Humidity Measurement Notification function.   Main file There are some modifications that need to be done in the Sensor main file: Add humidity_interface.h in main file /* Profile / Services */ #include "humidity_interface.h" Declare humidity service There are some modifications that have to be done in order to use the new Humidity Profile in the Sensor example. First, we need to declare the Humidity Service: static humsConfig_t humsServiceConfig = {(uint16_t)service_humidity, 0};   Rename BleApp_SendTemperature -> BleApp_SendHumidity static void BleApp_SendHumidity(void); After this, we need to add or modify the following functions and events: Modify BleApp_Start /* Device is connected, send humidity value */        BleApp_SendHumidity();   Ble_AppConfig Start Humidity Service and modify the Serial_Print line. /* Start services */ humsServiceConfig.initialHumidity = 0; (void)Hums_Start(&humsServiceConfig); (void)Serial_Print(gAppSerMgrIf, "\n\rHumidity sensor -> Press switch to start advertising.\n\r", gAllowToBlock_d);   BleApp_ConnectionCallback events - Event: gConnEvtConnected_c (void)Hums_Subscribe(peerDeviceId);   - Event: gConnEvtDisconnected_c (void)Hums_Unsubscribe();   Notify value in BleApp_GattServerCallback function /* Notify the humidity value when CCCD is written */ BleApp_SendHumidity(); Add the Hums_RecordHumidityMeasurement function and modify the initial value update in BleApp_SendHumidity function /* Update with initial humidity */ (void)Hums_RecordHumidityMeasurement((uint16_t)service_humidity,                                            (int16_t)(BOARD_GetTemperature())); Note: in this example, the Record Humidity uses the BOARD_GetTemperature to allow the developer to use the example without any external sensor and to be able to see a change in the collector, but in this section, there should be a GetHumidity function.   app_config.c file There are some modifications that need to be done inside app_config.c file: Modify Scanning and Advertising Data {     .length = NumberOfElements(uuid_service_humidity) + 1,     .adType = gAdComplete128bitServiceList_c,     .aData = (uint8_t *)uuid_service_humidity }   *Optional* Modify name {     .adType = gAdShortenedLocalName_c,     .length = 9,     .aData = (uint8_t*)"NXP_HUM" }   Modify Service Security Requirements {     .requirements = {         .securityModeLevel = gSecurityMode_1_Level_3_c,         .authorization = FALSE,         .minimumEncryptionKeySize = gDefaultEncryptionKeySize_d     },     .serviceHandle = (uint16_t)service_humidity }   Client (Collector)   We will use the Temperature Collector project as base to create our Humidity Custom Profile Client (Collector). BLE SIG profiles As mentioned in the Server section, we need to verify if the Profile or Service is already defined in the specification. For this, we can take a look at the Bluetooth SIG profiles document and check in the ble_sig_defines.h file (${workspace_loc:/${ProjName}/bluetooth/host/interface}) if this is already declared in the code. In our case, the Service is not declared, but the Characteristic of the Humidity is declared in the specification. Then, we need to check if the Characteristic is already included in ble_sig_defines.h. Since the Characteristic is not included, we need to define it as shown: /*! Humidity Characteristic UUID */ #define gBleSig_Humidity_d                    0x2A6FU GATT Database The Humidity Collector is going to have the GATT client; this is the device that will receive all new information from the GATT Server. The demo provided in this article works in the same way as the Temperature Collector. When the Collector enables the notifications from the Sensor, received notifications will be printed in the seral terminal. In order to create the demo, we need to define or develop a Service that must be the same as in the GATT Server, this is declared in the gatt_uuid128.h file. If the new Service is no the same, Client and Server will not be able to communicate each other. All macros, functions or structures in the SDK have a common template which helps the application to act accordingly. Hence, we need to define this service in the gatt_uui128.h as shown next: /* Humidity */ UUID128(uuid_service_humidity, 0xfe, 0x34, 0x9b, 0x5f, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x02, 0x00, 0xfa, 0x10, 0x10) Includes After that, copy the humidity profile folder from the Sensor project and paste it into the Collector project inside ${workspace_loc:/${ProjName}/bluetooth/profiles}. Also, include the path of the new folder.   Main file In the Collector main file, we need to do some modifications to use the Humidity Profile Include humidity_interface.h /* Profile / Services */ #include "humidity_interface.h"   Modify the Custom Info of the Peer device humcConfig_t     humsClientConfig;   Modify BleApp_StoreServiceHandles function static void BleApp_StoreServiceHandles {     APP_DBG_LOG("");     uint8_t i,j;     if ((pService->uuidType == gBleUuidType128_c) &&              FLib_MemCmp(pService->uuid.uuid128, uuid_service_humidity, 16))     {         /* Found Humidity Service */        mPeerInformation.customInfo.humsClientConfig.hService = pService->startHandle;         for (i = 0; i < pService->cNumCharacteristics; i++)         {             if ((pService->aCharacteristics[i].value.uuidType == gBleUuidType16_c) &&                     (pService->aCharacteristics[i].value.uuid.uuid16 == gBleSig_Humidity_d))             {                 /* Found Humidity Char */             mPeerInformation.customInfo.humsClientConfig.hHumidity = pService->aCharacteristics[i].value.handle;                 for (j = 0; j < pService->aCharacteristics[i].cNumDescriptors; j++)                 {                     if (pService->aCharacteristics[i].aDescriptors[j].uuidType == gBleUuidType16_c)                     {                         switch (pService->aCharacteristics[i].aDescriptors[j].uuid.uuid16)                         {                             /* Found Humidity Char Presentation Format Descriptor */                             case gBleSig_CharPresFormatDescriptor_d:                             {                                 mPeerInformation.customInfo.humsClientConfig.hHumDesc = pService->aCharacteristics[i].aDescriptors[j].handle;                                 break;                             }                             /* Found Humidity Char CCCD */                             case gBleSig_CCCD_d:                             {                                 mPeerInformation.customInfo.humsClientConfig.hHumCccd = pService->aCharacteristics[i].aDescriptors[j].handle;                                 break;                             }                             default:                                 ; /* No action required */                                 break;                         }                     }                 }             }         }     } }   Modify BleApp_StoreDescValues function if (pDesc->handle == mPeerInformation.customInfo.humsClientConfig.hHumDesc) {        /* Store Humidity format*/        FLib_MemCpy(&mPeerInformation.customInfo.humsClientConfig.humFormat,                     pDesc->paValue,                     pDesc->valueLength); }   Implement BleApp_PrintHumidity function static void BleApp_PrintHumidity (     uint16_t humidity ) {     APP_DBG_LOG("");     shell_write("Humidity: ");     shell_writeDec((uint32_t)humidity);     /* Add '%' for Percentage - UUID 0x27AD.        www.bluetooth.com/specifications/assigned-numbers/units */     if (mPeerInformation.customInfo.humsClientConfig.humFormat.unitUuid16 == 0x27ADU)     {         shell_write(" %\r\n");     }     else     {         shell_write("\r\n");     } }   Modify BleApp_GattNotificationCallback function if (characteristicValueHandle == mPeerInformation.customInfo.humsClientConfig.hHumidity) { BleApp_PrintHumidity(Utils_ExtractTwoByteValue(aValue)); }   Modify CheckScanEvent function foundMatch = MatchDataInAdvElementList(&adElement, &uuid_service_humidity, 16);   Some events inside BleApp_StateMachineHandler need to be modified: BleApp_StateMachineHandler - Event: mAppIdle_c if (mPeerInformation.customInfo.humsClientConfig.hHumidity != gGattDbInvalidHandle_d)   - Event: mAppServiceDisc_c if (mPeerInformation.customInfo.humsClientConfig.hHumDesc != 0U)  mpCharProcBuffer->handle = mPeerInformation.customInfo.humsClientConfig.hHumDesc;   - Event: mAppReadDescriptor_c if (mPeerInformation.customInfo.humsClientConfig.hHumCccd != 0U)   Modify BleApp_ConfigureNotifications function mpCharProcBuffer->handle = mPeerInformation.customInfo.humsClientConfig.hHumCccd;   Demonstration   In order to print the relevant data in console, it may be necessary to disable Power Down mode in app_preinclude.h file. This file can be found inside source folder. For this, cPWR_UsePowerDownMode and cPWR_FullPowerDownMode should be set to 0. Now, after connection, every time that you press the User Interface Button on QN9090 Humidity Sensor is going to send the value to QN9090 Humidity Collector. Humidity Sensor   Humidity Collector  
記事全体を表示
This guide explains how to configure Wi-Fi as Access Point using the i.MX8M Plus EVK (8MP) as the AP device and the i.MX8M Mini EVK (8MM) as the connected device.
記事全体を表示
The border router device provides connectivity of the nodes in the Thread network with the possibility to connect to the networks as the www. Requirements Hardware K32W/JN5189 DK6 Board Udoo Neo Ethernet Cable Software MCUXpresso IDE v11.4.1 o newer. SDK 2.6.4. https://mcuxpresso.nxp.com/en/dashboard DK6 Production Flash Programmer Tool udoo_neo_os_nxp.img Docker Image Software Set up 1. Flash udoo_neo_os_nxp.img on an SD card using a tool. You could use any tool to flash the image, make sure that the SD card is correctly formatted. 2. Flash the ot-rcp.bin file on the USB Dongle(K32W/JN5189),  included in the SDK. \K32W061DK6\middleware\wireless\openthread\openthread\output\k32w061\bin DK6Programmer.exe -V5 -s COM2 -p ot-rcp.bin Running OpenThread BorderRouter You have connected your Udoo Neo board to an Ethernet cable, just open a new terminal to be sure that you have a connection. You could type the ping 8.8.8.8 command. If you do not have the IPV4, you could access connection your board to your computer and use the USB IP. After that, you could open a browser and enter to the Udoo Neo page using the USB IP. You could use the different address for creating a SSH connection.   Install Docker Copy the Docker image and Bash scripts to the Udoo Board; Install docker; curl -sSl https://get.docker.com | sh; The command will take some time   Verify the Docker images was successfully loaded Launch a Docker container   In this case, the UDOO NEO Extended doesn't have an Ethernet port, so, there is a USB converter to Ethernet. The OpenThread Example requires an IPV6 address sudo ./run_br_container.sh; Note: You have to have Ethernet Connection because the OpenThread requires IPV6. Be sure that the file has the execute permissions. The image below shows the process of the container. You cannot use this terminal, as this is a running Docker instance. It will output logs from the wpantund while it’s running.   Open a new terminal and look at for the container ID     After that, open a browser and search the IPV4 of your UDOO Neo, and you will find an OpenThread web page.     On the left side, select the option form, and a new page will be displayed for the network creation. Then you can ask for the wpanctl status, it will show all the Thread information, the address, the channel of the network, etc. sudo wpanctl status sudo wpanctl getprop Thread:OnMeshPrefixes Node A In the same UDOO terminal, start the border router internal commissioner and allow that a Thread node with the preshared key could join in this network. sudo wpanctl commissioner start; sudo wpanctl commissioner joiner-add “*” 120 J01NME; Node B Flash another JN5189/K32W using the REED example and type the next command for enabling and join to a Thread Network. \K32W061DK6\boards\k32w061dk6\wireless_examples\openthread\reed ifconfig up joiner start J01NME After the joining process is complete, type the next command to attach to the border router. thread start Look at the image below, you will notice the Node B Commands.   Ping the external internet 64:ff9b::808:808 to be sure that you have access to the internet.   For a better reference please look at the OpenThread Demo Applications User Guide included in your SDK documentation. "\K32W061DK6\docs\wireless\OpenThread" 11 Chapter Running Border Router Application Scenarios   Regards, Mario    
記事全体を表示
简介: 当 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 引导加载程序哪些扇区将被擦 除,哪些扇区将被保留。    
記事全体を表示
URL : https://community.nxp.com/docs/DOC-343990 版本:3 最后更新:09-14-2020 更新:EdgarLomeli 介绍 本文档介绍了如何通过无线编程引导加载程序将新的软件镜像加载到KW41 设备中。此外, 还将详细说明如何设置客户端软件以更改镜像文件的存储方式。 软件要求 1. IAR 嵌入式集成开发环境或MCUXpresso IDE 2. 下载两个软件包,SDK FRDM-KW41Z 和SDK USB-KW41Z。 硬件要求 1. FRDM-KW41Z 板 更新过程中的OTAP 内存管理 KW41 具有512KB 程序闪存,其闪存地址范围为0x0000_0000 至0x0007_FFFF。 1. OTAP 应用程序将闪存分为两个独立的部分,即OTAP 引导加载程序(Bootloader)和 OTAP 客户端。OTAP Bootloader 会验证OTAP 客户端上是否有可用的新镜像文件要对 设备进行重新编程。OTAP 客户端软件提供了将OTAP 客户端设备与包含新镜像文件 的OTAP 服务器进行通信所需的Bluetooth LE 自定义服务(OTAP 服务器设备可以是连 接到安装有测试工具的PC 或安装有IoT 工具箱应用的智能手机的另一个FRDM-KW41Z 板)。因此,需要对OTAP 客户端设备进行两次编程,首先编程OTAP Bootloader,然后 编程支持OTAP 客户端的Bluetooth LE 应用程序。为使两个不同的软件共存于同一设备 而使用的方法是将每个软件存储在不同的存储区域中。此功能由链接器文件实现。在 KW41 设备中,引导加载程序已从0x0000_0000 到0x0003_FFF 保留了16 KB 的内存区 域,因此OTAP Client 演示程序保留了其余的内存空间。 2. 要为客户端设备创建新的镜像文件,开发人员需要在链接文件中指定将以16 KB 的偏移 量放置代码,因为必须把最前面的地址空间预留给OTAP Bootloader。 3. 在连接状态下,OTAP 服务器通过蓝牙LE 将镜像数据包(称为块)发送到OTAP 客户 端设备。OTAP 客户端设备可以首先将这些块存储在外部SPI 闪存或片上闪存中。在 OTAP 客户端软件中可以选择代码存储的目的地。 4. 当连接完成,并将所有块都从OTAP 服务器发送到OTAP 客户端设备后,OTAP 客户端 软件会将信息,比如镜像更新的来源(外部闪存或内部闪存)写入称为Bootloader 标 志的内存部分中并复位MCU 以执行OTAP Bootloader 代码。OTAP 引导加载程序 (Bootloader)会读取引导加载程序(Bootloader)标志以获取对设备进行编程所需的信 息,并触发编程以使用新应用程序对MCU 进行重新编程。由于新应用程序的偏移地 址为16 KB,因此OTAP Bootloader 从0x0000_4000 地址开始对设备进行编程,并且 OTAP 客户端应用程序将被新镜像文件所覆盖,因此,通过该方法对设备重新编程后, 将无法二次以同样的方法对设备再次编程。最后,OTAP 引导加载程序(Bootloader) 会触发命令以自动开始执行新代码。 使用IAR 嵌入式开发工具准备软件以测试KW41Z 设备的OTAP 客户端 ⚫ 加载OTAP Bootloader 到FRDM-KW41Z 上。可以通过以下路径从SDK FRDM-KW41Z 中包含的项目中编程OTAP Bootloader 软件,也可以从以下路径中拖放已编译好的二进 制文件。 ⚫ OTAP Bootloader 项目: <SDK_2.2.0_FRDM-KW41Z_download_path>\boards\frdmkw41z\wireless_examples\framework\bootloader_otap\bm\iar\bootloader_otap_bm.eww OTAP Bootloader 已编译好的二进制文件: <SDK_2.2.0_FRDM-KW41Z_download_path>\tools\wireless\binaries\bootloader_otap_frdmkw41z.bin ⚫ 打开位于以下路径的SDK FRDM-KW41Z 中包含的OTAP Client 项目。 <SDK_2.2.0_FRDM-KW41Z_download_path>\boards\frdmkw41z\wireless_examples\bluetooth\otap_client_att\freertos\iar\otap_client_att_freertos.eww ⚫ 自定义OTAP 客户端软件以选择存储方式。在工作区的源文件夹中找到 app_preinclude.h 头文件。 1. 要选择外部闪存存储方式,请将“gEepromType_d”定义为 “gEepromDevice_AT45DB041E_c” 2. 要选择内部闪存存储方式,请将“gEepromType_d”定义为 “gEepromDevice_InternalFlash_c” ⚫ 配置链接标志。打开项目选项窗口(Alt + F7)。在“Linker->Config”窗口中,找到 “Configuration file symbol definitions”窗格。 1. 要选择外部闪存存储方式,请删除“gUseInternalStorageLink_d = 1”链接标志 2. 要选择内部闪存存储方式,请添加“gUseInternalStorageLink_d = 1”链接标志 ⚫ 加载OTAP 客户端软件到FRDM-KW41Z 板上(Ctrl + D).停止调试会话(Ctrl + Shift + D). 项目默认的链接器配置会把OTAP 客户端应用程序存储到相应的内存偏移位置上。 使用MCUXpresso IDE准备软件以测试KW41Z 设备的OTAP 客户端 ⚫ 加载OTAP Bootloader 到FRDM-KW41Z 上。可以通过以下路径从SDK FRDM-KW41Z 中包含的项目中编程OTAP Bootloader 软件,也可以从以下路径中拖放已编译好的二进 制文件。 OTAP Bootloader项目: wireless_examples->framework->bootloader_otap->bm OTAP Bootloader 已编译好的二进制文件 <SDK_2.2.0_FRDM-KW41Z_download_path>\tools\wireless\binaries\bootloader_otap_frdmkw41z.bin • 单击"Quickstart Panel"视窗中的"Import SDK examples(s)"选项 • 双击frdmkw41z 图标 • 打开位于下列路径中包含在SDK FRDM-KW41Z 中的OTAP 客户端项目 wireless_examples->bluetooth->otap_client_att->freertos • 自定义OTAP 客户端软件以选择存储方式。在工作区的源文件夹中找到 app_preinclude.h 头文件。 1. 要选择外部闪存存储方式,请将“gEepromType_d”定义为 “gEepromDevice_AT45DB041E_c” 2. 要选择内部闪存存储方式,请将“gEepromType_d”定义为 “gEepromDevice_InternalFlash_c” • 配置链接文件 1. 若选择外部闪存存储方式,从此时起无需对项目中做任何修改,可跳过此步骤。 2. 若选择内部闪存存储方式,搜索位于下列路径中SDK USB-KW41Z 中的链接文件, 替换OTAP 客户端项目中源文件夹中的默认链接文件。你可以从SDK USB-KW41Z 复制(Ctrl+C ) 链接文件,并直接粘贴(Ctrl + V)在工作区中。这将显示一条警告消息,选择”Overwrite "。 SDK USB-KW41Z 上的链接文件: <SDK_2.2.0_USB-KW41Z_download_path>\boards\usbkw41z_kw41z\wireless_examples\bluetooth\otap_client_att\freertos\MKW41Z512xxx4_connectivity.ld • 保存项目中的更改。在“Quickstart Panel”中选择“Debug”。一旦项目已经加载到 设备上,请停止调试会话。 在IAR 嵌入式工作台中为FRDM-KW41Z OTAP 客户端创建S 记录镜像文件 • 从SDK FRDM-KW41Z 中打开要使用OTAP Bootloader 进行编程的一个无线连接的 项目。本示例是一个使用葡萄糖传感器的项目,该项目位于以下路径。 <SDK_2.2.0_FRDM-KW41Z_download_path>\boards\frdmkw41z\wireless_examples\bluetooth\glucose_sensor\freertos\iar\glucose_sensor_freertos.eww • 打开项目选项窗口(Alt + F7)。在“Linker->Config”窗口中,在“Configuration file symbol definitions”文本框中添加以下链接标志。 gUseBootloaderLink_d=1 • 转到“Output Converter”窗口。取消选择“Override default”复选框,展开“Output format”组合框,然后选择Motorola S-records 格式,然后单击“确定”按钮。 • 重编译项目。 • 在以下路径中搜索S-Record 文件(.srec)<SDK_2.2.0_FRDM-KW41Z_download_path>\boards\frdmkw41z\wireless_examples\bluetooth\glucose_sensor\freertos\iar\debug 在MCUXpresso IDE 中为FRDM-KW41Z OTAP 客户端创建S-Record 镜像文件 • 从MCUXpresso IDE 中打开要使用OTAP Bootloader 进行编程的一个无线连接的项 目。本示例是一个使用葡萄糖传感器的项目,该项目位于以下路径。 wireless_examples->bluetooth->glucose_sensor->freertos • 搜索位于以下路径的SDK FRDM-KW41Z 中的链接文件,并替换Glucose Sensor 项 目中源文件夹中的默认链接文件。你可以从SDK FRDM-KW41Z 复制(Ctrl + C) 链接文件,然后直接粘贴(Ctrl + V)到工作区中。这将显示一条警告消息,请选择“Overwrite”。 SDK FRDM-KW41Z 上的链接文件: <SDK_2.2.0_FRDM- KW41Z_download_path>\boards\frdmkw41z\wireless_examples\bluetooth\otap_client_att\freertos\MKW41Z512xxx4_connectivity.ld • 打开新的“MKW41Z512xxx4_connectivity.ld”链接文件。找到下图的段位置,并删除 “FILL”和“BYTE”语句。 • 编译项目。 在工作区中找到“Binaries”图标。在“.axf”文件上单击鼠标右键。选择“Binary Utilities/Create S-Record”选项。S-Record 文件将保存在工作区中带有“.s19”扩展名的 “Debug”文件夹中。 使用IoT Toolbox App 测试OTAP 客户端演示 1. 将通过上一节中的步骤创建的S-Record 文件保存在智能手机中的已知位置。 2. 打开IoT Toolbox App,然后选择OTAP 演示。按“SCAN”开始扫描合适的广告客户。 3. 按下FRDM-KW41Z 板上的“SW4”按钮开始广告。 4. 与找到的设备建立连接。 5. 按“Open”并搜索S-Record 文件 6. 按“Upload”开始传输。 7. 传输完成后,请等待几秒钟,直到引导加载程序(bootloader)完成对新镜像文件 的编程。新的应用程序将自动启动。 标签:KW KW41Z | 31Z | 21Z frdm-kw41
記事全体を表示
从 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 环境中移植完成。          
記事全体を表示
Symptoms In the KW36 SDK, there is an API bleResult_t Controller_SetTxPowerLevel(uint8_t level, txChannelType_t channel) to set the Tx power, but the unit of param[in] level is not dBm. But how do we set a Tx power in dBm? Diagnosis By going through the source code, we found that two conversions are required between the actual dBm and the set value of the API. One is PA_POWER to Transmit Output Power conversion table:     Other is Level to PA_POWER  conversion table: .tx_power[0] = 0x0001, .tx_power[1] = 0x0002, .tx_power[2] = 0x0004, .tx_power[3] = 0x0006, .tx_power[4] = 0x0008, .tx_power[5] = 0x000a, .tx_power[6] = 0x000c, .tx_power[7] = 0x000e, .tx_power[8] = 0x0010, .tx_power[9] = 0x0012, .tx_power[10] = 0x0014, .tx_power[11] = 0x0016, .tx_power[12] = 0x0018, .tx_power[13] = 0x001a, .tx_power[14] = 0x001c, .tx_power[15] = 0x001e, .tx_power[16] = 0x0020, .tx_power[17] = 0x0022, .tx_power[18] = 0x0024, .tx_power[19] = 0x0026, .tx_power[20] = 0x0028, .tx_power[21] = 0x002a, .tx_power[22] = 0x002c, .tx_power[23] = 0x002e, .tx_power[24] = 0x0030, .tx_power[25] = 0x0032, .tx_power[26] = 0x0034, .tx_power[27] = 0x0036, .tx_power[28] = 0x0038, .tx_power[29] = 0x003a, .tx_power[30] = 0x003c, .tx_power[31] = 0x003e, The input parameter 'level' of the API is the subscript of this array. The array value is PA_POWER of first conversion table, then we can find the final Tx power. From another perspective, the parameter 'level' is the index of the first table.   Solution The following demonstrates a conversion process.  
記事全体を表示
The radio certification has been performed on JN5189, QN9090 and K32W products. The certificates or declaration of conformity are available in attached files.   And click here to know more on the best way to build a PCB the first time right with K32W061, QN9090 or JN5189 ! 
記事全体を表示
Please find here all the information needed to build your own PCB based on K32W061/041(AM/A), QN9090/9030(T) or JN5189/5188(T). Your first task before to send any inquiry to NXP support is to fill the K32W Design In CHECK LIST available in this ticket.   K32W061 Manufacturing package  Find here all the product pages, most of the HW documents are in the corresponding platforms web pages: K32W061/041 (AM/A) QN9090/9030(T) JN5189/5188(T)   The K32W EVK getting started webpage: IOT_ZTB-DK006 Get started page (nxp.com) IoT_ZTB getting started manual (nxp.com)   HW: HW design consideration : JN-RM-2078-JN5189-Module-Development_1V4.pdf (see attached file) JN-RM-2079-QN9090-Module-Development_1V0.pdf (see attached file) JN-RM-2080-K32W-Module-Development_1V0.pdf (see attached file)   Radio: RF report:  JN5189: https://www.nxp.com/docs/en/application-note/AN12154.pdf (nxp.com) QN9090: https://www.nxp.com/docs/en/nxp/application-notes/AN12610.pdf (nxp.com) K32W: https://www.nxp.com/docs/en/application-note/AN12798.pdf (nxp.com) Antenna: https://www.nxp.com/docs/en/application-note/AN2731.pdf (nxp.com)   Low Power Consumption:  JN5189: https://www.nxp.com/docs/en/application-note/AN12898.pdf (nxp.com) QN9090: https://www.nxp.com/docs/en/application-note/AN12902.pdf (nxp.com) K32W: https://www.nxp.com/docs/en/application-note/AN12846.pdf (nxp.com) A power calculator tool is available here: https://community.nxp.com/t5/Connectivity-Support-QN-JN-KW/QN9090-Bluetooth-LE-Power-Profile-Calculator-Tool/ta-p/1209602 SW tools: Customer Module Evaluation Tool  (nxp.com) Bluetooth Low Energy Certification Tool (nxp.com) K32W041/K32W061/QN9090(T)/QN9030(T) Bluetooth Low Energy Certification Tool User's Guide (nxp.com)     Certification: Certificates/Declarations of conformity (nxp community)  
記事全体を表示
Based on i.MX8MN-EVK And Linux 5.4.70_2.3.0 BSP As an example of NXP Bluetooth Bluetooth application, this article describes how to use Bluetooth to realize file transfer between windows PC and i.MX8MN-EVK (linux), and between Android mobile phone and i.MX8MN-EVK. The test architecture used in this example is as follows: The following steps are for the application example: Step 1 Preparation  --Downloading DEMO Image For i.MX8MN-EVK  --Downloading uuu tool  --Compiling L5.4.70_2.3.0 BSP for i.MX8MN-EVK  --Copying rootfs to the DEMO Image directory  --Modifying example_kernel_emmc.uuu as uuu programming script  --Programming images to i.MX8MN-EVK board  Booting i.MX8MN-EVK board Step 2 Loading WIFI/BT driver and Enable Bluetooth Step 3 File Transter between Windows 10 PC and i.MX8MN-EVK board Step 4 File Transter between Android Mobile and i.MX8MN-EVK board [Summary] More detailed information, see attachment, please!
記事全体を表示
The homologation requirements in China (MIIT [2002]353) obviously are planned (end of December 2022) to be sharpened (MIIT publication from 2021-01-27: “Notice on Matters Related to Radio Management in the 2400MHz, 5100MHz and 5800MHz Bands”).   A modification register is need on the KW38 and KW36 to pass the new Chinese  requirement with acceptable margin: PA_RAMP_SEL value must be set to 0x02h (2us) instead of 0x01h (1us default value) Modification SW: XCVR_TX_DIG_PA_CTRL_PA_RAMP_SEL(2) in the nxp_xcvr_common_config.c All the details are in the attached file.   Note: This SW modification is for China country only.
記事全体を表示
In the process of practical application, customers often need the combination of ble + NFC. At present, our IOT-DK006 is the only development board with NFC module. But the NFC example is not perfect. So we porting the library of NFC reader- PN7150, to support KW series microcomputer so that KW series can handle the demand of ble + NFC function. Now I will introduce you how to port the NFC lib to KW. 1 PN7150 Introduction PN7150 is the high-performance version of PN7120, the plug’n play NFC solution for easy integration into any OS environment, reducing Bill of Material (BOM) size and cost. PN71xx controllers are ideal for home-automation applications such as gateways and work seamlessly with NFC connected tags. 2 Tools hardware:FRDM-KW36,PN7150 , some wire software:mcuxpresso11.3 package:NXP-NCI MCUXpresso example Project This package contains the nfc library and example that we need. We will refer the ‘NXPNCI-K64F_example’ firstly. Sdk version: 2.2.8, Example: frdmkw36_rtos_examples_freertos_i2c  3 Steps Hardware part:We need connect the PN7150 to KW36 like the picture. Although we can connect the PN7150 to board through the ardunio connector, the pin’s voltage is not enough to drive the PN7150. So we need a wire connected to U1 to get 3.3V.   PN7150 FRDM-KW36 VBAT/PVDD 3.3V VANT 5V GND GND IRQ PTA16 VEN PTC15 SCL PTB0,I2C0 SDA PTB1,I2C0 Software part:We should add the nfc library and directory into our project. You can check the following picture to know what file is necessary. If you want to know how to add directory into our project, you can refer this link. The red line shows what file we need. Please notice that when we add file path into the mcuxpresso configuration, we also need add the path into ‘Path and Symbols’ .   We need add some macro into ‘Preprocessor’.   We copy the NXPNCI-K64F_example’s main file content into our ‘freertos_i2c.c’. Next, we need modify the file pin_mux.c, tml.c and board.h   In file board.h,add the following macro. Don't forget to enable the pin clock. /* NXPNCI NFC related declaration */ #define BOARD_NXPNCI_I2C_INSTANCE I2C0 #define BOARD_NXPNCI_I2C_BAUDRATE (100000) #define BOARD_NXPNCI_I2C_ADDR       (0x28) #define BOARD_NXPNCI_IRQ_PORTIRQn PORTA_IRQn #define BOARD_NXPNCI_IRQ_GPIO     (GPIOA) #define BOARD_NXPNCI_IRQ_PORT     (PORTA) #define BOARD_NXPNCI_IRQ_PIN      (16U) #define BOARD_NXPNCI_VEN_GPIO     (GPIOC) #define BOARD_NXPNCI_VEN_PORT     (PORTC) #define NXPNCI_VEN_PIN            (5U)     In file pin_mux.c, add head file ‘board.h’. Add the following code in function ’ BOARD_InitPins’. The step is to configure the VEN, IRQ and I2C0. This example contains the I2C1’s code, you can comment them.     /* Initialize NXPNCI GPIO pins below */   /* IRQ and VEN PIN_MUX Configuration */   PORT_SetPinMux(BOARD_NXPNCI_IRQ_PORT, BOARD_NXPNCI_IRQ_PIN, kPORT_MuxAsGpio);   PORT_SetPinMux(BOARD_NXPNCI_VEN_PORT, NXPNCI_VEN_PIN, kPORT_MuxAsGpio);   /* IRQ interrupt Configuration */   NVIC_SetPriority(BOARD_NXPNCI_IRQ_PORTIRQn, 6);   EnableIRQ(BOARD_NXPNCI_IRQ_PORTIRQn);   PORT_SetPinInterruptConfig(BOARD_NXPNCI_IRQ_PORT, BOARD_NXPNCI_IRQ_PIN, kPORT_InterruptRisingEdge);   Finally, in file tml.c, modify PORTC_IRQHandler as PORTA_IRQHandler We finished all steps. 4 Results We use ntag to test the reading and writing operation.   When the tag is closed to the PN7150, we will get the following message.   The text recording is ‘VER=03’. Next, we will modify the text recording We need add the new macro to preprocessor.   We can modify the variable NDEF_MESSAGE in function task_nfc_reader to modify the text recording.   Then we download the program again. We will see the original text ‘VER=03’ and the text has been modified. Then we read the tag again. We will see the new text.   If we want to send the larger text, what should we do? We need modify the macro ‘ADD’. When only 4 characters are sent, ‘ADD’ is 0. And every additional character is added, the ‘ADD’ will add. We modify the tag as ‘Ver=03’, and we have two more characters. So ‘ADD’ needs to be defined as 2   It firstly shows the text ‘Test’. Then it will show the new text ‘Ver=03’. Other tags’ reading and writing operation can be enabled by defining some macro.      
記事全体を表示
This article describes how to compile the Linux BSP of the i.MX platform under ubuntu 18.04, 20.04 LTS and debian-10. This is a necessary step to integrate WIFI/BT to the I.MX platform. See the attachment for detailed steps.
記事全体を表示
This article describes how to use the tcpdump tool to capture wireless network data packets. The test block diagram is as follows: For more detailed information, See attachment,please!   NXP CAS-TIC Wireless MCU team Weidong Sun
記事全体を表示
This example of custom profile uses the Temperature Sensor and Temperature Collector examples as a base, so it can be easily modified. Both examples are in the SDK, so this document explains how to add the Humidity profile, and how to modify the code to get the Humidity Sensor and Collector working. Introduction Generic Attribute Profile (GATT) establishes in detail how to exchange all profile and user data over a BLE connection. GATT deals only with actual data transfer procedures and formats. All standard BLE profiles are based on GATT and must comply with it to operate correctly. This makes GATT a key section of the BLE specification, because every single item of data relevant to applications and users must be formatted, packed, and sent according to the rules. GATT defines two roles: Server and Client. The GATT server stores the data transported over the Attribute Protocol (ATT) and accepts Attribute Protocol requests, commands and confirmations from the GATT client. The GATT client accesses data on the remote GATT server via read, write, notify, or indicate operations. Notify and indicate operations are enabled by the client but initiated by the server, providing a way to push data to the client. Notifications are unacknowledged, while indications are acknowledged. Notifications are therefore faster, but less reliable.  GATT Database establishes a hierarchy to organize attributes. These are the Profile, Service, Characteristic and Descriptor. Profiles are high level definitions that define how services can be used to enable an application and Services are collections of characteristics. Descriptors defined attributes that describe a characteristic value.    To define a GATT Database several macros are provided by the GATT_DB API in the Freescale BLE Stack, which is part KW38 SDK. Server (Sensor)  First, we need to use the Temperature Sensor project as a base, to create our Humidity Custom Profile Server (Sensor). BLE SIG profiles To know if the Profile or service is already defined in the specification, you have to look for in Bluetooth SIG profiles and check in the ble_sig_defines.h file (${workspace_loc:/${ProjName}/bluetooth/host/interface) if this is already declared in the code. In our case, the service is not declared, but the characteristic of the humidity is declared in the specification. Then, we need to check if the characteristic is already included in ble_sig_defines.h. Since, the characteristic is not included, we need to define it as shown next:   /*! Humidity Charactristic UUID */ #define gBleSig_Humidity_d 0x2A6F   GATT Database The Humidity Sensor is going to have the GATT Server, because is going to be the device that has all the information for the GATT Client. On the Temperature Sensor demo have the Battery Service and Device Information, so you only have to change the Temperature Service to Humidity Service    In order to create the demo we need to define or develop a service that has to be the same as in the GATT Client, this is declared in the gatt_uuid128.h.If the new service is not the same, they will never be able to communicate each other. All macros, function or structure in SDK have a common template which helps the application to act accordingly. Hence, we need to define this service in the gatt_uuid128.h as shown next:    /* Humidity */ UUID128(uuid_service_humidity, 0xfe ,0x34 ,0x9b ,0x5f ,0x80 ,0x00 ,0x00 ,0x80 ,0x00 ,0x10 ,0x00 ,0x02 ,0x00 ,0xfa ,0x10 ,0x10)   All the Service and Characteristics is declared in gattdb.h. Descriptors are declared after the Characteristic Value declaration but before the next Characteristic declaration. In this case the permission is the CharPresFormatDescriptor that have specific description by the standard. The Units of the Humidity Characteristic is on Percentage that is 0x27AD. Client Characteristic Configuration Descriptor (CCCD) is a descriptor where clients write some of the bits to activate Server notifications and/or indications.   PRIMARY_SERVICE_UUID128(service_humidity, uuid_service_humidity) CHARACTERISTIC(char_humidity, gBleSig_Humidity_d, (gGattCharPropNotify_c)) VALUE(value_humidity, gBleSig_Humidity_d, (gPermissionNone_c), 2, 0x00, 0x25) DESCRIPTOR(desc_humidity, gBleSig_CharPresFormatDescriptor_d, (gPermissionFlagReadable_c), 7, 0x0E, 0x00, 0xAD, 0x27, 0x00, 0x00, 0x00) CCCD(cccd_humidity)   After that, create a folder humidity in the next path ${workspace_loc:/${ProjName}/bluetooth/profiles. Found the temperature folder, copy the temperature_service.c and paste inside of the humidity folder with another name (humidity_service.c). Then go back and look for the interface folder, copy temperature_interface.h and change the name (humidity_interface.h) in the same path. You need to include the path of the created folder. Project properties>C/C+ Build>Settings>Tool Settings>MCU C Compiler>Includes: Humidity Interface The humidity_interface.h file should have the following code. The Service structure has the service handle, and the initialization value.   /*! Humidity Service - Configuration */ typedef struct humsConfig_tag { uint16_t serviceHandle; int16_t initialHumidity; } humsConfig_t; /*! Humidity Client - Configuration */ typedef struct humcConfig_tag { uint16_t hService; uint16_t hHumidity; uint16_t hHumCccd; uint16_t hHumDesc; gattDbCharPresFormat_t humFormat; } humcConfig_t;   Humidity Service At minimum on humidity_service.c file, should have the following code. The service stores the device identification for the connected client. This value is changed on subscription and non-subscription events.   /*! Humidity Service - Subscribed Client*/ static deviceId_t mHums_SubscribedClientId;   The initialization of the service is made by calling the start procedure. This function is usually called when the application is initialized. In this case is on the BleApp_Config().   bleResult_t Hums_Start(humsConfig_t *pServiceConfig) { mHums_SubscribedClientId = gInvalidDeviceId_c; /* Set the initial value of the humidity characteristic */ return Hums_RecordHumidityMeasurement(pServiceConfig->serviceHandle, pServiceConfig->initialHumidity); }   On stop function, the unsubscribe function is called.   bleResult_t Hums_Stop(humsConfig_t *pServiceConfig) { /* Stop functionality by unsubscribing */ return Hums_Unsubscribe(); } bleResult_t Hums_Unsubscribe(void) { /* Unsubscribe by invalidating the client ID */ mHums_SubscribedClientId = gInvalidDeviceId_c; return gBleSuccess_c; }   The subscribe function will be used in the main file, to subscribe the GATT client to the Humidity service.   bleResult_t Hums_Subscribe(deviceId_t clientDeviceId) { /* Subscribe by saving the client ID */ mHums_SubscribedClientId = clientDeviceId; return gBleSuccess_c; }   Depending on the complexity of the service, the API will implement additional functions. For the Humidity Sensor only have a one characteristic. The measurement will be saving on the GATT database and send the notification to the client. This function will need the service handle and the new value as input parameters.   bleResult_t Hums_RecordHumidityMeasurement(uint16_t serviceHandle, int16_t humidity) { uint16_t handle; bleResult_t result; bleUuid_t uuid = Uuid16(gBleSig_Humidity_d); /* Get handle of Humidity characteristic */ result = GattDb_FindCharValueHandleInService(serviceHandle, gBleUuidType16_c, &uuid, &handle); if (result != gBleSuccess_c) return result; /* Update characteristic value */ result = GattDb_WriteAttribute(handle, sizeof(uint16_t), (uint8_t*) &humidity); if (result != gBleSuccess_c) return result; Hts_SendHumidityMeasurementNotification(handle); return gBleSuccess_c; }   After save the measurement on the GATT database with GattDb_WriteAttribute function we send the notification. To send the notification, first have to get the CCCD and after check if the notification is active, if is active send the notification.   static void Hts_SendHumidityMeasurementNotification ( uint16_t handle ) { uint16_t hCccd; bool_t isNotificationActive; /* Get handle of CCCD */ if (GattDb_FindCccdHandleForCharValueHandle(handle, &hCccd) != gBleSuccess_c) return; if (gBleSuccess_c == Gap_CheckNotificationStatus (mHums_SubscribedClientId, hCccd, &isNotificationActive) && TRUE == isNotificationActive) { GattServer_SendNotification(mHums_SubscribedClientId, handle); } }   Humidity Sensor Main file There are some modifications that have to be done, to use the new Humidity profile in our sensor example. First, we need to declare the humidity service:   static humsConfig_t humsServiceConfig = {(uint16_t)service_humidity, 0};   Then, we need to add or modify the following functions: BleApp_Start You need to modify this line:   /* Device is connected, send humidity value */ BleApp_SendHumidity();   BleApp_Config You need to start the Humidity Service, and to modify the PrintString line:   humsServiceConfig.initialHumidity = 0; (void)Hums_Start(&humsServiceConfig);     AppPrintString("\r\nHumidity sensor -> Press switch to start advertising.\r\n");   BleApp_ConnectionCallback There are some modifications required in two Connection Events. gConnEvtConnected_c   (void)Hums_Subscribe(peerDeviceId); gConnEvtDisconnected_c   gConnEvtDisconnected_c   (void)Hums_Unsubscribe();   BleApp_GattServerCallback   /* Notify the humidity value when CCCD is written */ BleApp_SendHumidity()   BleApp_SendHumidity And, we need to add this function:   static void BleApp_SendHumidity(void) { (void)TMR_StopTimer(appTimerId); /* Update with initial humidity */ (void)Hums_RecordHumidityMeasurement((uint16_t)service_humidity, (int16_t)(BOARD_GetTemperature())); #if defined(cPWR_UsePowerDownMode) && (cPWR_UsePowerDownMode) /* Start Sleep After Data timer */ (void)TMR_StartLowPowerTimer(appTimerId, gTmrLowPowerSecondTimer_c, TmrSeconds(gGoToSleepAfterDataTime_c), DisconnectTimerCallback, NULL); #endif }   In this example, the Record Humidity uses the BOARD_GetTemperature, to use the example without any external sensor and to be able to see a change in the collector, but, in this section would be a GetHumidity function. Client (Collector)  First, we need to use the Temperature Collector project as a base, to create our Humidity Custom Profile Client (Collector). BLE SIG profiles The same applies for the Client. To know if the Profile or service is already defined in the specification, you have to look for in Bluetooth SIG profiles and check in the ble_sig_defines.h file (${workspace_loc:/${ProjName}/bluetooth/host/interface) if this is already declared in the code. In our case, the service is not declared, but the characteristic of the humidity is declared in the specification. Then, we need to check if the characteristic is already included in ble_sig_defines.h. Since, the characteristic is not included, we need to define it as shown next:   /*! Humidity Charactristic UUID */ #define gBleSig_Humidity_d 0x2A6F   GATT Database The Humidity Collector is going to have the GATT client; this is the device that will receive all information from  the GATT server. Demo provided in this post works like the Temperature Collector. When the Collector enables the notifications from the sensor, received notifications will be printed in the serial terminal. In order to create the demo we need to define or develop a service that has to be the same as in the GATT Server, this is declared in the gatt_uuid128.h.If the new service is not the same, they will never be able to communicate each other. All macros, function or structure in SDK have a common template which helps the application to act accordingly. Hence, we need to define this service in the gatt_uuid128.h as shown next:   /* Humidity */ UUID128(uuid_service_humidity, 0xfe ,0x34 ,0x9b ,0x5f ,0x80 ,0x00 ,0x00 ,0x80 ,0x00 ,0x10 ,0x00 ,0x02 ,0x00 ,0xfa ,0x10 ,0x10)   After that, copy the humidity profile folder from the Sensor project, to the Collector project ${workspace_loc:/${ProjName}/bluetooth/profiles. And also for this project, include the path of the new folder. Project properties>C/C+ Build>Settings>Tool Settings>MCU C Compiler>Includes: Humidity Collector Main file In the Collector source file, we need to do also some modifications, to use the Humidity Profile. First, we need to modify the Custom Information of the Peer device:   humcConfig_t humsClientConfig;   BleApp_StoreServiceHandles   static void BleApp_StoreServiceHandles ( gattService_t *pService ) { uint8_t i,j; if ((pService->uuidType == gBleUuidType128_c) && FLib_MemCmp(pService->uuid.uuid128, uuid_service_humidity, 16)) { /* Found Humidity Service */ mPeerInformation.customInfo.humsClientConfig.hService = pService->startHandle; for (i = 0; i < pService->cNumCharacteristics; i++) { if ((pService->aCharacteristics[i].value.uuidType == gBleUuidType16_c) && (pService->aCharacteristics[i].value.uuid.uuid16 == gBleSig_Humidity_d)) { /* Found Humudity Char */ mPeerInformation.customInfo.humsClientConfig.hHumidity = pService->aCharacteristics[i].value.handle; for (j = 0; j < pService->aCharacteristics[i].cNumDescriptors; j++) { if (pService->aCharacteristics[i].aDescriptors[j].uuidType == gBleUuidType16_c) { switch (pService->aCharacteristics[i].aDescriptors[j].uuid.uuid16) { /* Found Humidity Char Presentation Format Descriptor */ case gBleSig_CharPresFormatDescriptor_d: { mPeerInformation.customInfo.humsClientConfig.hHumDesc = pService->aCharacteristics[i].aDescriptors[j].handle; break; } /* Found Humidity Char CCCD */ case gBleSig_CCCD_d: { mPeerInformation.customInfo.humsClientConfig.hHumCccd = pService->aCharacteristics[i].aDescriptors[j].handle; break; } default: ; /* No action required */ break; } } } } } } }   BleApp_StoreDescValues   if (pDesc->handle == mPeerInformation.customInfo.humsClientConfig.hHumDesc) { /* Store Humidity format*/ FLib_MemCpy(&mPeerInformation.customInfo.humsClientConfig.humFormat, pDesc->paValue, pDesc->valueLength); }   BleApp_PrintHumidity   /*www.bluetooth.com/specifications/assigned-numbers/units */ if (mPeerInformation.customInfo.humsClientConfig.humFormat.unitUuid16 == 0x27ADU) { AppPrintString(" %\r\n"); } else { AppPrintString("\r\n"); }   BleApp_GattNotificationCallback   if (characteristicValueHandle == mPeerInformation.customInfo.humsClientConfig.hHumidity) { BleApp_PrintHumidity(Utils_ExtractTwoByteValue(aValue)); }    CheckScanEvent   foundMatch = MatchDataInAdvElementList(&adElement, &uuid_service_humidity, 16);   BleApp_StateMachineHandler mAppIdle_c   if (mPeerInformation.customInfo.humsClientConfig.hHumidity != gGattDbInvalidHandle_d)   mAppServiceDisc_c   if (mPeerInformation.customInfo.humsClientConfig.hHumDesc != 0U) mpCharProcBuffer->handle = mPeerInformation.customInfo.humsClientConfig.hHumDesc;   mAppReadDescriptor_c   if (mPeerInformation.customInfo.humsClientConfig.hHumCccd != 0U)   BleApp_ConfigureNotifications   mpCharProcBuffer->handle = mPeerInformation.customInfo.humsClientConfig.hHumCccd;   Demonstration Now, after connection, every time that you press the SW3 on KW38 Humidity Sensor is going to send the value to KW38 Humidity Collector.  
記事全体を表示