As mentioned in this other post, its important to have the correct trim on the external XTAL. However, once you have found the required trim to properly adjust the frequency, it is not very practical to manually adjust it in every device. So here is where changing the default XTAL trim comes in handy. KW41Z With the KW41 Connecitivity Software 1.0.2, it is a pretty straightforward process. In the hardware_init.c file, there is a global variable mXtalTrimDefault. To change the default XTAL trim, simply change the value of this variable. Remember it is an 8 bit register, so the maximum value would be 0xFF. KW40Z With the KW40, it is a similar process; however, it is not implemented by default on the KW40 Connectivity Software 1.0.1, so it should be implemented manually, following these steps: Create a global variable in hardware_init.c to store the default XTAL trim, similar to the KW41:  /* Default XTAL trim value */ static const uint8_t mXtalTrimDefault = 0xBE;‍‍‍‍‍‍‍‍ Overwrite the default XTAL trim in the hardware_init() function, adding these lines after NV_ReadHWParameters(&gHardwareParameters):    if(0xFFFFFFFF == gHardwareParameters.xtalTrim)   {       gHardwareParameters.xtalTrim = mXtalTrimDefault;   }‍‍‍‍‍‍‍‍‍‍‍‍ Add this define to allow XTAL trimming in the app_preinclude.h file:  /* Allows XTAL trimming */ #define gXcvrXtalTrimEnabled_d  1‍‍‍‍‍‍‍ Once you have found the appropriate XTAL trim value, simply change it in the global variable declared in step 1.

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

In addition of the Design Guideline, PCB hardware package find here the design in check list to build sucessfully your own PCB

This application note describes the usage of the DC-DC Switching Mode Power Supply (SMPS) converter for the MKW39A/38A/37A/38Z/37Z families. This document covers operating voltages, types of circuit operation, hardware design guidelines, software configuration, and power capabilities. It's a complementary document from the AN5025. The DC-DC converter for MKW3x is a dual output converter that supports two operating modes: Bypass and Buck. In Bypass mode, the DC-DC converter is disabled and the supply pins of the microcontroller must be supplied externally. In Buck mode, the DC-DC converter is enabled and requires a DC supply in the range of 1.8 V to 4.2 V (during startup the minimum required is 2.1 V).

This document provides information on distance measurements depending of the Bluetooth LE data rate (1Mbps, 2Mbps, LR S=2 & LR S=8). The FRDM-KW38 boards are used to perform the measurements. Results are similar on KW37 and KW39.  

       This document will address the JN5169 CMET setup and JN5169 connection setup with IQxel-MW. We also show the EVM and packet error rate results.

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.

View the Webinar Recording

       My customer asks if QN9080 can be tested with MT887x. We co-work with Anritsu Taiwan to integrate QN9080 and MT887x to perform 1M bps, 2M bps and Frame error rate test. This document will address the QN9080 setup and MT887x connection setup. We show the 1M bps, 2M bps and frame error rate results. The Anritsu equipment is applied to MT8870, MT8872 model name.        If you would like to perform the same test environment. You may contact Anritsu to get the latest "Auto-test tool " released by Anritsu and follow their SOP document to install "Auto-test tool" into PC to perform this RF validation test. 

Hi RF High Power Model Kit 2020 Rev2.1 Installation Questions URL: nxp.com/products/rf/rf-high-power-models/models-for-ads-keysight-advanced-design-system:RF_HIGH_POWER_MODELS_KEYSIGHT file name: RF-POWER-ADS2020v2p1-DK.zip I installed it but the library does not contain anything as shown below. Please help with this. Thank you!

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

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

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

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

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

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.

Regarding to the "Reprogramming a KW36 device using the OTAP Client Software" and "Reprogramming a KW35 device using the OTAP Client Software" documents, there are some additional steps to debug the OTAP client software in the specific case when you use MCUXpresso together with a P&E micro debug probe. Just before to program the OTAP client project (the second software), the user must do the following: Open the "Debug Configurations" view clicking on the green bug as depicted below. Go to the "Debugger" perspective and search the "Advanced Options" button. Enable the "Preserve this range (Memory Range 0)" checkbox, and edit the textbox "From: 0" To: 1fff" for the KW36 device or "From: 0 To: 3fff" for the KW35 device. After to flash the device, disconnect and connect again. If everything it's OK, the RGB LED must blink (If you are using an FRDM board). Then, test the demo as described in the document.

This Application Note provides guidance on migrating ZigBee 3.0 Base device application designed for the NXP JN516x wireless microcontrollers to the KW41Z with the help of attached PDF.

The FRDM-KW36 comes with the OpenSDA circuit which allows users to program and debug the evaluation board. There are different solutions to support such OpenSDA circuits: 1. The J-Link (SEGGER) firmware.  2. The CMSIS-DAP (mbed) firmware. The FRDM-KW36 comes pre-programmed with the CMSIS-DAP firmware. However, if you want to update the firmware version, you need to perform the next steps.  Press and hold the Reset button (SW1 push button in the board).  Unplug and plug the FRDM-KW36 again to the PC.  The board will be enumerated as "DAPLINKBOOT" device. Drag and drop the binary file to update the OpenSDA firmware.  If the J-Link version is programmed, the board will be enumerated as "FRDM-KW36J". On the other hand, if the CMSIS-DAP version is programmed, the board will be enumerated as "FRDM-KW36". The binary for the J-link version can be downloaded from the next link: SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace  The binary for the CMSIS-DAP version can be found in the next link: OpenSDA Serial and Debug Adapter|NXP    Hope this helps... 

I got a question related to best practices to configure a GPIO if the pin is not used. To make it short, the recommendation is to leave the GPIO floating on the PCB and leave the GPIO in its "Default" state as shown in the Signal Multiplexing table in the Reference Manual. The Default state is either “Disabled” or an analog function.   Some Kinetis devices have analog only pins (PGAx/ADCx) while most have GPIO pins with analog functions (PTx/ADCx) or digital GPIO pins   Unused pins, whether analog only or GPIO, should be left floating. Analog only pins do not have input buffers that will cause shoot-through currents when the input floats. GPIO pins with analog functions default to analog functions, which disables the digital input buffer – no shoot-through current.   The digital GPIO pins default to "Disabled", which disables the input buffers - no shoot-through currents with floating inputs.   Finally, unused pins shall not be tied to VDD or VSS. Hence, when designing your board and there are some unused pins, leave them floating on the PCB and then make sure that the software leaves the GPIO in its Default state in the MUX register.