The homologation requirements in China (MIIT [2002]353) obviously are planned (end of December 2022) to be sharpened (MIIT publication from 2021-01-27: “Notice on Matters Related to Radio Management in the 2400MHz, 5100MHz and 5800MHz Bands”).   A modification register is need on the KW38 and KW36 to pass the new Chinese  requirement with acceptable margin: PA_RAMP_SEL value must be set to 0x02h (2us) instead of 0x01h (1us default value) Modification SW: XCVR_TX_DIG_PA_CTRL_PA_RAMP_SEL(2) in the nxp_xcvr_common_config.c All the details are in the attached file.   Note: This SW modification is for China country only.

If the application running in the KW41Z does not operate in low power mode, the device could work without the 32 kHz oscillator. However, for it to work correctly, the clock configuration must be changed. Figure 1.  KW41Z clock distribution By default, the software stack running on the KW41Z selects a clock source that requires the 32 kHz oscillator. However, if the 32 kHz oscillator is not available, the clock configuration must be changed. Fortunately, the option to change it is already implemented, it is only required to change the clock configuration to the desired one. To do this, change the value for the CLOCK_INIT_CONFIG macro located in the app_preinclude.h file. /* Define Clock Configuration */ #define CLOCK_INIT_CONFIG           CLOCK_RUN_32‍‍‍‍‍‍‍‍‍‍ In the selected mode in this example, CLOCK_RUN_32, the selected clock mode is BLPE (Bypassed Low Power External). In this mode, the FLL is bypassed entirely, and clock is derived from the external RF oscillator, in this case, the 32 MHz external clock. These macros are the default available options to change the clock configuration, they are located in the board.h file. It is up to the application and the developer to chose the most appropriate configuration. #define CLOCK_VLPR       1U #define CLOCK_RUN_16     2U #define CLOCK_RUN_32     3U #define CLOCK_RUN_13     4U #define CLOCK_RUN_26     5U #define CLOCK_RUN_48_24  6U #define CLOCK_RUN_48_16  7U #define CLOCK_RUN_20_FLL 8U‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ More information regarding the different clock modes and their clock sources are available in the KW41Z reference manual, Chapter 5: Clock Distribution, section 5.4 Clock definitions, and Chapter 24: Multipurpose Clock Generator.

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....

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.

This patch fixes some minor issues with the Connectivity Software v1.0.2 when working with the Kinetis BLE Toolbox application for smartphones. Following issues are fixed. BLE OTAP Application: Fixes application failing to download the new image when the previous image upload has been interrupted due a disconnection. BLE Wireless UART: Fixes MTU exchange issue causing some characters not bein shown in the smartphone application in iOS and Android. Hybrid BLE + Thread console: Fixes MTU exchange issue causing some characters not bein shown in the smartphone application console in iOS and Android. Make sure the Connectivity Software version 1.0.2 is installed in your computer before proceeding to install this application.

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

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.

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.  

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  ovidiu_usturoi_0-1752503129993.png   Connectivity Framework Documentation(change log and guides):  https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/wireless/framework/index.html ovidiu_usturoi_1-1752503167217.png   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    

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

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.   

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

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

The KW43 product family is a low-power, secure, single-chip wireless MCU that integrates a high performance, Bluetooth Low Energy, Bluetooth Channel Sounding, EdgeLock Secure Accelerators, and various MCU peripherals targeted for Automotive applications. The KW43 family utilizes an Arm® Cortex®-M33 core (Armv8-M architecture) running up to 96 MHz for customer applications. The family includes memory configurations of up to 1.5MB flash and 256 KB SRAM across all listed part numbers. All devices in the family integrate a state-of-the-art, scalable security architecture including Arm’s TrustZone®-M, a resource domain controller and an isolated EdgeLock Secure Accelerators supporting hardware cryptographic accelerators, random number generators and key generation, storage, and management along with secure debug. All members of the KW43 family are designed to be compliant to a SESIP Level 3 certification following the Arm PSA Level 3 profile. KW43 uses dual Arm Core Cortex-M33 (‘CM33’) and supports multiple interfaces and security features. One is for application and system use and other is for radio link layer and both cores share a common flash of 1.5 MB. The devices include a full certified Bluetooth LE 6.x controller stack with support for up to 10 simultaneous connections in any controller/peripheral combination. The multiprotocol radio subsystem integrated in the KW43 Family is energy efficient and is designed for Wi-Fi coexistence. The radio is supported with tested software stacks for Bluetooth Low Energy for standalone and hosted applications to enable a range of Automotive, IoT and industrial applications. There is also software and hardware support for 2.4 GHz proprietary protocols. To address ranging requirements, the Localization Engine (LCE) is integrated into the system for enhanced localization performance. The KW43 series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development. Early access program The KW43 is in pre-production, developers can get started today with the KW45/KW47, which is pin and software compatible.   you can request access contacting NXP sales team - Pascal Bernard ([email protected]) Join KW47 early access program here: KW43 Early Access Training Bluetooth Low energy 6.0 NXP Introduction Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology.  2024: Channel Sounding 2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Useful Links How to import and run demo examples with MCUXpresso for Visual Studio Code: This article gives information on how to import and run demo examples from the new SDK with ARM GCC toolchain, in MCUXpresso for Visual Studio Code. [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide: This article describes a simple process for enabling the user controls the radio through serial commands.

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);  

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

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.

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.

Board pictures (KW47-M2) neidys_vargas_0-1753807293929.png 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 neidys_vargas_1-1753714061544.png 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.   neidys_vargas_2-1753714061554.png   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. neidys_vargas_6-1753714061702.png   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” neidys_vargas_7-1753714061704.png   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. neidys_vargas_8-1753714061713.png   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" neidys_vargas_9-1753714061729.png  

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