This patch fix the issue in hdmi dongle JB4.2.2_1.1.0-GA release that wifi((STA+P2P)/AP) cann't be enabled properly. In the root directory of Android Source Code, use the following command to apply the patch: $ git apply hdmi_dongle_wifi_jb4.2.2_1.1.0.patch

The SMAC & IEEE 802.15.4 protocol stacks are a KSDK add-on, therefore you need the installation of the KSDK 1.2 before installing these connectivity stacks. Install the Kinetis SDK 1.2: Software Development Kit for Kinetis MCUs|Freescale After installing the KSDK 1.2, download the desired protocol stack. The connectivity software for this platform can be found in the board webpage, in the downloads tab: Modular Reference Boards for Kinetis KW0x|Freescale The installation window will guide you through an easy way to install the software. Best regards, Luis Burgos.

Document Purpose This post entry provides an example of a hybrid application (Wireless_UART + GFSK Advertising) by covering Bluetooth Low Energy multiple node connections in parallel with GFSK (Generic Frequency Shift Keying) communication.  This is an additional example for the SDK where we have defined a Hybrid application for Bluetooth LE advertising and scanning in parallel with GFSK communication. Audience The goal of this post is to serve as a guide for software developers who want to use, adapt and integrate GFSK functionality in a Bluetooth Low Energy application.    Setting up the development environment Toolchain:           - IAR Embedded Workbench 8.32 or newer;            https://www.iar.com/iar-embedded-workbench/   SDK:          - This version of firmware has been tested using SDK_2.2.1_FRDM-KW36, that can be downloaded using the following link: https://mcuxpresso.nxp.com/en/select            (please consider to select as Toolchain/IDE: All toolchains);             Hardware:       - 2 to 5 FRDM-KW36 development board:  FRDM-KW36 Development Kit KW36/35 MCUs | NXP  Implementation This demo application is design for the FRDM-KW36 platform and can be easily integrated into any board that is using KW35/36 MCU family. The functionality is based on the coexistence mechanism available on the SDK (Mobile Wireless System - MWS module). Based on the HW link-layer implementation, the Bluetooth Low Energy has a higher priority than the GFSK protocol and as the effect, the GFSK communication is executed during the Idle states (inactive periods) of the Bluetooth LE.  For more details related to the MWS module, please refer to connectivity framework documentation from SDK (Connectivity Framework Reference Manual.pdf). As for functionality on the Bluetooth low energy, both roles, central and peripheral, are supported.  Integration to the KW36 SDK - download the attached file and unzip to ...\SDK_2.2.1_FRDM-KW36\boards\frdmkw36\wireless_examples\hybrid folder: - open IAR project (SDK_2.2.1_FRDM-KW36_2019_07_19\boards\frdmkw36\wireless_examples\hybrid\ble_w_uart_gfsk\freertos\iar\ble_w_uart_gfsk_freertos.eww). - the project is organized like below: Functionality Switches functionality:     - functionality is defined in main.c file, BleApp_Handle Keys function;    - on the FRDM-KW36 we have:                 - SW2 - start scanning - Central device;                 - Long SW2 - start advertising - Peripheral device; (long SW2 - SW2 pressed for more than 3 seconds)                 - SW3 - start/stop GFSK TX operation (advertising);                 - Long SW3 - start/stop GFSK RX operation (long SW3 - SW3 pressed for more than 3 seconds) Logs:    - Serial events for different states of the board;    - BaudRate 115200; Validation The solution has been validated using 1 Master and 4 Slave devices as below: 1. Create the network:     a. Open serial communication of all devices. After reset you will see the following message:    b. On the Central device press SW2 to start scanning;    c. On the Peripheral device press Long SW2 to start advertising and wait for the confirmation on the serial port:   d. Repeat steps b. and c. for all of the slave devices.   e. When the network is completed on the Central device you will see something like below:   f. Check the over the air connections (connection interval = 312.5 ms): 2. Validate functionality on the Bluetooth LE: - from each slave (Peripheral) serial terminal write a message (e.g: testslaveX) and check that the message is printed on the master serial port. - do the same test from the master (Central) serial terminal. - Below is an example of this step:   - over the air log: 3. Initiate GFSK communication: - in one of the board's press SW3 to start GFSK TX operation (Advertising packet with AdvAddress = 0909090909); At every 1 second (gGenFskApp_TxInterval_c), an ADV packet will be sent over the air. - Select other board and press Long Sw3 to initiate GFSK RX operation (RX interval = 100ms = gGenFskApp_RxInterval_c); - Each time an ADV packet from address = 0909090909 is received this will be listed on the serial port as below: - over the air the GFSK TX packets will be listed as a ADV_NONCONN_IND: 4. Validate Bluetooth LE in parallel with GFSK: - write a message on the Master (Central) serial terminal and check the feedback on the slave(Peripheral) serial terminals: Attached is the source code for this application. Regards, Ovidiu

Blue Ravens (Bluetooth Ranging Access Vehicle Enablement System) is a system solution developed by NXP to assist customers in designing their own BLE-based car access solutions using NXP products. It is designed to support a variety of car access use cases through a modular approach. The main objective (but not limited) is to present all the capabilities and advantages of the Channel Sounding technology and NXP BLE Handover in an automotive use case. Channel Sounding is part of the new Bluetooth Low Energy (BLE) standard (BLE 6.0) as a highly accurate distance measurement solution, and available on the NXP KW47 chip. BLE Handover is an NXP proprietary feature developed by NXP to seamlessly transfer a BLE connection from one device to another, without disconnection, using and out of band channel (e.g. CAN). This transfer does not impact the peer device so interoperability is guaranteed. This feature can also be used to enable BLE connection RSSI sniffing to increase RSSI based system security. (KW45 & KW47) Thanks to its modularity, this system can be used to address multiple use-cases, from simple BLE connection system, up to a full BLE Channel Sounding positioning system. Please, note that Channel Sounding is only supported on KW47 chip. KW45 can only be used for simple BLE system. By default, the system on KW47 covers a basic use of Channel Sounding to measure the distance between one remote device (Digital Key) and alternatively several different fixed devices (Car Anchor). At each instant in time, only one anchor is connected to the Digital Key. The other anchors (not connected) can be set in Connection RSSI Sniffing mode (based on Handover). This mode increase the system security by accessing the RSSI value of a connection instead of an advertising packet. These RSSI values can be used to estimated which anchor can be used in the round-robin or to keep the best BLE link around the Car.     The system is composed of multiple KW4x boards, each with a specific role. On board is used as Digital Key, to be caried by the user, the other represent the Car sub-system. On this Car Sub-system, all boards are connected to each other using the CAN bus. The CAN bus fulfills the purpose to power all boards with 12V and to allow communication between the boards: Control Unit (KW4x EVK-Board) Car Anchors (KW4x LOC-Board) Digital Key (KW4x LOC-Board) Role: Central decision-making node Functionality: - Coordinates BLE anchors. - Triggers actions based on received data   Role: BLE devices connected to the Control Unit via CAN bus Functionality: - Advertise BLE presence. - Wait for a Digital Key to connect. - Act as CS initiators during the session. Role: Acts as the remote BLE device Functionality: - Scans for BLE anchors. - Initiates connection with a Car Anchor. - Once connected, behaves as a CS reflector.     A Desktop application is used to monitor the states and monitor the measurement done by the system:   Using the successive measurement on each anchors, the Car sub-system is able to estimate the Digital Key position (Disclaimer: this solution is not consider accurate in dynamic environments)       Features   BLE connection Supporting 1 connection only for now (multiple peer plan) BLE Channel Sounding (KW47 only) Yes RSSI Sniffing Yes – All not connected anchors Automatic exclusion of suboptimal anchors Yes BLE Handover with CS context (No CS repeat) Yes Trilateration algorithm Yes Measurement filtering (real time) Yes Detection area triggering action (e.g. Welcome zone) Yes Car Anchor CAN Synchronization (radio core sync) No (planned for next release) Channel Sounding Sniffing No (feasibility study ongoing)   KPIs   Number of Anchor From 2 to 8 Number of Digital Key 1 BLE Connection Interval 7.5ms – 4s (Default = 30ms) BLE Handover connection transfer time (+CS context transfer) <60ms (CI=30ms) <50ms (CI=10ms) CS start Delay (2+7)*CI CS measurement and data transfer (Real Time) <70ms (CI=30ms) CS Algo <30ms Full cycle time (CS + Handover) [Algorithm runs asynchronously on the anchor after the handover is finished] 390ms (CI=30ms) 190ms (CI=10ms) Line Of Sight CS measurement range 100m Max (at 10dBm) Back Pocket CS measurement range 10m (at 10dB)   This solution is under development and improvement will be added in the future releases. This system can also be enhanced with Ultra-Wide Band support. For access, please contact pascal.bernard@nxp.com  

Hello community, This time I bring to you a document which explains what are the ZigBee Test Client commands and how to use it. Before to read this guide, I widely recommend to take a look into the document Running a demo with BeeKit (802.15.4 MAC, SMAC and ZigBee BeeStack). This guide requires the BeeKit Wireless Connectivity Toolkit​ and the Test Tool for Connectivity Products applications.     I hope you find this guide useful. Enjoy this guide! Any feedback is welcome. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

Hello everyone, Over The Air Programming (OTAP) NXP's custom Bluetooth LE service provides the developer a solution to upgrade the software that the MCU contains. It removes the need for cables and a physical link between the OTAP client (the device that is reprogrammed) and the OTAP server (the device that contains the software update). This post explains how to run the OTAP Client Software that comes within the FRDM-KW36 package: Reprogramming a KW36 device using the OTAP Client Software. As it is mentioned in the last post, the OTAP Client can reprogram the KW36 while it is running, with new software using Bluetooth LE. However, this implementation for most of the applications is not enough since once you have reprogrammed the new image, the KW36 can not be reprogramed a second time using this method. For these applications that require to be updated many times using Bluetooth LE during run-time, we have created the following application note, that comes with a functional example of how to implement the OTAP Client software, taking advantage of this service. You can download the software clicking on the link in blue and the documentation is in the link in green. Please visit the following link: DOCUMENTS and Application Notes for KW36 In the "DOCUMENTS" section, you can found more information of the KW36. In the "Application Note" section, you can found more software and documentation of interesting topics like this.        Best Regards.

Our customer, who is considering MKW40, is asking NXP regarding max input voltage of PSWITCH and DCDC_CFG pins. Especially they plan to use buck mode with input voltage 4.2[v] as shown below. Would you comment if max voltage of PSWITCH and DCDC_CFG pins is 4.2[v] as well as DCDC_IN pin? Regards, Koichi

BeeStack solutions included in BeeKit contain several low level drivers that definitely ease customer’s development phase.  Ranging from UART, SPI, NVM, I2C, among many others, these drivers could be used to interface the MW2x devices with different devices or sensors. It is also true these drivers will not support all custom applications by default, but they are conveniently provided in source code so anyone can modify them to the application’s needs. One example would be the need to use an accelerometer such as FXOS8700 or MMA8451. In this case, the default functionality of the I2C drivers might not be well-suited to work with these devices out-of-the-box. Nevertheless, this could be achieved with simple modifications to the source code. This project implements the basic I2C functionality to interface a TWR-KW24D512 board with a FXOS8700 sensor using the drivers included in Kinetis BeeStack Codebase 4.0.x solutions. The demo uses a ZigBee Home Automation GenericApp template to initialize and periodically read the accelerometer data X, Y and Z. A change in the registers read and written would be enough to use MMA8451 instead.  Following images illustrate the I2C frames obtained from the analyzer: FXOS8700 Initialization: Accelerometer X-Axis Data: Accelerometer Y-Axis Data: Accelerometer Z-Axis Data: IMPORTANT NOTE: Support of the attached project is limited. Please use this project as reference only. If it does not fulfill your requirements, you could always modify its source code to meet you application’s needs.

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

By default the clock configuration on the KW2xD demos is set to PLL Engaged External (PEE). In this mode the system clock is derived from the output of the PLL and controlled by an external reference clock. The modem provides a programmable clock source output CLK_OUT that can be used as the external reference clock for the PLL. In the Figure 1 we can see that the CLK_OUT modem signal is internally connected to EXTAL0 in the MCU.   The CLK_OUT output frequency is controlled by programming the modem 3-bit field CLK_OUT_DIV [2:0] in the CLK_OUT_CTRL Register. The default frequency is either 32.787 kHz or 4 MHz depending on the state of the modem GPIO5 at reset determined by the MCU. See section 4.4.2 and 5.6.2 from the MKW2xD Reference Manual for more information on the clock output feature. If the GPIO5 modem pin is low upon POR, then the frequency will be 4 MHz. If this GPIO5 modem pin is high upon POR, then the frequency will be 32.78689 kHz.   In the KW2xD demos, the GPIO5 (PTC0) is held low during the modem reset so the CLK_OUT has a frequency of 4MHz. The clock configuration structure g_defaultClockConfigRun is defined in board.c. Figure 1. Internal Functional Interconnects   In this example project, another clock configuration will be added to the Connectivity Test Project: FLL Engaged Internal (FEI). In this mode, the system clock is derived from the FLL clock that is controlled by the 32kHz Internal reference clock.   In FEI mode the MCU doesn’t need the clock source output CLK_OUT from the modem, so we can disable the radio’s clock output and then set the radio to Hibernate to save power when we are not using the radio.   If the low-power module from the connectivity framework is used to go to a low-power mode, the clock configuration is changed automatically when entering a sleep mode (See the Connectivity Framework Reference Manual for more information about the low-power library).   System Requirements Kinetis MKW2xD and MCR20A Connectivity Software (REV 1.0.0) TWR-KW24D512 IAR Embedded Workbench for ARM 7.60.1 or later Attached project files Application Description The clock configuration can be changed with shortcuts on the serial console: Press “c” to use the PEE clock configuration (default). Press “v” to use the FEI clock configuration and set the radio to Autodoze. Press “b” to use the FEI clock configuration and set the radio to Hibernate.   You must be in the main menu in order to change the radio mode, the mode automatically changes to Autodoze when entering a test menu.   Hibernate mode can only be changed when in FEI mode. This is because in hibernate the radio disables the CLK_OUT and the PEE configuration needs this clock.   Current Measurements The following measurements were done in a TWR-KW24D256 through J2 5-6 to measure the radio current. Table 1. Radio Current Measurements Clock mode/Radio mode Radio Current PEE/Autodoze 615µA FEI/Autodoze 417µA FEI/Hibernate 0.3µA   Code Modifications The following modifications to the source files were made: \boards\twrkw24d512\Board.c Added clock user configuration Added array of clock configs and configuration struct for clock callback   \boards\twrkw24d512\Board.h Include for fsl_clock_manager.h Declaration of clock callback and configuration array used in CLOCK_SYS_Init() function.   \boards\twrkw24d512\Hardware_init.c Added calibration code after BOARD_ClockInit(), this is to calibrate internal clock using the bus clock.   \examples\smac\Connectivity_Test\common\Connectivity_TestApp.c Initialize the clock manager. Disable PTC0 because it is only used at modem reset to select the CLK_OUT default frequency (4MHz). Return clock configuration on idle state. Prepare radio to go to Autodoze when entering a test menu.   \examples\smac\Connectivity_Test\twrkw24d512\common\Connectivity_Test_Platform.c Changed length of the lines to be erased in PrintTestParameters() from 65 to 80 Added clock config and radio mode to be printed in the test parameters. Added the cases in the shortcut parser to change the clock and radio configuration with the keys “c”, “v” and “b”. Added functions at end of file (Explained in the next section).   \examples\smac\Connectivity_Test\twrkw24d512\common\Connectivity_Test_Platform.h Macros for the clock and radio modes. Function prototypes from the source file.   \examples\smac\Connectivity_Test\twrkw24d512\common\ConnectivityMenus.c Shortcuts descriptions.   The modified source files can be found attached to this document.   Functions added The functions PWRLib_Radio_Enter_Hibernate() and PWRLib_Radio_Enter_AutoDoze() were taken from the file PWRLib.c located at <Connectivity_Software_Path>\ConnSw\framework\LowPower\Source\KW2xD. The PWRLib.c file is part of the low-power library from the connectivity framework.   The Clock_Callback() function was implemented to handle when the clock configuration is updated. Inside the function there is a case to handle before and after the clock configuration is changed. Before the clock configuration is changed, the UART clock is disabled and if the clock configuration is PEE, the radio is set to AutoDoze and the CLK_OUT is enabled. After the clock configuration has changed, the Timer module is notified that the clock has changed, the UART is re-initialized and if the clock configuration is FEI, the CLK_OUT is disabled. This behavior is shown in Figure 2. Figure 2. Clock callback diagram   The prepareRadio() function is used when entering a test mode to make sure the radio is set to AutoDoze in case it was in hibernate. The restoreRadio() function is used when leaving the test menu and going to hibernate if it was previously set.

Hello,  Here are some helpful steps to follow when working with the NXP GitHub SDK. Step1: Ensure the necessary toolchains are installed:  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/gsd/repo.html  Additional notes and links: VS code: https://code.visualstudio.com/ MCUXpresso plugin: https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-for-visual-studio-code:MCUXPRESSO-VSC Getting started with MCUXpresso for VS Code: https://www.nxp.com/design/design-center/training/TIP-GETTING-STARTED-WITH-MCUXPRESSO-FOR-VS-CODE   Step 2: Download and Install the SDK: GUI Method: - Open VS Code, navigate to Import Repository and select the Remote option as shown below: - Upon successful import, the repository will show up in the Imported Repositories window:    Command Line Method: - west commands: # Initialize west with the manifest repository west init -m https://github.com/nxp-mcuxpresso/mcuxsdk-manifests/ mcuxpresso-sdk # Update the west projects cd mcuxpresso-sdk west update More details:  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/gsd/installation.html#get-mcuxpresso-sdk-repo  - import the local repository to VS code: Open VS Code, navigate to Import Repository and select the Local option and Browse.. to your local repo:   Step3: Run a Bluetooth LE Example Step3a: Run a Bluetooth LE Example using MCUXpresso for VS code - click Import Example from Repository from the QuickStart Panel - From the open dialog, select the MCUXpresso SDK, the Arm GNU toolchain, your target board, desired template, and application type, and proceed by clicking Import:   For the application type, you’ll typically see two options:  - Repository application  - Freestanding application. The key difference lies in where the project is imported. Repository applications are placed within the MCUXpresso SDK directory, while Freestanding applications can be imported to a custom location defined by the user. - Next, VS Code will prompt you to verify trust for the imported files—click Yes. Navigate to the PROJECTS view. - Identify your project, right click and select the Prestine Build icon to begin building:  - details of the build are into the terminal window: - using Debug button will allow you to download and debug the software:   (useful link: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/gsd/run_a_demo_using_mcuxvsc.html ) Step3b: Run a Bluetooth LE Example using IAR Embedded Workbench for ARM: - use the west list_projects command to list the supported example for boards and the corresponding toolchain: Example to list Bluetooth examples:  west list_project -p .\examples\wireless_examples\bluetooth\ or if you know the platform or/and the project you can use: west list_project -b kw45b41zevk -p .\examples\wireless_examples\bluetooth\w_uart  west list_project -b frdmmcxw23 -p .\examples\wireless_examples\bluetooth\w_uart   Once you've confirmed that the project is available for the IAR toolchain, run the appropriate command to build it: west build -p always examples/wireless_examples/bluetooth/w_uart/freertos --toolchain iar --config debug -b kw45b41zevk The build folder will contain the generated output:   To work with IDE add  -t guiproject in the west command: west build -p always examples/wireless_examples/bluetooth/w_uart/freertos --toolchain iar --config debug -b kw45b41zevk -t guiproject --pristine --build-dir=build/w_uart_freertos_kw45    The result of the build will indicate the path to the *.eww/*.ewp:   (additional details: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/gsd/run_project.html )   Step4: Create a standalone example With the freestanding project approach, only the application code is included in the export folder. Other essential files remain linked to the repository. To generate a complete standalone project, the recommended method is using West by adding -t standalone_project option. Example of command for kw45b41zevk, IAR toolchain: west build -b kw45b41zevk ./examples/wireless_examples/bluetooth/w_uart/freertos -p always --toolchain iar --config debug -t standalone_project -d c:\work\w_uart_kw45  The result of the build will indicate the path to the *.eww/*.ewp:   Example of command for kw45b41zevk, armgcc toolchain: west build -b kw45b41zevk ./examples/wireless_examples/bluetooth/w_uart/freertos -p always --toolchain armgcc --config debug -t standalone_project -d c:\work\w_uart_KW45_armgcc The result of the build will indicate the path to the project that need to be imported in VsCode: Regards, Ovidiu  

The MCX W72x family features a 96 MHz Arm® Cortex®-M33 core coupled with a multiprotocol radio subsystem supporting Matter, Thread, Zigbee and Bluetooth LE. 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 W72x 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 W72x family includes Bluetooth Channel Sounding capabilities, with a dedicated on-chip Localization Compute Engine to reduce ranging latency. It incorporates additional memory to support application-specific code, connectivity stacks and over-the-air firmware updates. In addition, the radio subsystem can run the full Thread or Zigbee stack alongside the Bluetooth Low Energy stack. This delivers reliable wireless performance, as the real-time activities of the radio run on a separate core from the application. Building on NXP's strong history of providing industrial edge solutions, the MCX W series offers a wide operating temperature range from -40 °C to 125 °C and peripherals for industrial applications, including an optional CAN interface and will be part of NXP's 15-year Product Longevity program to support long-term industrial use. The MCX W series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development. The MCX W72x is in pre-production, developers can get started today with the MCX W71x, which is pin and software compatible.       Channel Sounding  Channel Sounding Introduction presentation   Bluetooth Specifications 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   Bluetooth Training Bluetooth Low energy 6.0 NXP Introduction   Training MCX W Series Training - NXP Community   Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development    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)... 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. Kinetis (K32/38/KW45 & K32W1/MCXW71) Power Profile Tools:  This page is dedicated to the Kinetis (KW35/KW38/KW45) and MCX W7x (MCX W71) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IoT) and evaluate the battery lifetime of your solution. KW47/MCXW72 32MHz & 32kHz Oscillation margins: this article provides the properly configuration for the Oscillation margins for the circuit. Videos NXP Channel Sounding technology interfacing with Google Pixel 10This is a demo showing the MCX W72 LOC board interacting with Google Pixel 10 phone using channel sounding

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

Introduction In some applications, is it necessary to keep updated the software running in many MCU's that take part in the system, fortunately, Over The Air Programming, it's a custom Bluetooth LE service developed to send "over the air" software updates for the KW MCU series. FRDM-KW36 SDK already provides the "otap_client" software, that can be used together with the "otap_bootloader" such as it is described in the following community post: Reprogramming a KW36 device using the OTAP Client Software to reprogram the KW36. This example can be modified to store code for another MCU and later send the software update to this device as depicted in the figure below. This post guides you on modifying the OTAP client software to support software updates for other MCU's. Preparing the OTAP client software The starting point of the following modifications is supposing that there is no need to perform over the air updates for the KW36 MCU, so the use of the "otap_bootloader" is obsolete and will be removed in this example. In other words, KW36 will be programmed only with the "otap_client" code. Open the MCUXpresso settings window (Project->Properties->"C/C++ Build->MCU settings") and configure the following fields. Save the changes. For external storage: For internal storage: Locate the "app_preinclude.h" file, and set the storage method, as follows: For external storage: #define gEepromType_d       gEepromDevice_AT45DB041E_c For internal storage: #define gEepromType_d        gEepromDevice_InternalFlash_c Locate the "main_text_section.ldt" linker script into the "linkscripts" folder, and delete it from the project.  Search in the project for "OTA_SetNewImageFlag();" and "ResetMCU();" functions in the "otap_client.c" file (source->common->otap_client->otap_client.c) and delete or comment. (For reference, there are 4 in total). Locate the following code in "OtaSupport.h" (framework->OtaSupport->Interface) and delete or comment. extern uint16_t gBootFlagsSectorBitNo;‍‍‍‍‍‍ void OTA_SetNewImageFlag(void);‍‍‍‍‍‍‍ Locate the following code in "OtaSupport.c" (framework->OtaSupport->Source) and delete or comment. extern uint32_t __BootFlags_Start__[]; #define gBootImageFlagsAddress_c ((uint32_t)__BootFlags_Start__)‍‍‍‍‍‍‍‍‍‍‍‍ #if !gEnableOTAServer_d || (gEnableOTAServer_d && gUpgradeImageOnCurrentDevice_d) /*! Variables used by the Bootloader */ #if defined(__IAR_SYSTEMS_ICC__) #pragma location = "BootloaderFlags" const bootInfo_t gBootFlags = #elif defined(__GNUC__) const bootInfo_t gBootFlags __attribute__ ((section(".BootloaderFlags"))) = #elif defined(__CC_ARM) volatile const bootInfo_t gBootFlags __attribute__ ((section(".BootloaderFlags"))) = #else #error "Compiler unknown!" #endif { {gBootFlagUnprogrammed_c}, {gBootValueForTRUE_c}, {0x00, 0x02}, {gBootFlagUnprogrammed_c}, #if defined(CPU_K32W032S1M2VPJ_cm4) && (CPU_K32W032S1M2VPJ_cm4 == 1) {PLACEHOLDER_SBKEK}, {BOOT_MAGIC_WORD} #endif }; #endif /* !gEnableOTAServer_d || (gEnableOTAServer_d && gUpgradeImageOnCurrentDevice_d) */‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ uint16_t gBootFlagsSectorBitNo; gBootFlagsSectorBitNo = gBootImageFlagsAddress_c/(uint32_t)((uint8_t*)FSL_FEATURE_FLASH_PFLASH_BLOCK_SECTOR_SIZE);‍‍‍‍ gBootFlagsSectorBitNo = gBootImageFlagsAddress_c/(uint32_t)((uint8_t*)FSL_FEATURE_FLASH_PAGE_SIZE_BYTES);‍‍‍‍ void OTA_SetNewImageFlag(void) { #if (gEepromType_d != gEepromDevice_None_c) && (!gEnableOTAServer_d || (gEnableOTAServer_d && gUpgradeImageOnCurrentDevice_d)) /* OTA image successfully written into the non-volatile storage. Set the boot flag to trigger the Bootloader at the next CPU Reset. */ union{ uint32_t value; uint8_t aValue[FSL_FEATURE_FLASH_PFLASH_BLOCK_WRITE_UNIT_SIZE]; }bootFlag; #if defined(CPU_K32W032S1M2VPJ_cm4) && (CPU_K32W032S1M2VPJ_cm4 == 1) uint8_t defaultSBKEK[SBKEK_SIZE] = {DEFAULT_DEMO_SBKEK}; #endif uint32_t status; if( mNewImageReady ) { NV_Init(); bootFlag.value = gBootValueForTRUE_c; status = NV_FlashProgramUnaligned((uint32_t)&gBootFlags.newBootImageAvailable, sizeof(bootFlag), bootFlag.aValue); if( (status == kStatus_FLASH_Success) && FLib_MemCmpToVal(gBootFlags.internalStorageAddr, 0xFF, sizeof(gBootFlags.internalStorageAddr)) ) { bootFlag.value = gEepromParams_StartOffset_c + gBootData_ImageLength_Offset_c; status = NV_FlashProgramUnaligned((uint32_t)&gBootFlags.internalStorageAddr, sizeof(bootFlag), bootFlag.aValue); } #if defined(CPU_K32W032S1M2VPJ_cm4) && (CPU_K32W032S1M2VPJ_cm4 == 1) if( status == kStatus_FLASH_Success ) { /* Write the default SBKEK for secured OTA */ status = NV_FlashProgramUnaligned((uint32_t)&gBootFlags.sbkek, SBKEK_SIZE, defaultSBKEK); } #endif if( status == kStatus_FLASH_Success ) { mNewImageReady = FALSE; } } #endif }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   At this point, the FRDM-KW36 can receive and store any image for any MCU and can request a further software update from the OTAP server device.    Adding API's to reprogram the "MCU X" on OTAP client software Once the software update has been downloaded from the OTAP Server into the OTAP Client, the developer should request the software update from the OTAP Client to the "MCU X" through a serial protocol such as UART, SPI, CAN, etc. You should develop the API's and the protocol according to the requirements for your system to send the software update to the "MCU X" (as well as the bootloader for the MCU X). The handling your protocol can be integrated into the OTAP client code replacing "ResetMCU()" (The same code removed in step 4) in the code by "APISendSoftwareUpdateToMCUX()" for instance, since at this point the image was successfully sent over the air and stored in the memory of the KW36. 

Customer is designing QN9090 module. They have IQxel non-signaling equipment and ask if QN9090 can be tested with IQxel-MW. We co-work with ACE Solution Taiwan Co.Ltd. to Integrate QN9090 and IQxel to perform 1M bps, 2M bps and Frame error rate test. This document will address the QN9090 setup and IQxel connection setup. Finally we show the 1M bps, 2M bps and packet error rate results.

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

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 steady state. 5 is enough 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 : ESR: Crystal Equivalent Series Resistance C0: Shunt Capacitance Rm1: Motional resistor Cm1: Motional Capacitance Lm1: Motional Inductance fosc: oscillation frequency, measured with Rs_Max mounted fr: resonance frequency of the Rm1Lm1Cm1 of the crystal from (1) :    Oscillation margin is:                     Example: for the EVK board’s 32kHz crystal (NX2012SE) ESR    80000,0 Ω Rm1    79978,2 Ω 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 Ω Oscillation Margin   10,3   Measurement Requirements for measurement PCB (for the test, it is recommended to add a series resistor on the EXTAL32k trace) 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 stops. 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 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. A test jig and socket could be used in measurement but stray of them will give influence for oscillation margin.   KW47/MCX W72 product oscillation margin overview 32MHz crystal NXP recommends to use the quartz NDK NX1612SA 32MHz (EXS00A-CS15781) to be compliant with the +/-50ppm required in Bluetooth LE. Using the current SDK, NXP guarantees an oscillation margin of 10 for startup and steady state commonly used by Automotive customers. 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 a general basis, the requested oscillation margin has to be between the 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 Rs_max = 560 Ω) The CDAC/ISEL area where the oscillation starts and propagates in the internal blocks is defined (green color raws) in the table below. The frequency accuracy is indicated for some of them:     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 (Cap_Sel) is limited (green area) as shown in the graph below:   Example: for an oscillation margin at 6.3, if the load cap is set at 12pF and the ESR_Range to 3, the 32kHz frequency accuracy will be around -23ppm. From this point, the oscillation margin can be enlarged to 10.3 by decreasing the load cap to 6pF but the accuracy will be degraded (110ppm).   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 111ppm to 21ppm by setting the ESR_range 2 to an ESR_Range 3 but the current consumption will be increased to 169.5nA. Another 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)              

 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.        

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

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-340993