Wireless Connectivity Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Wireless Connectivity Knowledge Base

Discussions

Sort by:
The RW61x is a highly integrated, low-power tri-radio wireless MCU with an integrated MCU and Wi-Fi ®  6 + Bluetooth ®  Low Energy (LE) 5.4 / 802.15.4 radios designed for a broad array of applications, including connected smart home devices, enterprise and industrial automation, smart accessories and smart energy. The RW61x MCU subsystem includes a 260 MHz Arm ®  Cortex ® -M33 core with Trustzone ™ -M, 1.2 MB on-chip SRAM and a high-bandwidth Quad SPI interface with an on-the-fly decryption engine for securely accessing off-chip XIP flash. The RW612 includes a full-featured 1x1 dual-band (2.4 GHz/5 GHz) 20 MHz Wi-Fi 6 (802.11ax) subsystem bringing higher throughput, better network efficiency, lower latency and improved range over previous generation Wi-Fi standards. The Bluetooth LE radio supports 2 Mbit/s high-speed data rate, long range and extended advertising. The on-chip 802.15.4 radio can support the latest Thread mesh networking protocol. In addition, the RW612 can support Matter over Wi-Fi or Matter over Thread offering a common, interoperable application layer across ecosystems and products. NXP RW61x Block Diagram Documents   RW61x Datasheet      RW61x Datasheet RW61x User Manual:  UM11865: RW61x User Manual RW61x Register Manual: RM00278: RX16x Registers     RW61x Modules   Azurewave   AW-CU570 u-blox  IRIS-W10 Series  Murata LBES0ZZ2FR    Evaluation boards    FRDM-RW612 FRDM-RW612 is a compact and scalable development board for rapid prototyping of the RW61x series of Wi-Fi 6 + Bluetooth Low Energy + 802.15.4 tri-radio wireless MCUs. It offers easy access to the MCU’s I/O's and peripherals, integrated open-standard serial interfaces, external flash memory and on-board MCU-Link debugger. FRDM-RW612 Getting Started Getting Started with FRDM-RW612 FRDM-RW612 User Manual: UM12160: FRDM-RW612 Board User Manual FRDM-RW612 Quick Start Guide FRDM-RW612 Quick Start Guide   u-blox   USB-IRIS-W1 The USB-IRIS-W1 development platform is built on the dual-band Wi-Fi 6 and Bluetooth LE module IRIS-W1, based on the NXP RW610/612 chip. The board is designed with a USB interface to simplify evaluation and prototyping directly from a PC. In addition to the IRIS-W1 module with integrated antenna, it also integrates four buttons, an RGB LED, and a USB/UART converter, to further support an easy evaluation.   u-blox   EVK-IRIS-W1  The EVK-IRIS-W1 evaluation kit provides stand-alone use of the IRIS-W1 module series featuring the NXP RW610/612 chipset. Azurewave    AW-CU570-EVB   Murata   2FR EVK     Application Notes     RM00287: Wi-Fi Driver API for SDK 2.16.100     The radio driver source code provides APIs to send and receive packets over the radio interfaces by communicating with the firmware images. This manual provides the reference documentation for the Wi-Fi driver and Wi-Fi Connection Manager.  UM12133: NXP NCP Application Guide for RW612 with MCU Host - User manual     This user manual describes: • The NXP NCP application for RW612 with MCU host platform i.MX RT1060 as example. • The hardware connections for one of the four supported interfaces to enable NCP mode on the NXP RW612 BGA V4 board (UART, USB, SDIO, or SPI). • The method to build and run the NCP applications on both the NCP host (i.MX RT1060) and the NCP device (RW612). The applications apply to Wi-Fi, Bluetooth Low Energy and OpenThread (OT)    UM12095:  NXP NCP Application Guide for RW612 with MPU Host - User manual      This user manual describes: • The NXP NCP application for RW612 with MPU host platform i.MX 8M Mini as example. • The hardware connections for one of the four supported interfaces to enable NCP mode on the NXP RW612 BGA V4 board (UART, USB, SDIO, or SPI). • The method to build and run the NCP applications on both the NCP host (i.MX 8M Mini) and the NCP device (RW612). The applications apply to Wi-Fi, Bluetooth Low Energy and OpenThread (OT).  AN14439: Migration Guide from FRDM-RW612 Board to Third-Party Module board This Application note provides an overview of what it means to migrate the application to a different board with different flash and pSRAM AN14111: Target Wake Time (TWT) on RW16x This application note describes the target wake time feature and provides examples for RW61X AN13006: Compliance and Certification Considerations This application note provides guidance and tips on how to test products on NXP Wi-Fi devices for regulatory compliance. AN13049: Wi-Fi/Bluetooth/802.15.4 M.2 Key E Pinout Definition This Application note defines M.2 usage for both NXP Wi-Fi/Bluetooth and Tri-Radio M.2 module design   Support   if you have questions regarding RW61x family please leave a question in our Wireless MCU Community! here    Training FRDM-RW612 Training Wi0Fi 6 Tri-Radio in a secure i.MX RT MCU     Development Tools    SDK builder     The MCUXpresso SDK brings open-source drivers, middleware, and reference example application to speed your software development. 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        The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated embedded controllers, smart watches, and IoT wireless applications. 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. SDK Examples for Wireless MCUs    The wireless examples feature many common connectivity configurations.   Useful Links     Bluetooth Spec Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview  
View full article
KW45’s three-core architecture integrates a 96 MHz CM33 application core, dedicated CM3 radio core and an isolated EdgeLock Secure Enclave. The Flash-based radio core with dedicated SRAM delivers a highly configurable and upgradeable software-implemented radio, freeing resources on the main core for customer application space. The Bluetooth Low Energy 5.3-compliant radio supports up to 24 simultaneous secure connections. The EdgeLock Secure Enclave’s isolated execution environment provides a set of cryptographic accelerators, key store operations and secure lifecycle management that minimizes main core security responsibilities. The KW45 MCU additionally integrates FlexCAN, helping enable seamless integration into an automobile’s in-vehicle or industrial CAN communication network. The FlexCAN module can support CAN’s flexible data rate (CAN FD) for increased bandwidth and lower latency. KW45 Block Diagram KW45 Architecture Block Diagram Documents: Reference Manual Datasheet Errata Secure Reference manual** Certifications Bluetooth Spec Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Evaluation boards KW45 KW45-EVK KW45-EVK Schematic KW45-EVK Design Files KW45-EVK User manual KW45-LOC User manual KW45-EVK Getting Started Application Notes Software, Hardware and Peripherals:   AN14122 : How to use RTC on KW45 This application note describes how to configure and use the RTC peripheral in a BLE demo AN14141 : Enabling Watchdog Timer Module on KW45 Bluetooth Low Energy Connectivity Stack This application note describes the process to implement the WDOG timer in a Connectivity Stack demo. AN13855 : KW45/K32W1 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. AN13584 : Kinetis KW45 and K32W1 Loadpull Report This application note describes measurement methodology and associated results on the load-pull characteristics. AN13860 : Creating Firmware Update Image for KW45/K32W1 using OTAP tool This application note provides the steps to create and upgrade the image on the KW45 board via OTAP. AN14077 : Steps to migrating KW45 (1MB) to KW45 (512kB) This application note describes the initial steps require to migrate from 1MB flash to 512kB flash. Power Management: AN13230 : Kinetis KW45 and K32W1 Bluetooth LE Power Consumption Analysis This application note provides information about the power consumption of KW45 wireless MCUs, the hardware design and optimized for low power operation. AN13831 : KW45/K32W1 Power Management Hardware This application note describes the usage of the different modules dedicated to power management in the KW45/K32W1 MCU. RF: AN13687 : K32W1 Connectivity test for 802.15.4 Application This application note describes how to use the connectivity test tool to perform K32W1 802.15.4 RF performance. AN13728 : KW45 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 KW45 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.  AN14098: KW45-LOC RF Test Report This application note provides basic RF test result of the KW45B41Z localization board.  AN13228 : KW45-EVK RF System Evaluation Report for BLE Applications This application note provides the RF evaluation test result of the KW45B41Z-EVK for BLE application using two frequency Shift Keying modulation. AN13229 : KW45-EVK Co-existence with RF System Evaluation Report for BLE application This application note provides the RF evaluation test results of the KW45B41Z-EVK for BLE application (2FSK modulation) AN13512 : Kinetis Wireless Family Products BLE Coexistence with Wi-Fi Application  This application note provides the K32W1/4X low energy family products immunity on Wi-Fi signals and methods to improve coexistence with Wi-Fi  Security: AN13859 : KW45/K32W1 In-System Programming Utility This application note provides steps to boot KW45/K32W1 MCU in ISP mode and establish various serial connections to communicate with the MCU. AN1403 : Programming the KW45 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.    Support if you have questions regarding KW45 please leave a question in our Wireless MCU Community! here    Useful Links The best way to build a PCB first time right with KW45 (Automotive) or K32W1/MCXW71 (IoT/Industrial)... 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 <<Link to training community Post>>   Development Tools    SDK builder     The MCUXpresso SDK brings open-source drivers, middleware, and reference example application to speed your software development. 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.  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. Config Tools    MCUXpresso Config Tools, an integrated suite of configuration tools, these configuration tools allow developers to quickly build a custom SDK and leverage pins, clocks and peripheral to generate initialization C code or register values for custom board support. SDK Examples for Wireless MCUs    The wireless examples feature many common Bluetooth configurations.
View full article
SC16is752 is a I2C to dual UART bridge, it is often used to expand UART interface when SoC UART can't provide sufficient interfaces, some users also select the chip to connect Bluetooth UART, in the article, the following 4 contents will be described. 1. Hardware connections (1) i.MX8MP-EVK--->SC16IS752---->nxp  IW416-EVK UART (2)i.MX8MP-EVK--->SC16IS752 (CPU UART <--->SC16IS752 UART Channel A) 2. Software configurations (1) Kernel options (2) SC16IS752 device tree 3. UART Test  Transmitting data between CPU uart3 & SC16is752 UART_A 4. Bluetooth test UART_A of SC16IS752 is connected to IW416 BT UART, and make a file transmission between PC & IW416 using obexd & obexctl tool.   NXP TIC Connectivity Team Weidong Sun Oct-28-2024
View full article
HCI Application is a Host Controller Interface application which provides a serial communication to interface with the KW40/KW41/KW3x/QN9080 BLE radio part.   It enables the user to have a way to control the radio through serial commands.   The format of the HCI Command Packet it’s composed by the following parts.   Figure 1. HCI Command Packet   Each command is assigned a 2 byte Opcode which it’s divided into two fields, called the OpCode Group Field (OGF) and OpCode Command Field (OCF).   The OGF uses the upper 6 bits of the Opcode, while the OCF corresponds to the remaining 10 bits.   The OGF of 0x3F is reserved for vendor-specific debug commands. The organization of the opcodes allows additional information to be inferred without fully decoding the entire Opcode.    For further information regarding this, please check the BLUETOOTH SPECIFICATION Version 5.0 | Vol 2, Part E, 5.4 EXCHANGE OF HCI-SPECIFIC INFORMATION.    This document will guide you through the implementation of custom HCI commands in the KW36, but it can be applied as well for the rest of the NXP Bluetooth LE MCU’s that support HCI.   The following changes were made and tested in the FREEDOM KW38 and will generate a continuous with both channel and power configurable.      You will need to perform the following changes to the HCI black box demo.   Modify the hci_transport.h public constants and macros section by adding:   #define gHciCustomCommandOpcodeUpper (0xFC90) #define gHciCustomCommandOpcodeLower (0xFC00) #define gHciInCustomVendorCommandsRange(x) (((x) <= gHciCustomCommandOpcodeUpper) && \ ((x) >= gHciCustomCommandOpcodeLower))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   In this case, the opcodes 0xFC90 to 0xFC00 are not used by our stack. These opcodes meet the requirements for vendor specific commands (OCF = 3F).   Then you will need to declare the handler for the custom command.   void Hcit_InstallCustomCommandHandler(hciTransportInterface_t mCustomInterfaceHandler);‍‍‍‍‍     In the  hcit_serial_interface.c modify the following :   Add in the private memory declarations section   static hciTransportInterface_t mCustomTransportInterface = NULL;‍‍‍‍‍ Change the Hcit_SendMessage as it is shown:   static inline void Hcit_SendMessage(void) { uint16_t opcode = 0; /* verify if this is an event packet */ if(mHcitData.pktHeader.packetTypeMarker == gHciEventPacket_c) { /* verify if this is a command complete event */ if(mHcitData.pPacket->raw[0] == gHciCommandCompleteEvent_c) { /* extract the first opcode to verify if it is a custom command */ opcode = mHcitData.pPacket->raw[3] + (mHcitData.pPacket->raw[4] << 8); } } /* verify if command packet */ else if(mHcitData.pktHeader.packetTypeMarker == gHciCommandPacket_c) { /* extract opcode */ opcode = mHcitData.pPacket->raw[0] + (mHcitData.pPacket->raw[1] << 8); } if(gHciInCustomVendorCommandsRange(opcode)) { if(mCustomTransportInterface) { mCustomTransportInterface( mHcitData.pktHeader.packetTypeMarker, mHcitData.pPacket, mHcitData.bytesReceived); } } else { /* Send the message to HCI */ mTransportInterface( mHcitData.pktHeader.packetTypeMarker, mHcitData.pPacket, mHcitData.bytesReceived); } MEM_BufferFree( mHcitData.pPacket ); mHcitData.pPacket = NULL; mPacketDetectStep = mDetectMarker_c; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Implement the registration of the handler void Hcit_InstallCustomCommandHandler(hciTransportInterface_t mCustomInterfaceHandler) { OSA_EXT_InterruptDisable(); mCustomTransportInterface = mCustomInterfaceHandler; OSA_EXT_InterruptEnable(); return; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍    Once those changes are done, we will need to modify the  hci_black_box.c with the following changes.    Add the files to support HCI Custom commands.   #include "hci_transport.h" #include "fsl_xcvr.h"‍‍‍‍‍‍‍‍‍‍   Define the custom commands, in this case, we will create some to turn ON/OFF the continuous wave as well as to set up the channel and power.    //@CC custom command #define CUSTOM_HCI_CW_EVENT_SIZE (0x04) #define CUSTOM_HCI_EVENT_SUCCESS (0x00) #define CUSTOM_HCI_EVENT_FAIL (0x01) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Also, adding some app auxiliar variables  static uint16_t channelCC = 2402; static uint8_t powerCC = 0x3E;   Create the custom event packet    uint8_t eventPacket[6] = {gHciCommandCompleteEvent_c, CUSTOM_HCI_CW_EVENT_SIZE, 1, 0, 0, 0 };‍‍‍‍‍   In the main_task() after the BleApp_Init() register the callback for the custom commands.   /* Initialize peripheral drivers specific to the application */ BleApp_Init(); //Register the callback for the custom commands. Hcit_InstallCustomCommandHandler(BleApp_CustomCommandsHandle);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Once that it’s added, add the handler for the command   bleResult_t BleApp_CustomCommandsHandle(hciPacketType_t packetType, void* pPacket, uint16_t packetSize) { uint16_t opcode = 0; uint8_t error=0; switch(packetType) { case gHciCommandPacket_c: opcode = ((uint8_t*)pPacket)[0] + (((uint8_t*)pPacket)[1] << 8); if (opcode >= 0xfc00 & opcode <= 0xfc50) { channelCC = 2400+(opcode - 0xfc00); eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else if (opcode <= 0xfc70) { powerCC = (opcode-0xfc50)*2; if (gXcvrSuccess_c ==XCVR_ForcePAPower(powerCC) eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; else eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } else if (opcode == 0xfc80) { if (gXcvrSuccess_c == XCVR_DftTxCW(channelCC*1000000)) { eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } else if(opcode == 0xfc90) { XCVR_ForceTxWd(); /* Initialize the PHY as BLE */ XCVR_Init(BLE_MODE, DR_1MBPS); eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else { eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } eventPacket[3] = (uint8_t)opcode; eventPacket[4] = (uint8_t)(opcode >> 8); Hcit_SendPacket(gHciEventPacket_c, eventPacket, sizeof(eventPacket)); break; default: break; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍} The format of this HCI command is: 01 XX FC 00 Where: When 0<=XX<=50: set the transmitting channel. The transmitting frequency is (2400+XX (in hexadecimal) )*1000MHz When 50<xx<70: set the transmitting power. 51 is the minimum Tx power and 69 corresponds to the maximum Tx power. When XX = 80: start the CW transmission When XX = 90: Stop the CW transmission   For example, if you want to transmit a CW on the frequency 2420MHz at maximum frequency, you should send the following command: 01 14 FC 00 01 69 FC 00 01 80 FC 00   whenever you want to change the channel or Tx power, please stop the ongoing Tx first by sending 01 90 FC 00 Then repeat the previous step.   If you want to add some parameter to it, please consider that the fourth byte of the packet will correspond to the number of parameters to enter and you will need to indicate it there. 
View full article
Where to find Wi-Fi Software Drivers   NXP Recommends using Wi-Fi source code drivers available from GitHub based on the following decisions:     Software Drivers NXP Processor Linux software drivers on NXP host processor (i.MX6, 7, 8 or 9) Driver: GitHub - nxp-imx/mwifiex: WiFi extensions Radio firmware: GitHub - nxp-imx/imx-firmware Pre-built binary demo files for each quarterly BSP release are available here: Linux: Embedded Linux for i.MX Applications Processors | NXP Semiconductors Android: Android OS for i.MX Applications Processors | NXP Semiconductors Software Drivers NXP Microcontrollers RTOS software drivers on NXP host processor (MCX, MCU, or i.MX RT) Wi-Fi driver: GitHub - NXP/wifi_nxp: NXP Wi-Fi driver and networking utilities Bluetooth middleware: GitHub - nxp-mcuxpresso/mcux-sdk-middleware-edgefast-bluetooth: EdgeFast Bluetooth PAL Software Drivers Non-NXP Processor Non-nxp host processor with Linux or Android Driver: GitHub - nxp-imx/mwifiex: WiFi extensions Radio firmware: GitHub - nxp-imx/imx-firmware Software Drivers Non-NXP Microcontrollers Non-nxp host MCU RTOS Link: https://www.keil.arm.com/packs/wifi-nxp/versions In addition to GitHub, RTOS drivers are available on NXP web site and as an Open CMSIS Pack from ARM: SDK BUILDER mcuxpresso.nxp.com/en/welcome NXP Website Available in SDK Builder on nxp.com Distributed in .zip folder alongside entire SDK    OPEN-CMSIS-PACKS www.keil.arm.com/packs/wifi-nxp/versions/ ARM Open-CMSIS Pack NXP Wi-Fi driver CMSIS Pack Distributed as ARM CMSIS pack   Linux Drivers are available as a .ZIP folder from each of the Wi-Fi specific product pages.
View full article
/*** 2024 October 15th latest disclaimers:  - KW47, MCX W72 are direct derivative from KW45 and MCX W71  - please bookmark this page for future update - this article is for early enablement based on KW45, K32W148, MCX W71 and is pending updates up to wider releases of new KW47 and MCX W72 in 2025 -- Datasheet, Reference Manual and HW manufacturing files shared on request--  ***/ Please, find the important link to build a PCB using a KW47 or MCX W72 and all concerning the radio performances, low power and radio certification (CE/FCC/IC).   KW47 product NXP web page:  pending release of KW47/MCXW72  MCXW72 product NXP web page: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/mcx-arm-cortex-m/mcx-w-series-microcontrollers/mcx-w72x-secure-and-ultra-low-power-mcus-for-matter-thread-zigbee-and-bluetooth-le:MCX-W72X KW-MCXW-EVK getting started NXP web page pending release of KW47/MCXW72  KW47-LOC getting started NXP web page pending release of KW47/MCXW72  MCXW72-LOC getting started NXP web page pending release of KW47/MCXW72     HARDWARE   KW47 MCX W72 EVK board: attached     KW47 LOC Channel Sounding board - diagram: attached     KW47-MCXW72-EVK HW guideline: Available on request        HVQFN48 package specification: SOT619-17(D)   pending release of SOT619-17(DD)       KW47-MCXW72-EVK User Manual pending release of KW47/MCXW72        Minimum BoM (attached file) >> KW45 applicable for KW47 waiting release of KW47/MCXW72      DCDC management guide (AN13831) : KW45/K32W148 - Power Management Hardware (nxp.com) KW45 applicable for KW47 waiting release of KW47/MCXW72      Design-In check list: see attached file at the bottom of this article     RF matching: S parameters (attached file) pending release of KW47/MCXW72    Information: “As RF behavior are dependent of PCB layout & manufacturing; PCB prototypes (based on NXP recommendations) will have to be fine-tuned to insure the expected qualified in RF is reached on the final productized platform.”   RADIO     RF report: KW45 and K32W148 RF System Evaluation Report for Bluetooth LE and K32W148 for 802.15.4 Applications ...  pending release of KW47/MCXW72 - available ON DEMAND     Radio co-existence: Kinetis Wireless Family Products Bluetooth Low Energy Coexistence with Wi-Fi Application (nxp.com) pending release of KW47/MCXW72      Distance performances: refer to attached file pending release of KW47/MCXW72      Antenna:  Compact Planar Antennas for 2.4 GHz Communication Designs and Applications within NXP EVK Boards Antennas for Channel Sounding Applications     BLE connectivity test binary file:  available in SDK on demand      Return loss (S11) measurement: How to measure the return loss of your RF matching (S11) part of the RF report (AN13728)     Loadpull: pending release of KW47/MCXW72   SW tools for RF trials:     IoT Tool box (mobile application)     Connectivity test tool for connectivity products (part of the IoT toolbox)     DTM: How to use the HCI_bb on Kinetis family products a... - NXP Community https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-...   CRYSTAL   Article : KW45/K32W1 32MHz & 32kHz Oscilllation margins - NXP Communitypending release of KW47/MCXW72     Recommended Crystal attached LowPower      Estimator Tool https://community.nxp.com/t5/Wireless-Connectivity/Kinetis-KW35-38-KW45-amp-K32W1-MCXW71-Power-Profi... pending release of KW47/MCXW72       Low Power Consumption: https://www.nxp.com/docs/en/application-note/AN13230.pdf pending release of KW47/MCXW72     CERTIFICATION pending release of KW47/MCXW72  
View full article
This article gives detailed hands-on steps about how to do Bluetooth A2DP music playing and Wi-Fi 2.4G iperf throughout coexist test. The hands-on test is based on 88W8997 with I.MX8MQ which is based on Linux 5.15.71 host platform. Using driver is  Q1-2024 released Wi-Fi driver + Q1-2024 released FW version. You can refer to this article to do similar Bluetooth A2DP music playing and Wi-Fi 2.4G iperf throughout test on other Wi-Fi/Bluetooth chips based on other Linux platform. For detailed steps, please refer to attached pdf file.   Best regards, Christine.
View full article
Sometimes, we need to assign a static IP to Wi-Fi chip which is working in STA mode to do test based on Linux platform. In this article, shared the steps to assign a static IP address for 88W8997 which is working in STA mode based on Linux. And you can also refer this method to set static IP for other Wi-Fi chips.
View full article
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.
View full article
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.
View full article
 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.        
View full article
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
View full article
On the KW45 product, there is a way to enable the 32kHz clock without using a crystal externally. Indeed, a FRO32K can be used instead. this article proposes to show you at a glance how to activate it and which performances to expect in comparison to a 32kHz crystal.  This Crystal-Less mode allows to reduce the cost of the system, without compromising the 32 kHz clock accuracy thanks to a software calibration mechanism called SFC standing for Smart Frequency Calibration. One other advantage of the FRO32K is the shorter start up time, including the calibration. The FRO32K clock is calibrated against the 32 MHz RF oscillator through the Signal Frequency Analyzer (SFA) module of KW45. Software enablement: The Crystal-less feature is available since the SDK version 2.12.7 (MR4) , all measurements in this document are done with softwares based on this version of SDK. To enable the Crystal-Less mode, simply define the compilation flag gBoardUseFro32k_d to 1 in board_platform.h or in app_preinclude.h. In this mode, the SFC module measures and recalibrates the FRO32K output frequency when necessary. This typically happens at a Power On Reset, or when the temperature changes, or periodically when the NBU is running. By using this mode, higher power consumption is expected. The FRO32K consumes more power than the XTAL32K in low power mode (around 350nA), and the NBU wakes up earlier while FRO32K is used, which also entails a higher power consumption.   FRO32K vs Xtal32K performances: For these measurements, we used an early FRO32K delivered feature but, even if it is still in experimental phase, the results below will already give you some information.    Clock accuracy at room temperature:    In steady state, the output frequency of the FRO32K is even more stable than that of the XTAL32K thanks to the SFC module. The clock frequency accuracy of the XTAL32K is a bit better than the FRO32K, however, both are within the permitted accuracy range and are compliant with the Bluetooth Low Energy specification. Clock accuracy after recalibration (triggered by a temperature variation):   This test proved that the FRO32K provided a source clock that is within the target accuracy range even during a temperature variation. Throughput test at room temperature: Throughput measurements are performed using two different clock sources to verify if there is any connection lost due to the potential clock drift entailed by using the FRO32K as a clock source. The BLE_Shell demo application is used for the throughput measurement. (refer to KW45-EVK Software Development Kit). The DUT is programmed with software using either the XTAL32K or the FRO32K as the source clock. After the communication establishment, the bit rate measurement is triggered manually, and the result is displayed on the prompt window.  Results: Two clock configurations show identical performance, which proves that the 32 kHz crystal-less mode presents no disconnection and no performance degradation. Throughput test over a temperature variation: it is the same test set up as above but within a 60 °C temperature variation. The results are identical to previous ones. No disconnection or performance degradation is detected. Conclusion Various tests and measurements proved that the FRO32K can be used as the 32 kHz clock source instead of the XTAL32K, with the help of the SFC module. It is capable of providing an accurate and stable 32 kHz clock source that satisfies the requirements of connectivity standards. However, please note that this feature is still in experimental phase, tests are still ongoing to ensure that the feature is robust in any circumstances. Customers who want to enable this feature in production must validate this solution according to their own use cases. For more detailed information, a draft version of the application note is attached to this article but an updated version will be available on NXP.com website when a new SDK is released.
View full article
Default init case By default, when no country regulatory setting is defined, we use WW (World Wide safe setting, meaning we only transmit on bands which are allowed worldwide, with the TX power compatible with all countries regulations)   Setting country 1/ When operating in AP mode: - we usually set country code (ex : country_code=JP) in hostapd.conf to define the country. - this country definition will be advertised to all connected STA if ieee80211d=1 is set in hostpad.conf - the country can also be set with "iw reg set" command   2/ When operating in STA mode - country code can be set with "iw reg set" command or in wpa_supplicant.conf (ex : country=jp) - once connected to the AP (with 80211d enabled), the STA will switch to the AP country setting (this behaviour can be disabled by adding country_ie_ignore=1 driver parameter)   Once country is set: - we will only transmit on channels allowed for that country - with country maximum TX power - we might use DFS feature on channels declared as DFS channels for that specific country   TX power settings   1/ By default, using Linux regulatory settings (/lib/firmware/regulatory.db, generated from db.txt) These settings define allowed channels, DFS flags and max TX power on a country basis See section "Regulatory db" further.   2/ Linux regulatory settings can be overwritten by: a. cntry_txpwr=0 and txpwrlimit_cfg=nxp/txpower.bin driver param (generated from txpower.conf (channel/MCS->txpower), see AN13009) Same setting for all countries (static). Using channels/flags from db.txt, and minimum TX power between db.txt and txpower.bin/rgpower.bin b. cntry_txpwr=1 (look for nxp/txpower_XX.bin files (generated from txpower.conf (channel/MCS->txpower), see AN13009) Need one txpower_XX.bin file for each country XX (dynamically loaded, for instance with iw reg set XX) Using channels/flags from db.txt, and minimum TX power between db.txt and txpower_XX.bin   cntry_txpwr txpwrlimit_cfg TX power limit Method 0 nxp/txpower.bin nxp/txpower.bin (static) V1 1 - nxp/txpower_XX.bin (dynamic) V1 cfg     We have default TX power tables, but customer can tune these TX power settings, based on their HW. Please refer to "AN13009 Wi-Fi Tx Power Management in Linux"       Regulatory db   Source https://wireless.wiki.kernel.org/en/developers/Regulatory/wireless-regdb   Wifi regulatory setting (allow channels, etc) are defined in db.txt, then converted to regulatory.db (store in /lib/firmware) We can get official db.txt from here, and build regulatory.db with below command   git clone git://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git make   Kernel regulatory.db integrity is checked by the Linux kernel. Disabling REGDB signature check with the folllowing kernel config: CONFIG_EXPERT=y CONFIG_CFG80211_CERTIFICATION_ONUS=y # CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not set   Rebuilding kernel and flashing scp Image root@192.168.0.2:/run/media/mmcblk0p1/      iw reg command examples and other notes   root@imx8mqevk:~# iw reg get global country 00: DFS-UNSET         (2402 - 2472 @ 40), (N/A, 20), (N/A)         (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN         (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN         (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN         (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN         (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN         (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN         (57240 - 63720 @ 2160), (N/A, 0), (N/A) root@imx8mqevk:~# iw reg get global country FR: DFS-ETSI         (2400 - 2483 @ 40), (N/A, 20), (N/A)         (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW         (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW         (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS         (5725 - 5875 @ 80), (N/A, 13), (N/A)         (57000 - 66000 @ 2160), (N/A, 40), (N/A)   By default (if no country is set), we are using the world domain. this is the most restrictive. Then you can set the country (using driver module parameter, wpa_supplicant.conf, etc) or get the country automatically provided by the access point (80211d). This will update the regulatory domain, meaning the allowed channels, etc. You can check the country settings with "iw reg get" command.   The regulatory domain has priority, compared to the channel list you would set in the wpa_supplicant.conf.  
View full article
      The article will describe how to configure Access Point Based On NXP platform and WIFI chipset step by step. Users can easily make her AP based on NXP WIFI module work normally by following steps in the article. 1. Environment for the validation - Hardware Platform     i.MX8MN-EVK - Software    Kernel version: L5.4.70_2.3.0    rootfs : imx-image-multimedia -WiFi module   AW-CM358SM: NXP 88W8987 chipset 2. Diagram for Connections   For More detailed information, See attached document, please!   NXP CAS-TIC Wireless MCU team Weidong sun 04-16-2021  
View full article
CMSIS, the ARM Cortex Microcontroller Software Interface Standard, can be used to distribute software components in standard package format. CMSIS compliant software components allow: • Easy reuse of example applications or template code • Combination of SW components from multiple vendors CMSIS packages available here: https://www.keil.arm.com/packs/ NXP WiFi package available here: https://www.keil.arm.com/packs/wifi-nxp/versions/   Getting NXP WiFi/BT software   Please find the minimal setup required to download the NXP WiFi/BT software CMSIS packs: First, get cpackget binary from the Open CMSIS Pack toolbox binaries Then, install the NXP WiFi and Bluetooth packages and their dependencies using below commands cpackget add NXP::WIFI@2.0.0 cpackget add NXP::WIRELESS_WPA_SUPPLICANT@2.0.0 cpackget add NXP::EDGEFAST_BT_BLE@2.0.0   Please note that the CMSIS software packs are installed in below directory: ~/.cache/arm/packs/NXP/   Building NXP WiFi/Bluetooth software   Using combined WiFi+Bluetooth application on i.MXRT1060-revC board, as an example.   Prerequisite Follow below steps to install all the required tools to get CMSIS packages and build them . <(curl https://aka.ms/vcpkg-init.sh -L) . ~/.vcpkg/vcpkg-init vcpkg new --application vcpkg add artifact arm:cmsis-toolbox vcpkg add artifact microsoft:cmake vcpkg add artifact microsoft:ninja vcpkg add artifact arm:arm-none-eabi-gcc vcpkg activate Refer to CMSIS toolbox installation documentation    Activate required tools . ~/.vcpkg/vcpkg-init vcpkg activate Install the NXP i.MXRT1060-REVC Bluetooth examples and their dependencies cpackget add NXP::MIMXRT1060-EVKC_EDGEFAST_BLUETOOTH_Examples@1.0.0 Workaround: current NXP SW is aligned with ARM::CMSIS@5.8.0, and does not support latest ARM::CMSIS@6.0.0, so we need to use older version with below commands cpackget rm ARM::CMSIS@6.0.0 cpackget add ARM::CMSIS@5.8.0 List the installed packages cpackget list Building combined WiFi+BT example application Copy example application to local directory and provide write permissions mkdir -p ~/test cp -r ~/.cache/arm/packs/NXP/MIMXRT1060-EVKC_EDGEFAST_BLUETOOTH_Examples/1.0.0/boards/evkcmimxrt1060/edgefast_bluetooth_examples/wifi_cli_over_ble_wu/ ~/test/ cd ~/test/wifi_cli_over_ble_wu/ && chmod -R u+w .   Build the application csolution convert wifi_cli_over_ble_wu.csolution.yml cbuild wifi_cli_over_ble_wu.flexspi_nor_debug+armgcc.cprj Convert elf to bin for flashing cd armgcc/flexspi_nor_debug arm-none-eabi-objcopy wifi_cli_over_ble_wu.elf -O binary wifi_cli_over_ble_wu.bin
View full article
Generality on the Oscillation Margin Outline It is a margin to the oscillation stop and the most important item in the oscillation circuit. This margin is indicated by ratio based on the resistance of crystal, and it shows how amplification oscillation capability the circuit has. The oscillation circuit can theoretically operate if the oscillation margin is 1 or more. However, if oscillation margin is close to 1, the risk of operation failure will increase on module due to a too long oscillation start up time and so on. Such problems will be able to be solved by a larger oscillation margin. It is recommended to keep 3 times or more as oscillation margin during the startup of the oscillation. Factor of 10 is commonly requested for Automotive at startup and 5 for IoT market. However, some providers accept to have 3 times as oscillation margin for steady state. Here below is an oscillation example to explain better the phenomenon: At start up, the configuration is set internally by the hardware in order to be sure to start the oscillation, the load capacitor is 0pF. After this time, it is the steady state and the load capacitor from the internal capabank is taken into account.     If load capacitor is not set correctly with the right oscillator gain, the oscillation will not be maintained after the start up.   The oscillator gain value will also depend on the resisting path on the crystal track.  A good way to evaluate it is to add a resistor on the crystal path and try to launch the oscillation. In the SDK, the gain and the load capacitor can set directly in the application code.   Calculation The oscillation margin is able to be calculated as follows: The oscillation margin calculation is based on the motional resistor Rm by formula below :               Example: for the EVK board’s 32kHz crystal (NX2012SE) ESR   80000,0 ohm Rm1   79978,2 ohm Lm1    3900 H Cm1   6,00E-15 F C0      1,70E-12 F CL      1,25E-08 F fr        32901,2 Hz fosc    32771 Hz Series Resistor Rsmax      7,50E+05 Ohm Oscillation Margin   10,3   Measurement Requirements for measurement PCB Crystal unit (with equivalent circuit constants data) Resistors (SMD) Measurement equipment (Oscilloscope, Frequency counter or others capable to observe oscillation) Add a resistor to the resonator in serial and check if the oscillation circuit works or not. If the oscillation is confirmed by 2), change the resistor to larger. If there is no oscillation, change the resistor to smaller. Find out the maximum resistor (=Rs_max) which is the resistor just before the oscillation stop. Measure the oscillating frequency with Rs_max. Calculate the oscillation margin based on the Rs_max.   Notes The Oscillation margin is affected not only by crystal characteristics but also parts that compose the oscillation circuit (MCU, capacitor and resistor). Therefore, it is recommended to check the oscillation margin after the MCU functionality is checked on your module. The series resistor is only for the evaluation. Please do not use this resistor in actual usage. It is recommended to check the functionality of your module also. It is possible that the module does not work correctly due to a frequency shift on oscillation circuit and so on. Jig and socket could be used in measurement, but stray of them will give influence for oscillation margin.   KW45/K32W1 product oscillation margin overview 32MHz crystal NXP recommends to use the quartz NDK NX1612SA (EXS00A-CS14160) or NDK NX2016SA (EXS00A-CS14161) to be compliant with the +/-50ppm required in Bluetooth LE. Using the current SDK, NXP guarantees an oscillation margin of 10 for startup commonly used by Automotive customers and 3 for steady state. Higher oscillation margin can be reached by using higher ISEL and CDAC parameters with some drawback respectively on the power consumption and the clock accuracy. ( the load capacitance bank (CDAC) and the oscillator amplifier current (ISEL)) NDK recommended / target values for oscillation margin is informed case by case. On general basis requested oscillation margin has to be between recommended value and 3 times this value. "NDK quartz provider (FR) explains this oscillation margin specification is only mandatory at the start-up phase, not at the steady state. Starting the oscillation is the phase that needs more energy. That's why the gain of the oscillator gain is at the maximum value which means not optimal consumption. When the oscillation stability is reached, the gain could be reduced to save power. The oscillation will not be affected.  Keep in mind a quartz oscillates by mechanical effect. So, when the oscillation is starting you need the highest energy to emulate it. By its own inertial, you need less energy to maintain the mechanical oscillation. NDK provides a good picture of this. Starting up a crystal into oscillation is like a train what you would like to start moving. At the beginning the train is stopped and you need a lot of energy to start running. When the train is running at its nominal speed, you need less effort to maintain that movement and a very big effort to stop it completely."   Example: for the oscillation margin 10 (Series Resistor Rsmax = 560W) The CDAC/ISEL area where the oscillation starts and propagates in the internal blocks is defined (‘oscill’) in the table below.     32kHz crystal NXP recommends to use the quartz NDK NX2012SE (EXS00A-MU01517) or NDK NX2012SA (EXS00A-MU00801) to be compliant with the +/-500ppm required in Bluetooth LE. using the current SDK, the oscillation margin with this quartz is 10 with some limitation on the Crystal load capacitance selection (Cap_Sel) and the Oscillator coarse gain amplifier (ESR_Range) values, with some drawback respectively on the power consumption and the clock accuracy. For an oscillation margin at 10 for instance, the Capacitor value from the databank (CapSel) is limited (green area) as shown in the graph below: Example:  for an oscillation margin at 6.4, if the load cap is set at 14pF and the ESR_Range to 3, the 32kHz frequency accuracy will be around 91ppm. From this point, the oscillation margin can be enlarged to 10.3 by decreasing the load cap to 10pF but the accuracy will be degraded (183ppm). For an Oscillation margin at 10, the graph below is showing the ESR_Range versus the load cap. The possible load cap variation range (in green) is larger when the ESR_Range increases:   Example: at oscillation margin 10.3, the clock accuracy can be improved from 213ppm to 183ppm by setting the ESR_range 2 to an ESR_Range 3 but the current consumption will be increased to 169.5nA. An other important point is that for a given ESR_Range value, getting higher the load cap is much more increasing the current than in the example above.   Remark: Under a high oscillation margin condition, the crystal voltage will be smaller.   Other possible ways to improve the oscillation margin exist: - Use external capacitor instead of internal capacitor banks. Oscillation margin goes up to 10. - Use the internal 32kFRO is supported for BLE (target:+/-500ppm)
View full article
       The article will describe how to configure A2DP audio application Based On NXP platform and WIFI/BT chipset step by step. Users can easily make her A2DP audio based on NXP WIFI module work normally by following steps in the article. Environment for the validation Hardware Platform        i.MX8MN-EVK Software Kernel version: L5.4.70_2.3.0 rootfs : imx-image-multimedia WiFi module        AW-CM358SM: NXP 88W8987 chipset   For more detailed information, see attachment, please!   NXP CAS-TIC wireless MCU team Weidong Sun    
View full article
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
View full article
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!
View full article