Wireless Connectivity Knowledge Base

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

Wireless Connectivity Knowledge Base

Discussions

Sort by:
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
This article shares 2 step by step methods to create P2P connections between 2 IW612 modules. One is not setting pin code, another is setting pin code. And also shares local test results and printed logs for your reference. The basic environment: Hardware: 2 IW612 modules(Murata LBES5PL2EL) + I.MX93-EVK Software: Linux 6.12.20 Wi-Fi Driver and FW version = SDIW612---w9177o-V1, SDIO, FP99, 18.99.3.p25.7-MM6X18537.p9-GPL-(FP92) As a reference, you can also test on other NXP's Wi-Fi products based on Linux OS.   Best regards, Christine.
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
Matter is the industry-unifying standard from the Connectivity Standards Alliance that is delivering reliable, secure and interoperable connectivity for smart home devices, ensuring that they will work seamlessly together, today and tomorrow. From connectivity to security, processing and software, NXP offers complete end-to-end solutions for accelerating the development of Matter-enabled devices and is focused on helping our customers overcome the complexity and challenges that come with developing around this game-changing technology.   Getting Started Our investment in Matter starts with easing the development experience for adopting Matter in existing or new designs. With the breadth and scale of our portfolios, we scale to the system level to enable the autonomous edge - bringing intelligence to the edge. This approach provides developers with integrated platforms for the processing, connectivity and security requirements to go from prototype to production faster.   Matter Open-Source Protocol Compatible Products    Matter (previously known as Project CHIP) is a single, unified, application-layer connectivity standard designed to enable developers to connect and build reliable, secure IoT ecosystems and increase compatibility among Smart Home and Building devices. Backed by major brands and developed through collaboration within the Connectivity Standards Alliance (previously known as the Zigbee Alliance), Matter is an open-source royalty-free connectivity standard built with market-proven technologies using Internet Protocol (IP) and compatible with Thread and Wi-Fi network transports.   Useful Links   Getting Started with MCUXpresso for VS Code: Matter on Windows (24.12.71) MCUXpresso extension for VS Code v24.12.71 integrates the Matter toolchain for development on Windows, macOS and Linux.    Understanding Matter Terminology   Matter Is What's Cooking and NXP Has All the Right Ingredients     Matter GitHub Links    Releases Matter 
View full article
Board pictures (KW47-M2) Connectors (KW47-M2) Part Identifier Connector Type Description J3 2x5 pin header SWD DNP J8 1x6 pin header UART1 – FTDI DNP J9 1x6 pin header Power connector DNP Jumpers (KW47-M2) Part Identifier Connector Type Description JP5 2x3 pin header supply power source selection jumper: 1-2 shorted (default configuration): Use this configuration to set target MCU in DCDC mode.  3-4 shorted: Use this configuration to set target MCU in LDO/Bypass mode. All MCU power domains are supplied by P3V3_DUT.  JP4 1x2 pin header Target MCU boot configuration enable jumper: • Open (default setting): ISP mode is disabled • Shorted: ISP mode is enabled Push Buttons (KW47-M2) Part Identifier Switch name Description SW1 Reset button Resets the target MCU. This causes peripherals to reset to their default state. After this, MCU ROM bootloader will be executed. LED D1 turns on at SW1 press. SW2 User PB General purpose input. This pin supports low-power wakeup capabilities through Wake-Up Unit (WUU). LEDs (KW47-M2) Part Identifier Switch name Description D1 Reset LED Indicates a system reset event. When reset is triggered—such as by pressing the SW1 reset button—the D1 LED turns ON. D2 Led Green User indicator, indicates system activity   Power Configurations (KW47-M2) Populate J9 PWR connector. To run KW47 M2 as standalone, supply 3.3V to P3V3_DUT power rail Figure 1 J9 M10 Configuration (KW47-M2)   To get the KW47 M2 up and running, you need to select a power configuration through JP5 jumper. For more information on KW47 power configurations, refer to RM: Part Identifier pin Description JP5 1-2 1-2 shorted (default setting): Sets target MCU to DCDC mode. This mode is the recommended configuration. JP5 3-4 3-4 shorted: Sets target MCU to LDO mode.     External power configuration (KW47-M2) Enable KW47-M2 by supplying power through J9 connector: Note: When using DCDC or LDO mode, it is recommended to supply P3V3_DUT power rail only. Part Identifier pin Description J9 5 Use this pin to supply P3V3_DUT power rail with 3.3V. To get KW47-M2 up and running, it is recommended to set KW47 to DCDC mode and supply P3V3_DUT only. J9 3 Use this pin to supply P1V8_LDO power rail with 1.8V. This power rail is intended for an accurate control of VDD_RF power domain, but it is not necessary. J9 1 Use this pin to supply P1V1_EXT power rail with 1.1V. This power rail is intended for an accurate control of VDD_CORE power domain, but it is not necessary.     Programming the NBU in the KW47-M2 board The following steps guide you to program the NBU software for the KW47-M2 Place a jumper on the JP4 header while holding down the reset button (SW) on the module board. Then, connect the USB cable to the J8 connector (USB-to-serial bridge) and plug it into your computer. After the USB cable is connected, release the reset button.   Verify what COM Port was assigned to your KW47-M2 board. You can check the COM Port assigned in the Windows “Device Manager” program. Search for “Ports (COM & LPT)” and save the COM Port number. In this example the COM Port assigned was “COM19”   Navigate to your computer to the MCU-Link installation folder. The default installation path is located at “C:\nxp\LinkServer_25.3.31\MCU-LINK_installer Locate the “bin” folder and open it. Run the script “blhost” within a windows command prompt.   Type “blhost.exe -p COMX write-memory 0x48800000”, drag and drop the NBU binary file. When the process is ready you will see the response status "success"  
View full article
The slides were prepared for European School of Antennas at Carlos III University in Madrid. The contents: - About NXP and wireless controllers - About channel sounding and NXP solutions - Design of CS antennas and functional tests - CS antenna arrays and CS localization
View full article
In modern embedded systems, precise and reliable clocking is fundamental to the correct operation of digital peripherals. Microcontrollers like NXP’s KW45 and MCXW71 rely on internal oscillators to provide timing references for peripherals such as UART, SPI, timers, and ADCs. One such oscillator is the 6 MHz Free Running Oscillator (FRO6M), which is commonly used as a default clock source. This article provides a comprehensive guide to: Selecting and configuring alternative clock sources Choosing an alternative clock source The KW45/MCXW71 microcontroller offers several alternatives, including the Free Running Osilator 192Mhz (FRO192), the RF_OSC , and external crystal oscillators. Each option has its own advantages: FRO192 is stable and available, and external oscillators provide long-term accuracy. The choice of clock source should be based on the peripheral’s timing requirements, power constraints, and the availability of the clock in the current operating mode. Reconfiguring Peripheral Clock Sources Reconfiguring a peripheral’s clock source in KW45 is straightforward using the SDK’s clock management APIs. The function CLOCK_SetIpSrc() allows developers to assign a new clock source to a specific peripheral. Example on changing a UART clocking from FRO6M to other clocksource. UART peripheral connected to FRO6M   uint32_t uartClkSrcFreq = BOARD_DEBUG_UART_CLK_FREQ; CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq);   For example, to switch a UART from FRO6M to FRO-192M, the following code can be used: //Replace kCLOCK_Lpuart1 for your peripheral for clicking CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); Also in the example above we would have to set the  uint32_t uartClkSrcFreq  variable to the correct freq value corresponding to the FRO192M as it is being used as clock source, but the same logic applies to any other clock source for the peripheral.   Other clocking changes for modules can be done as shown in this examples: //Change clock source for LPIT 0 module from 6M FRO to other clocksources /* Iniital source for the LPIT module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro6M); /* Set the new source for the LPIT 0 module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Lpit0, 15U); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro6M); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Tpm0, 3U); //Change clock source for Luart 1 module from 6M FRO to other clocksources CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); /* Set the source for the Lpuart 1 module */ CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); uartClkSrcFreq = CLOCK_GetIpFreq(kCLOCK_Lpuart1); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); After changing the clock source, it is important to reinitialize the peripheral to ensure that timing parameters such as baud rate, prescaler, or sampling intervals are correctly recalculated. This step ensures that the peripheral operates reliably with the new clock configuration. Those were some examples on changing clock sources for some peripherals, but the same logic can be applied to any other module or peripheral, those examples were taken from SDK 2.16.00 as an example on how a module configured with a clock source can be switched to another.
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
See the necessary steps to enable additional SDK components for a project when using GitHub SDK and Kconfig/CMake.
View full article
The wireless examples feature many common Bluetooth, zigbee and thread configurations. This article describes each SDK example.  MCUs: KW45 K32W1 KW47 MXCW71/72 Category SDK Example Name Description comments BLE Controller hci_bb the HCI black box demo gives access to the BLE controller via serial interface using commands and events.    Bluetooth adv_ext_central the adv_ext_central implements a custom GATT based temperature Profile. After pairing with the peripheral, it configures notifications and displays temperature values on a terminal.  Board to Board Bluetooth adv_ext_peripheral the adv_ext_peripheral implements a custom GATT based temperature Profile. it begins with a general discoverable mode and waits for the central node to connect and configure notifications for the temperature value.  Board to Board Bluetooth ancs_c the demo acts as a peripheral that advertises a service solicitation for custom ANCS service. Also, can acts as a client once connected to the device offering the ANCS service. The application displays information about ANCS notifications received from the mobile. this service is available on iOS mobile devices.   Bluetooth beacon the demo has non-connectable advertising packets that are sent on the three advertising channels. From the info sent by the beacon we can see: company identifier.  beacon identifier.  UUID, by default this value is a random value based on the UI of the board.  some beacon application data  RSSI IoT toolbox app Bluetooth ble_fscibb implements a custom GATT based wireless UART profile. it can be possible to interact with the device through a serial terminal.    Serial Terminal  Bluetooth ble_shell implements a console application that allows the user to interact with a full feature BLE stack library. implements GAP roles and both client and server, to enabling these roles can be done using some commands. this demo allows the user to add, erase or modify services.  Serial Terminal Bluetooth eatt_central the application behaves as a GAP central node. It scans for an EATT peripheral to connect to. Once connected it performs service discovery, initiates an EATT connection and configures indications on the peripheral for services A and B.  The central reports the received service data and steps taken during the setup on a serial terminal.  Board to Board Bluetooth eatt_peripheral the application behaves as a GAP peripheral node. it works a as general discoverable mode and waits for a GAP central node to connect. This application implements two services, Service A and Service B. After the EATT connection in completed, the peer must enable indications for the two services to periodically receive profile data over EATT.   Board to Board Bluetooth hid_device (Mouse) the demo moves the cursor in a square pattern between a min and max axis. this demo behaves as a GAP peripheral node with a general discoverable mode that waits for a GAP central node to connect.    Bluetooth hid_host the application behaves as a GAP central node. it works as a GAP limited discovery Procedure and searches for HID devices to connect to. After connecting with the peripheral node, it configures notifications and displays the received HID reports on a serial terminal.  Serial Terminal Bluetooth loc_reader the application behaves as a GAP peripheral node. This application has the RASP profile implemented; it advertises for compatible devices, once it connected begins to send ranging data to the central device.  Board to Board Bluetooth loc_user_device the application behaves as a GAP central node. it scans for compatible devices, once it connected begins to send ranging commands to the peripheral device and calculates the distance estimation based on the information received.  Board to Board Bluetooth otac_att the over the air programming client is a GAP peripheral which advertising the BLE OTAP service and waits for a connection from an OTAP server. After an OTAP server connects, the OTAP client waits for it to write the OTAP control point CCCD and then starts sending commands via ATT indications.  over the air programming tool //IoT toolbox app Bluetooth otac_I2cap (different transfer method) The over the air programming client is a GAP peripheral which advertising the BLE OTAP service and waits for a connection from an OTAP server. After an OTAP server connects, the OTAP client waits for it to write the OTAP control point CCCD and then starts sending commands via ATT indications.  over the air programming tool // IoT toolbox app Bluetooth otas the Over the air programming server application is a GAP central which scans for devices advertising the BLE OTAP service. After it finds one, it connects to it and configures the OTAP control point CCC descriptor to receive ATT indications from the device then it waits fir OTAP commands from the device.  over the air programming tool // IoT toolbox app Bluetooth temp_coll the application behaves as a GAP central node, it enters GAP limited discovery procedure and searches for sensor devices to pair with. After pairing with the peripheral, it configures notifications and displays temperature values on a serial terminal.  Board to Board Bluetooth temp_sens the application behaves as a GAP peripheral node. it enters GAP general discoverable mode and waits for a GAP central node to connect and configure notifications for the temperature value.  Board to Board Bluetooth w_uart implements a custom GATT based wireless UART profile. it can be possible to interact with the device through a serial terminal.  IoT toolbox app Bluetooth wireless_ranging Is used to perform secure and highly accurate distance estimation between two BLE device.  the application is made of two parts: The embedded firmware, that can be controlled manually via serial connection. the host application (python) running on a PC and controlling the firmware using serial link. Wireless Ranging application allows to: Configure most of the parameters required for measurement. Select what type of measurement to be performed.  Trigger CS measurements using range or test command. Log system debug information but also raw IQ data information in MatLab. Board to Board  genfsk connectivity_test   Board to Board ieee_802.15.4 connectivity_test   Board to Board reference design bluetooth this application is based on a GATT temperature Service and demonstrates power consumption optimization in BLE. The power consumption is optimized during advertising, connected and no activity states.   
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
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  
View full article
Useful Links: Bluetooth Ranging Access Vehicle Enablement System - NXP Community
View full article
As documented in the MCX W23 [ERRATA] for WLCSP packaged devices, Tx modulation quality can potentially be violated on 2 data channels
View full article
This article introduces the Wi-Fi automatic recovery feature as well as how to enable and verify it on RW61x SDK. 1. Introduction Wi-Fi automatic recovery is a NXP proprietary feature that monitors Wi-Fi running status and recovers Wi-Fi out of exception state when running into one of the following cases: Driver fails to wakeup Wi-Fi MCU for commands/Tx Driver fails to receive command response from Wi-Fi MCU Driver detects Wi-Fi firmware is in abnormal state Once Wi-Fi automatic recovery is triggered, Wi-Fi middleware and driver will clean up the running states, reset Wi-Fi MCU power, reload Wi-Fi firmware and restart Wi-Fi initialization. It will not impact the ongoing Bluetooth LE/802.15.4 activities. Figure 1 is the Wi-Fi software architecture. Figure 1: Wi-Fi Software Architecture Figure 2 shows the work flow of Wi-Fi automatic recovery: Figure 2: Wi-Fi Automatic Recovery Work Flow Wi-Fi driver detects command timeout/wakeup card timeout/FW exception   Wi-Fi driver triggers WLAN reset to Stop Wi-Fi activities and de-initialize Wi-Fi Reset Wi-Fi power Reload the Wi-Fi only firmware and wait for the firmware to be active Send an event to notify the application before resetting it   2. SDK Configuration The Wi-Fi automatic recovery feature is not enabled by default in RW61x SDK. It needs to be enabled explicitly: Add below line in <example>/source/wifi_config.h to enable the feature  #define CONFIG_WIFI_RECOVERY 1 Besides, please also make sure the "CONFIG_WIFI_RESET" macro is defined as "1" in the SDK.   3. Automatic Recovery Verification This section introduces how to verify the Wi-Fi automatic recovery feature on RW61x SDK. wifi_cli application is used as example here together with the RW612 RD board. Refer to UM11799: NXP Wi-Fi and Bluetooth Demo Applications for RW61x for steps to flash and run Wi-Fi applications. Below are the steps to verify the Wi-Fi automatic recovery feature: Step 1: Define CONFIG_WIFI_RECOVERY in wifi_cli/source/wifi_config.h     #define CONFIG_WIFI_RECOVERY 1 Step 2: Build and flash the wifi_cli application onto RW612 RD board Step 3: Connect RW612 RD board to a serial terminal Step 4: Reset the power of RW612 RD board Step 5: Trigger Wi-Fi MCU into hung-up state with the following command to mimic a command timeout     # wlan-recovery-test Step 6: Wi-Fi recovery background task detects Wi-Fi FW hang and starts recovery process [wifi] Warn: Command response timed out. command 0x8b, len 12, seqno 0x1c timeout happends. # app_cb: WLAN: FW hang Event: 14 --- Disable WiFi --- [wifi] Warn: Recovery in progress. command 0x10 skipped [wifi] Warn: Recovery in progress. command 0x10 skipped [wifi] Warn: Recovery in progress. command 0xaa skipped [dhcp] Warn: server not dhcpd_running. --- Enable WiFi --- Initialize WLAN Driver [wifi] Warn: WiFi recovery mode done! Wi-Fi cau temperature : 31 STA MAC Address: C0:95:DA:01:1D:A6 board_type: 2, board_type mapping: 0----QFN 1----CSP 2----BGA app_cb: WLAN initialized ======================================== WLAN CLIs are initialized ======================================== ENHANCED WLAN CLIs are initialized ======================================== HOST SLEEP CLIs are initialized ======================================== CLIs Available: ======================================== help clear wlan-version wlan-mac wlan-thread-info wlan-net-stats wlan-set-mac <MAC_Address> wlan-scan wlan-scan-opt ssid <ssid> bssid ... wlan-add <profile_name> ssid <ssid> bssid... wlan-remove <profile_name> wlan-list wlan-connect <profile_name> wlan-connect-opt <profile_name> ... wlan-reassociate wlan-start-network <profile_name> wlan-stop-network wlan-disconnect wlan-stat wlan-info wlan-address wlan-uap-disconnect-sta <mac address> wlan-get-uap-channel wlan-get-uap-sta-list wlan-ieee-ps <0/1> wlan-set-ps-cfg <null_pkt_interval> wlan-deep-sleep-ps <0/1> wlan-get-beacon-interval wlan-get-ps-cfg wlan-set-max-clients-count <max clients count> wlan-get-max-clients-count wlan-rts <sta/uap> <rts threshold> wlan-frag <sta/uap> <fragment threshold> wlan-host-11k-enable <0/1> wlan-host-11k-neighbor-req [ssid <ssid>] wlan-host-11v-bss-trans-query <0..16> wlan-mbo-enable <0/1> wlan-mbo-nonprefer-ch <ch0> <Preference0: 0/1/255> <ch1> <Preference1: 0/1/255> wlan-get-log <sta/uap> <ext> wlan-roaming <0/1> <rssi_threshold> wlan-multi-mef <ping/arp/multicast/del> [<action>] wlan-wakeup-condition <mef/wowlan wake_up_conds> wlan-auto-host-sleep <enable> <mode> <rtc_timer> <periodic> wlan-send-hostcmd wlan-ext-coex-uwb wlan-set-uap-hidden-ssid <0/1/2> wlan-eu-crypto-rc4 <EncDec> wlan-eu-crypto-aes-wrap <EncDec> wlan-eu-crypto-aes-ecb <EncDec> wlan-eu-crypto-ccmp-128 <EncDec> wlan-eu-crypto-ccmp-256 <EncDec> wlan-eu-crypto-gcmp-128 <EncDec> wlan-eu-crypto-gcmp-256 <EncDec> wlan-set-antcfg <ant_mode> <evaluate_time> <evaluate_mode> wlan-get-antcfg wlan-scan-channel-gap <channel_gap_value> wlan-wmm-stat <bss_type> wlan-reset wlan-set-regioncode <region-code> wlan-get-regioncode wlan-11d-enable <sta/uap> <0/1> wlan-uap-set-ecsa-cfg <block_tx> <oper_class> <new_channel> <switch_count> <bandwidth> wlan-csi-cfg wlan-set-csi-param-header <sta/uap> <csi_enable> <head_id> <tail_id> <chip_id> <band_config> <channel> <csi_monitor_enable> <ra4us> wlan-set-csi-filter <opt> <macaddr> <pkt_type> <type> <flag> wlan-txrx-histogram <action> <enable> wlan-subscribe-event <action> <type> <value> <freq> wlan-reg-access <type> <offset> [value] wlan-uapsd-enable <uapsd_enable> wlan-uapsd-qosinfo <qos_info> wlan-uapsd-sleep-period <sleep_period> wlan-tx-ampdu-prot-mode <mode> wlan-rssi-low-threshold <threshold_value> wlan-rx-abort-cfg wlan-set-rx-abort-cfg-ext enable <enable> margin <margin> ceil <ceil_thresh> floor <floor_thresh> wlan-get-rx-abort-cfg-ext wlan-cck-desense-cfg wlan-net-monitor-cfg wlan-set-monitor-filter <opt> <macaddr> wlan-set-monitor-param <action> <monitor_activity> <filter_flags> <radio_type> <chan_number> wlan-set-tsp-cfg <enable> <backoff> <highThreshold> <lowThreshold> <dutycycstep> <dutycycmin> <highthrtemp> <lowthrtemp> wlan-get-tsp-cfg wlan-get-signal wlan-set-bandcfg wlan-get-bandcfg wlan-set-ips <option> wlan-enable-disable-htc <option> wlan-set-su <0/1> wlan-set-forceRTS <0/1> wlan-set-mmsf <enable> <Density> <MMSF> wlan-get-mmsf wlan-set-multiple-dtim <value> wlan-set-country <country_code_str> wlan-set-country-ie-ignore <0/1> wlan-single-ant-duty-cycle <enable/disable> [<Ieee154Duration> <TotalDuration>] wlan-dual-ant-duty-cycle <enable/disable> [<Ieee154Duration> <TotalDuration> <Ieee154FarRangeDuration>] wlan-external-coex-pta enable <PTA/WCI-2/WCI-2 GPIO> ExtWifiBtArb <enable/disable> PolGrantPin <high/low> PriPtaInt <enable/disable> StateFromPta <state pin/ priority pin/ state input disable> SampTiming <Sample timing> InfoSampTiming <Sample timing> TrafficPrio <enable/disable> CoexHwIntWic <enable/disable> wlan-sta-inactivityto <n> <m> <l> [k] [j] wlan-get-temperature wlan-auto-null-tx <sta/uap> <start/stop> wlan-detect-ant <detect_mode> <ant_port_count> channel <channel> ... wlan-recovery-test wlan-get-channel-load <set/get> <duration> wlan-get-txpwrlimit <subband> wlan-set-chanlist wlan-get-chanlist wlan-set-txratecfg <sta/uap> <format> <index> <nss> <rate_setting> <autoTx_set> wlan-get-txratecfg <sta/uap> wlan-get-data-rate <sta/uap> wlan-get-pmfcfg wlan-uap-get-pmfcfg wlan-set-ed-mac-mode <interface> <ed_ctrl_2g> <ed_offset_2g> <ed_ctrl_5g> <ed_offset_5g> wlan-get-ed-mac-mode <interface> wlan-set-tx-omi <interface> <tx-omi> <tx-option> <num_data_pkts> wlan-set-toltime <value> wlan-set-rutxpwrlimit wlan-11ax-cfg <11ax_cfg> wlan-11ax-bcast-twt <dump/set/done> [<param_id> <param_data>] wlan-11ax-twt-setup <dump/set/done> [<param_id> <param_data>] wlan-11ax-twt-teardown <dump/set/done> [<param_id> <param_data>] wlan-11ax-twt-report wlan-get-tsfinfo <format-type> wlan-set-clocksync <mode> <role> <gpio_pin> <gpio_level> <pulse width> wlan-suspend <power mode> ping [-s <packet_size>] [-c <packet_count>] [-W <timeout in sec>] <ipv4/ipv6 address> iperf [-s|-c <host>|-a|-h] [options] dhcp-stat ======================================== --- Done --- Step 7: Run other Wi-Fi shell commands to confirm Wi-Fi resumes to normal state  
View full article
Introduction: Bluetooth Low Energy offers the ability to broadcast data in format of non-connectable advertising packets while not being in a connection. This GAP Advertisement is widely known as a beacon.   In this post we will explore some of the features of the beacon_freertos example included in the SDK package of the KW45B41Z Evaluation Kit for MCUXpresso, for updating a counter every 5 seconds and broadcasting its value with the beacon, so the user can see it using the IoT Toolbox application.    Setup: 1 – SDK installation Download the latest version of the KW45B41Z-EVK SDK package from MCUXpresso SDK Builder Drag and drop the SDK zip file into the Installed SDKs window:   2 – Importing the project In the QuickStart Panel, click on Import SDK example From wireless_examples, select beacon_freertos. It is recommended to select UART for Debug Console when using BLE projects.  Click on finish   App Customization  1 – app_preinclude.h file: Set the following definitions to "0" in order to disable Extended Advertising and Low Power functionality.   2 – app_advertiser.h file: Add these aux prototypes that will allow to get and set the value of some flags.   /*Functions for data exchanging with beacon application*/ bool_t GetBleAppStarted(void); bool_t GetmAdvertisingOn(void); void SetmAdvertisingOn(bool_t value);   3 – app_advertiser.c file: Include fsl_component_timer_manager.h Add the macro UPDATE_BEACON_TIMER (5) to set the update timer to 5 seconds Create a timer ID by using TIMER_MANAGER_HANDLE_DEFINE Declare the callback for the timer Declare and define the "flag" BleAppStarted Include extern variable gAppAdvertisingData   Define the aux functions that will allow to get and set the value of BleAppStarted and mAdvertisingOn flags.   Define the timer callback, which will add the value of the counter into "A" field of the Beacon packet. #include "fsl_component_timer_manager.h" #define UPDATE_BEACON_TIMER (5) //in seconds /*Create timer ID*/ static TIMER_MANAGER_HANDLE_DEFINE(BeaconUpdateDataTimerID); /*Callback prototype*/ static void UpdateBeaconTimerCallback(void * pParam); /*Define the variables*/ static bool_t BleAppStarted = FALSE; static bool_t mAdvertisingOn = FALSE; /*Declare variable as external*/ extern gapAdvertisingData_t gAppAdvertisingData; /*Define functions for data echange*/ bool_t GetBleAppStarted(void) { return BleAppStarted; } bool_t GetmAdvertisingOn(void) { return mAdvertisingOn; } void SetmAdvertisingOn(bool_t value) { mAdvertisingOn = value; } /*define the timer callback*/ static void UpdateBeaconTimerCallback(void * pParam) { /*Value that will be advertised*/ static int32_t count = 1; /* Stop ADV and handle the update on the callbacks*/ Gap_StopAdvertising(); mAdvertisingOn = !mAdvertisingOn; /* On ADV data 0-1 = company ID, 2 = Beacon ID, 3 -18 = UUID, /* 19-20: A Data, 21-22: B Data, 23-24: C Data */ gAppAdvertisingData.aAdStructures[1].aData[19] = (uint8_t)((count >> 8) & 0xFF); gAppAdvertisingData.aAdStructures[1].aData[20] = (uint8_t)(count & 0xFF); count++; }   Inside App_AdvertiserHandler function, gAdvertisingParametersSetupComplete_c event is triggered when the advertising parameters setup is complete. Here, Advertising Data is set, and we are going to use this event to start the timer. Once the Advertising Data Setup is complete, we are going to use gAdvertisingDataSetupComplete_c event in App_AdvertiserHandler function to start advertising and update the timer. Every time the Data Setup is complete, the timer will start again.  case gAdvertisingParametersSetupComplete_c: { (void)Gap_SetAdvertisingData(mpAdvParams->pGapAdvData, mpAdvParams->pScanResponseData); if (!BleAppStarted) { BleAppStarted = TRUE; /*Allocate timer*/ (void) TM_Open(BeaconUpdateDataTimerID); /* Start data update timer */ (void) TM_InstallCallback((timer_handle_t) BeaconUpdateDataTimerID, UpdateBeaconTimerCallback, NULL); (void) TM_Start((timer_handle_t) BeaconUpdateDataTimerID, (uint8_t) kTimerModeSingleShot | (uint8_t) kTimerModeLowPowerTimer, TmSecondsToMilliseconds(UPDATE_BEACON_TIMER)); } } break; case gAdvertisingDataSetupComplete_c: { (void) Gap_StartAdvertising(App_AdvertisingCallback, App_ConnectionCallback); /* Start data update timer */ (void) TM_InstallCallback((timer_handle_t) BeaconUpdateDataTimerID, UpdateBeaconTimerCallback, NULL); (void) TM_Start((timer_handle_t) BeaconUpdateDataTimerID, (uint8_t) kTimerModeSingleShot | (uint8_t) kTimerModeLowPowerTimer, TmSecondsToMilliseconds(UPDATE_BEACON_TIMER)); } break;   4 – beacon.c file:  Wrap the mAppExtAdvParams structure inside gBeaconAE_c definition macro to avoid problems with the declaration of the extended advertising parameters  #if defined(gBeaconAE_c) && (gBeaconAE_c) static appExtAdvertisingParams_t mAppExtAdvParams = { &gExtAdvParams, &gAppExtAdvertisingData, NULL, mBeaconExtHandleId_c, gBleExtAdvNoDuration_c, gBleExtAdvNoMaxEvents_c }; #endif /*gBeaconAE_c */   BleApp_AdvertisingCallback handles BLE Advertising callback from the host stack. Every time advertising state changes, we are going to update Advertising Data when the device is not advertising and BleApp has already started. Replace the existing content of gAdvertisingStateChanged_c event.  case gAdvertisingStateChanged_c: { /* update ADV data when is disabled */ if((!GetmAdvertisingOn()) && GetBleAppStarted()) { Gap_SetAdvertisingData(&gAppAdvertisingData, NULL); SetmAdvertisingOn(true); } if(GetmAdvertisingOn()) { Led1On(); } else { Led1Off(); #if defined(gBeaconAE_c) && (gBeaconAE_c) if(mAppTargetState == mAppState_ExtAdv_c) { if (gBleSuccess_c != BluetoothLEHost_StartExtAdvertising(&mAppExtAdvParams, BleApp_AdvertisingCallback, NULL)) { panic(0, 0, 0, 0); } } #endif } } break;   Testing the application: The IoT Toolbox is an all-in-one application that demonstrates NXP’s BLE functionalities, the implementation of BLE and custom profiles and the compatibility with different smartphones. This mobile application can be downloaded from the App Store and Google Play Store.  Please, refer to the IoT Toolbox Mobile Application User Manual for more information on features, requirements and how to install the application.  Select Beacons  Press scan Press the USERINTERFACE Button (carrier board) to start advertising  In the IoT Toolbox app, you should be able to see the counter increasing its value every 5 seconds in the field "A"
View full article
The customer wanted to update the FW of the PN7462 to an NFC cockpit. In general, we recommend that customers use MASS STORAGE MODE to update two files (including Flash and EEPROM) into memory. But there will always be customers who don’t know or how to successfully access MASS STORAGE MODE. They cannot succeed in doing so. Therefore, it is recommended to use the GUI FLASH tool to upgrade the FW to the NFC cabin. In order to clearly indicate the user how to use the GUI FLASH tool, this document describes this step by step.
View full article
The customer submitted a case through DFAE to seek support from NXP. They designed the product using PN5180, and according to feedback, about 10% of the boards could not read the card. The specific manifestation of the problem is: after the host issues the RF_ON command, RF field seems cannot be turned on and then fails to detect the card. Therefore, it can be seen that the problem should be on TX, not RX. The customer's device does not enable DPC and LPCD.
View full article
Matter support in Visual Studio Code (VS Code) is now open to all developers. MCUXpresso extension for VS Code v24.12.71 integrates the Matter toolchain for development on Windows, macOS and Linux.  It can be installed by visiting Microsoft’s Marketplace for VS Code. The following steps will set up your Windows system to develop Matter on NXP devices. This Getting Started process takes ~1 hour.  This is similar time it takes with flawless CLI setup. Import Matter repo takes ~30 minutes (Clone Matter repo; run bootstrap setup script)  Import first project for a board takes @~10 minutes (SDK repo download - 1st time every board) Additional projects can then be quickly imported/built. 1. Install Pigweed Project Automation Tool Pigweed is used for easier automation of building, testing, and linting GN and CMake projects.  Matter uses GN, so Pigweed is used by the maintainers of the project.  Complete the following to allow the Matter Bootstrap to properly modify/install the repository. Launch a Terminal in Administrator mode to allow operations to complete successfully. Ensure that Developer Mode is enabled. This can also be done by running the following command as an administrator: REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\AppModelUnlock /t REG_DWORD /v AllowDevelopmentWithoutDevLicense /d 1 /f\"" Enable long file paths. This can be done using  regedit  or by running the following command as an administrator: REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f  Enable Git symlinks: git config --global core.symlinks true For more information on these settings visit Get started with Pigweed - Pigweed  2. Install Visual Studio Code (VS Code) Microsoft allows users to quickly install VS Code from https://code.visualstudio.com/download. The link allows the user to select the appropriate download for their OS.  The following instructions are for a Windows installation.  However, most of the following steps also apply to Mac and Linux users. It can be helpful for new users to directly install VS Code and the NXP extension.  This can be done by sharing one of two links:  vscode:extension/NXPSemiconductors.mcuxpresso https://marketplace.visualstudio.com/items?itemName=NXPSemiconductors.mcuxpresso  If VS Code exists on the system, the user will be taken to the NXP MCUXpresso for VS Code extension in the Microsoft Marketplace.  If VS Code is NOT installed on the system the user will be guided through the install of VS Code.  At this point the VS Code application should be installed on the laptop. 3. Install MCUXpresso for VS Code Extension The user can install or update the MCUXpresso for VS Code extension from within VS Code.  The following steps outline how.  A short clip is included to show the steps. Open VS Code.  Launch program from desktop. Open the Extensions Marketplace.  Click on Icon of 4 blocks in left navigation  or use Ctrl-Shft-X. Search "NXP" or "Mcuxpresso" in the Extension search window at the top left. MCUXpresso for VS Code extension will be displayed.  Click on listing. Click on blue Install button in the Extension Overview that is opened in the editor. The Extension is properly installed when the following NXP icon is shown in left navigation.  At this point the VS Code application now includes the NXP MCUXpresso extension. 4. Run MCUXpresso Installer for Tool Dependencies It is now necessary to install other tool dependencies to properly use VS Code for MCUXpresso, Zephyr and/or Matter. NXP provides the MCUXpresso Installer utility to simplify properly meeting these tool dependencies.  The following steps list how to use the installer for a Matter system.  A short clip is included to show the steps. Click on "Open MCUXpresso Installer" found under Quickstart Panel in upper left. The MCUXpresso Installer will launch if already installed.  NOTE: If the Installer is not found, the user should select the blue "Download" button in the bottom right notification. Select the following from the MCUXpresso Installer list of available tools: Matter Developer Arm GNU Toolchain Standalone Toolchain Add-ons LinkServer Click the blue "Install" button and wait until installation progress shows complete Restart VS Code so that new settings are active At this point the VS Code application now includes the NXP MCUXpresso extension, and the laptop has any other tools required to begin Matter installation. 5. Import NXP Matter Repository The MCUXpresso for VS Code extension simplifies how the user can add Matter to their workspace.  The repository import wizard automates most of the steps required for a user to get started with Matter. The following steps show how to add Matter Repository.  2 short clips are included to show the steps. Click on "Import Repository" found under Quickstart Panel in upper left. Click Repository found in the wizard's Remote tab. Select "NXP Matter".  This automatically targets the NXP/Matter repo found on GitHub. Enter a desired location to clone/store the NXP Matter repository.  Closer to C:/ is better. Select "release/v1.4.0" listed as an available version under Revision: Click Import The import process can take ~30 minutes depending on network bandwidth and IT software. NOTE: This is similar amount of time when using CLI in a terminal.   After the repo is cloned, the Matter Bootstrap script is used to setup matter environment. At this point the user laptop has a valid Matter workspace.  The workspace is now capable of importing and building Matter projects. 6. Import First Matter Project The MCUXpresso for VS Code extension includes an Import Example wizard that simplifies adding Matter projects to a workspace.  The following instructions show how to import a project from the NXP Matter repository.   A short clip is included to show the steps. Click "Import Example from Repository" from the Quickstart Panel in the upper left. Select the Matter Repository from the drop-down options for Repository. Select the desired Toolchain from the drop-down options for Toolchain.  A GNU Toolchain should be available from previous MCUXpresso Installer steps. Select the target board from the drop-down options for Board.  The listed boards are supported in the NXP Matter repo. Select the desired project from the Template drop-down options.  Currently there are "contact-sensor-app" and "lighting-app". Click Create blue button. At this point there is a Matter project in the workspace.  The project can be explored with the provided project properties and file explorer views. 7. Build Matter Project Building the project is the final step for Getting Started with a Matter project in VS Code.  The extension has properly setup the project toolchain and will build successfully.  The NXP extension reduces the setup time by not importing the SDK for all supported boards.  The board SDK is automatically imported/cloned when it is not located on the 1st build for a board.  Successive projects for the same board will not require this additional step/delay. The following steps show how to build a matter project in the workspace.  A short clip is included to show the steps.  Select the Matter project listed under the Projects pane located in the primary left sidebar.  When selected, project control icons are revealed to the left of the project name. Click on the Build icon.   Verify the build was successful by viewing the binary files with File Explorer.  Click the File Explorer icon to the right of project name or in the upper left of the side bar navigation.  The binary is found under the project's \out\debug folder. This exercise on "Getting Started with Matter" is completed.  At this point the Matter project imported to the workspace was successfully built. 
View full article