Wireless Connectivity Knowledge Base

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

Wireless Connectivity Knowledge Base

Discussions

Sort by:
Introduction This document describes the hardware considerations for the schematic and layout of the MKW36A512VFT4 device. This MCU is packaged into a 48-pin HVQFN - 7x7 mm, dissimilar to MKW36Z512VHT4 which comes packaged into a 48-pin LQFN - 7x7 mm (the last one takes part of FRDM-KW36).   Pin Layout  The MKW36A512VFT4 MCU is pin to pin compatible with the MKW36Z512VHT4 (FRDM-KW36) MCU, except for the DCDC pins. The following figure shows the distribution of the pins in the MKW36A512VFT4 MCU (left), compared with the MKW36Z512VHT4 (FRDM-KW36 MCU, right). Surely, this is the most important consideration for MKW36A512VFT4, since you can not simply move the FRDM-KW36 layout on your design. Minimum BOM The following figures show the minimum BOM necessary for each DCDC mode in KW36. For more information about DCDC modes and hardware guidelines, please visit: MKW4xZ/3xZ/3xA/2xZ DC-DC Power Management Bypass Mode   Buck Auto-Start Mode   Buck Manual-Start Mode     Layout Recommendations The footprint and layout are critical for RF performance, hence if the recommended design is followed exactly in the RF region of the PCB, sensitivity, output power, harmonic and spurious radiation, and range, you will succeed. For more information of layout recommendations, please visit Hardware Design Considerations for MKW35A/36A/35Z/36Z Bluetooth Low Energy Devices. The footprint recommended for the MKW36A512VFT4 is shown in the figure below. NXP prefers to use a top layer thickness of no less than 8-10 mils. The use of a correct substrate like the FR4 with a dielectric constant of 4.3 will assist you in achieving a good RF design. Other recommendations during EMC certification stages are: - Specific attention must be taken on 4 pins PTC1, 2, 3 & 4 if they are used on the application. - 4 decoupling capacitors of 3pF are mandatory on those pins and be positioned as close as possible. - Wires from those 4 pins must be underlayer. - NXP recommends putting the vias under the package in case the customer HW design rules allow it. Some recommendations for a good Vdd_RF supply layout are: - Vdd_RF1 and Vdd_RF2 lines must have the same length as possible, linked to pointA (‘Y’ connection). - 12pF decoupling capacitor from Vdd_RF wire must be connected to the Ground Antenna. The purpose is to get the path as short as possible from Vdd_RF1/Vdd_RF2 to the ground antenna. - 12pF decoupling capacitor from the Vdd_RF3 pin must be as close as possible. Return to ground must be as short as possible. So vias (2 in this below picture) must be placed near to the decoupling capacitor to get close connection to the ground layer. The recommended RF stage is shown in the following figure. The MKW36A512VFT4 has a single-ended RF output with a 2 components matching network composed of a shunt capacitor and a series inductor. Both elements transform the device impedance to 50 ohms. The value of these components may vary depending on your board layout. Avoid routing traces near or parallel to RF transmission lines or crystal signals. Maintain a continuous ground under an RF trace is critical to keep unaltered the characteristic impedance of the transmission line. Avoid routing on the ground layer that will result in disrupting the ground under RF traces. For more information about RF considerations please visit: Freescale IEEE 802.15.4 / ZigBee Package and Hardware Layout Considerations.
View full article
During last week I receive a question about identify a way to notice when the 32kHz oscillator is ready to be able to use it as clock source. In other words, when the 32kHz oscillator is stable to be used as reference clock for the MCG module. Then, system can switch over it. Kinetis devices starts up using its internal clock which is called FEI mode, then, the applications change to a different mode which require an external clock source (i.e. FEE mode). Normally, we have two options which are: Main reference clock. Talking specifically to KW devices, there is the 32MHz external crystal for the main reference clock. The 32kHz external crystal for the 32kHz oscillator which is driven through the RTC registers.  For the first option, there is a register which could be monitored to know when oscillator is ready (RSIM_CONTROL_RF_OSC_READY). So, it can be polled to notice when the oscillator is up and ready.  About the second option, there is no “OSCINIT” bit for the 32 kHz oscillator. However, there is a way to know when the 32kHz Oscillator is running, it is to simply enable the RTC OSC, and configure the RTC to count. After doing that immediately poll (read) the RTC_TPR register and check it until it is greater than 4096. It will roll over once it reaches 32767 so, it is important to the poll this register in a loop doing nothing else or the register could potentially be read when it is less than 4096 but had already rolled over. Once it is greater than 4096, it can be determined that oscillator is running well. If the RTC is not required, the counter can be disabled. Now that the 32kHz clock is available, the application can switch to FEE mode. So, in order to perform the above description, I modified the “CLOCK_CONFIG_EnableRtcOsc()” as shown next: static void CLOCK_CONFIG_EnableRtcOsc(uint32_t capLoad) {        rtc_config_t rtc_basic_config;        uint32_t u32cTPR_counter=0;        /* RTC clock gate enable */     CLOCK_EnableClock(kCLOCK_Rtc0);     if ((RTC->CR & RTC_CR_OSCE_MASK) == 0u)     {       /* Only if the Rtc oscillator is not already enabled */       /* Set the specified capacitor configuration for the RTC oscillator, "capLoad" parameter shall be set          to the value specific to the customer board requirement*/       RTC_SetOscCapLoad(RTC, capLoad);          /*Init the RTC with default configuration*/       RTC_GetDefaultConfig(&rtc_basic_config);       RTC_Init(RTC, &rtc_basic_config);       /* Enable the RTC 32KHz oscillator */       RTC->CR |= RTC_CR_OSCE_MASK;       /* Start the RTC time counter */       RTC_StartTimer(RTC);             /* Verify TPR register reaches 4096 counts */       while(u32cTPR_counter < 4096)       {          u32cTPR_counter= RTC->TPR;       }       /* 32kHz Oscillator is ready. Based on the application requirements, it can let the RTC enabled or disabled.           In this case, we can disable RTC since it is not needed by this application */       RTC_Deinit(RTC);     }     /* RTC clock gate disable  since RTC is not needed anymore*/     CLOCK_DisableClock(kCLOCK_Rtc0); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Then, using the above function, it can be noticed when the 32kHz oscillator is ready to be used. Hope this helps....
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 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)              
View full article
NXP wireless solutions build upon decades of Wi-Fi, Bluetooth®, multiprotocol silicon, software and system design expertise, including 802.15.4 in the latest tri-radio architectures. NXP is committed to driving large-scale deployment across multiple markets by a broad array of power- and cost-optimized Wi-Fi, Bluetooth and 802.15.4 transceivers, enabling products with advanced Wi-Fi and multiradio capabilities including Wi-Fi 4, Wi-Fi 5 and Wi-Fi 6 chips.   Market Product Wi-Fi Spec Wi-Fi Support Summary  IoT IW623 802.11ax (Wi-Fi 6E) 2x2 Tri-band (2.4G/5/7 GHz) + 1x1 Single Band (2.4 GHz) supports Wi-Fi 6E, with a high-performance 2x2 tri-band module for fast and flexible connectivity, plus an extra 1x1 2.4 GHz module likely for compatibility or low-power tasks IoT IW693 802.11ax (Wi-Fi 6/6E) CDW 2x2 Dual Band (5-7 GHz) + 1x1 Single Band (2.4 GHz) High-speed, low-latency connectivity on modern bands (5 and 6 GHz). Compatibility with older devices via 2.4 GHz A 2x2 MIMO setup for better performance, plus a 1x1 fallback for basic connections IoT IW610 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz)   IoT IW612 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz)   IoT IW611 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz)   IoT IW620 802.11ax (Wi-Fi 6) 2x2 DB (2.4/5 GHz)   IoT IW416 802.11n (Wi-Fi 4) 1x1 DB (2.4/5 GHz)       Markets Product Wi-Fi Spec Wi-Fi Support Summary Wireless MCU Hostless RW612 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) supports Wi-Fi 6, has a single antenna (1x1), and can connect to both 2.4 GHz and 5 GHz networks. Wireless MCU Hostless RW610 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) supports Wi-Fi 6, has a single antenna (1x1), and can connect to both 2.4 GHz and 5 GHz networks.   Markets Product Wi-Fi Spec Wi-Fi Support Automotive AW692 802.11ax (Wi-Fi 6) 2x2 + 1x1 CDW DB (2.4/5GHz + 2.4Ghz) Automotive AW693 802.11ax (Wi-Fi 6E) 2x2 + 1x1 CDW TB (2.4/5/6Ghz + 2.4Ghz) Automotive AW611 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) Automotive AW690 802.11ax (Wi-Fi 6) 1x1 CDW DB (2.4/5 GHz)   Wireless Module Partners Leading wireless connectivity solution providers offer NXP wireless modules in their wireless connectivity solutions. Module manufacturers develop Wi-Fi modules using NXP’s broad portfolio of Wi-Fi chips (system-on-chip (SoC)), including Wi-Fi 6 chips, Wi-Fi and Bluetooth® combo integrated circuits (ICs) and tri-radio SoCs with 802.15.4. NXP enables a broad range of wireless applications with an ecosystem of wireless module partners.   Why Use a Module Vendor? Accelerate time-to-market Avoid the complexity of RF design and testing Ensure regulatory compliance more easily (e.g. FCC, CE, ISED) Focus on the host product’s functionality while relying on the vendor for wireless performance   Useful Links Wi-Fi Basic concepts: This post provides information about the different terms used in Wi-Fi, 802.11 standards and the three types of 802.11 MAC frames. Wi-Fi Security Concepts: This post covers the security and authentication processes  Wi-Fi Connection/Disconnection process: In 802.11 standards, the connection procedure includes three major steps that shall be performed to make the device part of the Wi-Fi network and communicate in the network. Wi-Fi Software Drivers Locations: NXP Recommends using Wi-Fi source code drivers WiFi_BT_Integretation-(Linux_BSP_compilation_for_iMX_platform): This article describes how to compile the Linux BSP of the i.MX platform under ubuntu 18.04, 20.04 LTS and debian-10. This is a necessary step to integrate WIFI/BT to the I.MX platform. See the attachment for detailed steps. Enabling i.MX8MP-EVK uSDHC1 M.2 for Wi-Fi on Android-11.0.0_2.6.0: Detailed steps on enabling usdhc1 NXP Wi-Fi and Bluetooth Product:  The article will introduce how to build Wi-Fi Mass Market Driver Wi-Fi Firmware Automatic Recovery on RW61x: This article introduces the Wi-Fi automatic recovery feature as well as how to enable and verify it on RW61x SDK. Access Point Wi-Fi configuration on i.MX8 Family: This guide explains how to achieve that, using the i.MX8M Plus EVK (8MP) as the AP device and the i.MX8M Mini EVK (8MM) as the connected device. How to connect to a Wi-Fi network on i.MX8MP: this article guides you step by step how to connect to a Wi-Fi network NXP Wi-Fi/Bluetooth firmware on the i.MX8M series: steps to replace Wi-Fi/Bluetooth firmware on the i.MX8M series on Linux Enabling Wi-Fi on Zephyr projects with the FRDM-RW612: In this guide, we'll modify the mqtt_publisher example—originally designed for Ethernet—to work with Wi-Fi instead Training FRDM-iMX91 connectivity Wi-Fi Basic Hands-on FRDM-iMX91 connectivity Wi-Fi Bluetooth LE and OT COEX RW612/MCXW71 - Wi-Fi and thread border router Training FRDM-RW612 Getting Started, Wi-Fi CLI on VScode Community Support If you have questions regarding this training, please leave your comments in our Wireless MCU Community! here 
View full article
The TWR-KW2x board's OpenSDA is programmed with PE Micro's OpenSDA firmware which enables MSD, debugging and CDC Serial port. This firmware can be easily modified by putting the K20 part in bootloader mode and load another firmware to it with a simple drag and drop. Follow these steps to modify the OpenSDA firmware on the TWR-KW2x board. Segger's OpenSDA v2.1 will be used as an example of the new OpenSDA firmware (Instead of the default PE Micro's) 1. Unplug the board 2. Insert a Jumper in J30 to put the device in Bootloader mode 3. Plug in the board (Mini-USB) 4. Device will be enumerated as a "Drive Disk" But now with a "Bootloader" label 5. Drag and Drop the Segger's JLink_OpenSDA_V2_1.bin firmware (https://segger.com/opensda.html) into the Bootloader unit 6. Unplug the board 7. Remove Jumper 8. Plug in the board (Mini-USB) Now you should see the board being enumerated as "JLink CDC UART Port", allowing serial port communication. You should also be able to debug your application using J-Link debugging interface through the OpenSDA interface, no need of external hardware. Note1: Drivers can be found at Segger's website (https://segger.com/opensda.html) Note2: Jumper has to be in place in J29 for debugging Note3: IDE options must be set to use J-Link Driver
View full article
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.
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
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
View full article
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
View full article
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
View full article
This Document describes the additional changes needed for JN-AN-1229 ZigBee PRO Application Template for ZigBee version 1002 to be able to compile correctly with the latest update SDK JN-SW-4170 Version 1745 and JN-SW-4270 Version 1746. Note:  These modifications can be also found in the JN516x ZigBee 3.0 SDK Release Notes v1745 (Chapter 4.3 Modifications Required) Tool modifications The .zpscfg file contains all the information available of the setup of the ZigBee network, this file it’s located in C:\...\...\workspace\ JN-AN-1229\Common The first step is to add the MAC Interface List to The ZigBee devices (Co-ordinator, Router, and Sleeping End Device) in the .zpscfg file. Then, add the MAC Interface selecting the New Child option. In the Properties tab, the Co-ordinator and the Router should have the Router Allowed option set to True. Stack modifications The new stack has support for better throughput and automatic buffering of data packets during route discovery. This requires the addition of a new queue in the application. Open the app_common.h file which it’s located in the Common folder. This queue should be tied to the stack definition: extern PUBLIC tszQueue zps_msgMcpsDcfm; After that, open the app_router.c and app_sleeping_enddevice.c. The ZPS_tsAplAib structure has been changed, so, the vStartup function should be modified Old version /* Set channel to scan and start stack */ ZPS_psAplAibGetAib()->apsChannelMask = 1 << u8Channel; Update needed /* Set channel to scan and start stack */ ZPS_psAplAibGetAib()->pau32ApsChannelMask[0] = 1 << u8Channel; Add the next code to the app_start.c(Coordinator and Router) and app_start_SED.c(Sleeping End Device) The buffer of the Router device should be modified. The size of the queue is defined as: #define MCPS_DCFM_QUEUE_SIZE 5 The storage of the queue must be defined: PRIVATE MAC_tsMcpsVsCfmData asMacMcpsDcfm[MCPS_DCFM_QUEUE_SIZE]; In the APP_vInitResources function an additional queue must be added: ZQ_vQueueCreate(&zps_msgMcpsDcfm, MCPS_DCFM_QUEUE_SIZE,  sizeof(MAC_tsMcpsVsCfmData),(uint8*)asMacMcpsDcfm);  
View full article
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
View full article
Hello, Starting with SDK version 24.12.00, documentation is available online at: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/index.html  To view documentation for previous releases, replace latest in the URL with the specific version number: - example: https://mcuxpresso.nxp.com/mcuxsdk/25.03.00/html/index.html    Bluetooth LE Documentation For Bluetooth LE-related resources, refer to the following sections:  Bluetooth LE Host Documentation (change log and guides): https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/wireless/bluetooth/index.html    Connectivity Framework Documentation(change log and guides):  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/wireless/framework/index.html   Release Notes by platform To view what's new for each platform, refer to the "What is new" section in the respective release notes: KW45 - EVK:  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/boards/Wireless/kw45b41zevk/releaseNotes/rnindex.html   KW47-EVK:  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/boards/Wireless/kw47evk/releaseNotes/rnindex.html FRDM-MCXW23:  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/boards/MCX/frdmmcxw23/releaseNotes/rnindex.html  Regards, Ovidiu    
View full article
Using the Signal Frequency Analyzer (SFA) to Measure the FRO 6M Frequency Overview The Signal Frequency Analyzer (SFA) is a specialized hardware peripheral available in NXP’s KW45, MCXW71 microcontrollers. It is designed to provide precise, real-time measurement and analysis of digital signal characteristics, including frequency, period, and timing intervals. This makes it a valuable tool for applications requiring accurate timing diagnostics, signal validation, and system debugging. By utilizing internal 32-bit counters and configurable trigger mechanisms, the SFA enables high-resolution capture of signal transitions, supporting robust system monitoring and fault detection. Functional Capabilities of the SFA The SFA module supports the following measurements: Clock signal frequency of a Clock Under Test (CUT) Clock signal period It operates using two 32-bit counters: One for the Reference Clock (REF) One for the Clock Under Test (CUT) Measurement is performed by comparing the counts of both clocks until predefined target values are reached. FRO 6M Frequency Failure Scenarios The 6 MHz Free Running Oscillator (FRO6M) may occasionally output an incorrect frequency under certain conditions: When the device exits reset When the device wakes from low-power modes To mitigate potential issues caused by incorrect FRO6M output, it is the application developer’s responsibility to verify the oscillator’s frequency and apply corrective measures as needed. Monitoring the FRO 6M Using the SFA To monitor the FRO6M signal, the following configuration is recommended: SFA Configuration Parameters Reference Clock (REF): CPU Clock (e.g., 96 MHz) Clock Under Test (CUT): FRO6M routed via CLKOUT Interrupt Mode: Enabled for asynchronous measurement completion Code Implementation The presented functions are meant to be implemented in users application, the inner functions are part of the implementations of the SFA driver from the NXP’s SDK. It can be used on MCXW71, KW45 just make sure SFA Peripheral Initialization  void init_SFA_peripheral(void) { /* Enable SFA interrupt. */ EnableIRQ(SFA_IRQn); /* Set SFA interrupt priority. */ NVIC_SetPriority(SFA_IRQn, 1); SFA_Init(DEMO_SFA_BASEADDR); SFA_InstallCallback(DEMO_SFA_BASEADDR, EXAMPLE_SFA_CALLBACK); } SFA Callback Function void EXAMPLE_SFA_CALLBACK(status_t status) { if (status == kStatus_SFA_MeasurementCompleted) { SfaMeasureFinished = true; } sfa_callback_status = status; } Frequency Measurement Function This function sets up the measurement of the FRO6M signal using the CPU clock as the reference. uint8_t SFA_freq_measurement_6M_FRO(void) { uint8_t ratio = 0; uint32_t freq = 0UL; sfa_config_t config; CLOCK_SetClkOutSel(kClockClkoutSelSirc); //set clokout to SIRC SFA_GetDefaultConfig(&config); //Get SFA default config config.mode = kSFA_FrequencyMeasurement0; config.refSelect = kSFA_REFSelect1; //Set CPU clk as ref clk config.cutSelect = kSFA_CUTSelect1; //Set clkout as CUT config.refTarget = 0xFFFFFFUL; config.cutTarget = 0xFFFFUL; config.enableCUTPin = true; freq = get_ref_freq_value(CPU_CLK); SFA_SetMeasureConfig(DEMO_SFA_BASEADDR, &config); SFA_MeasureNonBlocking(DEMO_SFA_BASEADDR); while (1) { if (SfaMeasureFinished) { SfaMeasureFinished = false; if(kStatus_SFA_MeasurementCompleted == sfa_callback_status) { freq = SFA_CalculateFrequencyOrPeriod(DEMO_SFA_BASEADDR, freq);//Calculate the FRO freq if(FREQ_6MHZ + TOLERANCE <= freq ) { ratio = 1; } else { if(FREQ_3MHZ + TOLERANCE <= freq) { ratio = 2; } else { if(FREQ_2MHZ + TOLERANCE <= freq) { ratio = 3; } else { ratio = 4; } } } break; } } else { __WFI(); } } return ratio; } Result Interpretation and Usage To test the FRO 6M after adding the above functions the FRO can be tested after executing: init_SFA_peripheral(); SFA_freq_measurement_6M_FRO(); The measured FRO6M frequency ratio is returned by the function SFA_freq_measurement_6M_FRO(), with the ratio you can know the current frequency output of the 6M FRO, ration 1 means 6M are being output by the FRO, ratio 2 means the frequency output of the FRO it's being cut in half meaning the FRO is outputting 3 Mhz, ration 3 means the FRO output frequency is being cut by a third part, this results in 2MHz frequency output. With this information you can: Adapt peripheral clocking if the FRO6M frequency is incorrect (This can be achieve by modifying the peripheral dividers if dividers are being used). Trigger corrective actions such as  switching to an alternate clock source Steps to Reconfigure Peripheral Clocking When FRO6M output frequency is lower Detect the Faulty FRO6M Output Use the SFA measurement as described earlier to determine if the FRO6M is operating below its expected frequency (6 MHz). If the result is significantly lower, proceed to reconfigure. Choose an Alternative Clock Source Most NXP MCUs offer multiple internal and external clock sources. Common alternatives include: FRO 192M OSC RF 32M Sys OSC RTC OSC Choose one that is: Stable Available in your current power mode Compatible with the peripheral’s timing requirements You can add more clock divers if needed to make a higher frequency clock reach a certain lower frequency. Reconfigure the Peripheral Clock Source Use the SDK’s CLOCK_Set... APIs to change the clock source. You may also need to: Adjust dividers to match the required baud rate or timing Reinitialize the peripheral with the new clock settings Example Scenario: Measuring the FRO and Adjusting UART Based on Frequency Ratio Imagine your application relies on the 6 MHz Free Running Oscillator (FRO), and its accuracy directly affects UART communication. To ensure reliable operation, you can use the System Frequency Adjustment (SFA) feature to monitor the FRO output and dynamically adjust the UART configuration. After measuring the 6 MHz FRO using the recommended method, the system returns a frequency ratio value. This value ranges from 1 to 4, where: 1 indicates the frequency is within expected limits (no issues), 2 to 4 represent varying degrees of deviation from the expected frequency. Using this ratio, you can initialize and configure the UART peripheral and its driver to compensate for any frequency variation, ensuring stable and accurate communication. */ int main(void) { BOARD_InitHardware(); uint8_t ch = 0; uint8_t FRO_ratio = 0; init_SFA_peripheral(); /*Measure FRO6M output frequency*/ FRO_ratio = SFA_freq_measurment_6M_FRO(); /*Init debug console and compensate in case a different frequency is output */ if(0 == FRO_ratio) { assert(0);//this user defined return value means something went wrong while measuring 6Mz FRO } uint32_t uartClkSrcFreq = BOARD_DEBUG_UART_CLK_FREQ/FRO_ratio;//Compensate the src frequency set for uart module CLOCK_EnableClock(kCLOCK_Lpuart1); CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); ...... } SDK 25.0.00 Enhancements for FRO6M Calibration To address known reliability issues with the 6 MHz Free Running Oscillator (FRO6M), particularly during transitions from low-power modes, SDK version 25.06.00 introduces a set of software enhancements aimed at improving oscillator validation and calibration. Key Features Introduced FRO6M Calibration API Two new functions have been added to facilitate runtime verification of the FRO6M frequency: PLATFORM_StartFro6MCalibration() Initializes the calibration process by enabling the cycle counter, capturing a timestamp, and preparing the system to measure elapsed time using both the CPU and the FRO6M-based timestamp counter. PLATFORM_EndFro6MCalibration() Completes the calibration by comparing the time measured via CPU cycles and the FRO6M timestamp counter. This comparison determines whether the oscillator is operating at the expected 6 MHz or has erroneously locked to a lower frequency (e.g., 2 MHz). The result is stored in a global ratio variable (fwk_platform_FRO6MHz_ratio) for use by the system. These functions provide a lightweight and efficient mechanism to detect and respond to oscillator misbehavior, ensuring system stability and timing accuracy. Configuration Macro gPlatformEnableFro6MCalLowpower_d This macro enables automatic FRO6M frequency verification upon exiting low-power modes. When defined, the system will invoke the calibration functions to validate the oscillator before resuming normal operation. Default Integration The calibration mechanism is enabled by default in the SDK configuration file fwk_config.h, ensuring that all applications benefit from this safeguard without requiring manual setup. Use Case and Benefits These enhancements are particularly valuable in applications where: Precise timing is critical (e.g., wireless communication, sensor sampling). The system frequently enters and exits low-power states. Clock source integrity must be guaranteed to avoid peripheral misbehavior or timing faults. By integrating these calibration routines, developers can proactively detect and correct FRO6M frequency anomalies, improving overall system robustness and reducing the risk of runtime errors due to clock instability.  
View full article
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.
View full article
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.
View full article
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.
View full article
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.
View full article
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.
View full article
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 full article