The MCX W23 is a family of devices. All devices are Arm Cortex®-M33 based wireless microcontrollers for embedded applications supporting Bluetooth Low Energy 5.3. It can be used to develop IoT solutions. MCX W23xA supports LV_SM mode. MCX W23xB supports HV_SM and XR_SM mode. Building on NXP's strong history of providing industrial edge solutions, the MCX W series offers a wide operating temperature range from -40 °C to 125 °C. The Arm Cortex-M33 provides a security foundation, offering isolation to protect valuable IP and data with Trust Zone technology. It simplifies the design and software development of digital signal control systems with the integrated digital signal processing (DSP) instructions. To support security requirements, the MCX W23 also offers support for SHA-1, SHA2-256, AES, RSA, ECC, UUID, dynamic encryption, and decryption of the flash data using a PRINCE engine, debug authentication, and TBSA-M compliance.   Documents Reference Manual Fact sheet Data Sheet Errata for MCX W23xUIK MCX W23 Hardware Design Guide Secure Reference manual** European Union Declaration of Conformity for FRDM-MCXW23 FRDM-MCXW23 Board User Manual Bluetooth Specifications The MCX W23 is compatible with the Bluetooth Low Energy 5.3 specification: – Bluetooth Low Energy 5.3 controller subsystem (QDID 200592) – Bluetooth Low Energy 5.3 host subsystem (QDID 226395) – Includes a 48-bit unique Bluetooth device address – Up to 4 simultaneous connections supported The MCX W23 supports the following Bluetooth Low Energy features: – Device privacy and network privacy modes (version 5.0) – Advertising extension PDUs (version 5.0) – Anonymous device address type (version 5.0) – Up to 2 Mbps data rate (version 5.0) – Long range (version 5.0) – High-duty cycle, Non connectable advertising (version 5.0) – Channel selection algorithm #2 (version 5.0) – High output power (version 5.0) – Advertising channel index (version 5.1) – Periodic advertising sync transfer (PAST) (version 5.1) – Supports LE power control feature (version 5.2) RF antenna: 50 Ω single-ended RF receiver characteristics: – Sensitivity −94 dBm in Bluetooth Low Energy 2 Mbps – Sensitivity −97 dBm in Bluetooth Low Energy 1 Mbps – Sensitivity −100 dBm in Bluetooth Low Energy 500 kbps – Sensitivity −102 dBm in Bluetooth Low Energy 125 kbps – Accurate RSSI measurement with ±3 dB accuracy Flexible RF transmitter level configurability: – TX mode 1 (TXM1): Range from −31 dBm to +2 dBm when VDD_RF exceeds 1.1 V – TX mode 2 (TXM2): Range from −28 dBm to +6 dBm when VDD_RF exceeds 1.7   Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview   Training MCX W Series Training - NXP Community   Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development    Application Notes Power Management: AN14660: Power Management for MCX W23: This App Note provides information about the power manager software component. The application uses this component and the operating system to achieve optimal low-power states, based on the requirements of the application. RF: AN14575: MCX W23 Health Care IoT Peripheral Software Architecture: This App Note provides an overview of the software architecture for the MCX W23 Health care IoT Peripheral application. Designed as a model implementation, this application showcases the key features of the MCX W23 platform and serves as a foundation for developing product-quality applications. AN14659: MCX W23 Bluetooth Low Energy Power Consumption Analysis: This App Note describes the power consumption of the MCX W23 Bluetooth Low Energy (LE) device and the procedure to measure the current consumption using the MCXW23_EVK_BB and MCXW236B_RDM boards. AN2731: Compact Planar Antennas for 2.4 GHz Communication: This App Note is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays Security: AN14657: Getting Started with Secure Boot on MCX W23: This application note covers the design of the bootloader ROM code that NXP has developed on the MCX W23, and how to use all its features. Useful Links Bluetooth LE FSCI Host Application running on FRDM-MCXN947 and MCXW23B-Click Board: The Bluetooth LE FSCI Host application demonstrates a host-side implementation for the Health Thermometer use case. It is designed to work alongside the FSCI Blackbox application, which runs on platforms such as the MCXW236 Click Board, FRDM-MCXW236, or other compatible Bluetooth LE wireless MCUs. Transmitter Maximum Output Power Override Application Note   Development Tools    VSCode: MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. Zephyr RTOs  NXP Application Code Hub: Application Code Hub (ACH) repository enables engineers to easily find microcontroller software examples, code snippets, application software packs and demos developed by our in-house experts. This space provides a quick, easy and consistent way to find microcontroller applications. NXP SPSDK: Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool: The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool: Is an application that helps the user to perform an over the air firmware update of an NXP development board. Support If you have questions regarding MCX W23, please leave your question in our Wireless MCU Community! here

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

By default, FRDM-KW36 board includes a 32MHz XTAL (YI) as shown in Figure 1 but there are cases where a 26MHz XTAL is needed instead of 32MHz XTAL for FRDM-KW36 or a custom KW36 board.   Figure 1. 32MHz XTAL from FRDM-KW36 schematics Wireless connectivity demos from FRDM-KW36 Sofware Development Kit are configured to run with a 32MHz XTAL by default, but it's very easy to modify the software to operate with a 26MHz XTAL. Follow next steps to configure a FRDM-KW36 wireless connectivity demo to operate with a 26MHz XTAL: 1. In clock_config.h file, change BOARD_XTAL0_CLK_HZ define from 32000000U to 26000000U as shown in Figure 2.   Figure 2. BOARD_XTAL0_CLK_HZ define in clock_config.h 2. Add RF_OSC_26MHZ=1 line in preprocessor: If using IAR IDE: Right click on your project, then click options (Figure 3). Figure 3. IAR project options Go to C/C++ Compiler tab, then Preprocessor, and add RF_OSC_26MHZ=1 line in defined symbols window (Figure 4). Figure 4. IAR Preprocessor If using MCUXpresso IDE: Right click on your project, select Properties, go to Settings under C/C++ Build, then Preprocessor under MCU C Compiler (Figure 5). Figure 5. MCUXpresso Preprocessor Click on add button from Defined symbols, write RF_OSC_26MHZ=1 and click OK to finish (Figure 6). Figure 6. MCUXpresso Defined symbols To finish, re-compile your project and it will be ready to operate with a 26MHz XTAL. FRDM-KW36 SDK can be downloaded from the MCUXpresso webpage.

View the Webinar Recording

This video shows how to load the Open SDA software from PE micro to the TWR-KW2x in order to debug applications using USB port and without needing external JTAG debuggers. Required downloads: TWR-KW2x Board Support Package:Kinetis KW2x Tower System Modules|Freescale PE Micro - Open SDA: P&E Microcomputer Systems

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    

All FSCI packets contain a checksum field to verify data integrity. Every time a FSCI packet is created (by the Host or a Kinetis device) a new CRC is calculated based on every data byte in the FSCI frame. Compute CRC for TX packet The CRC field is calculated by XORing each byte contained in the FSCI command (opcode group, opcode, payload length and payload data). Checksum field then, accumulates the result of every XOR instruction.    In the firmware, the CRC is calculated in the 'FSCI_transmitPayload()' function wich is located in '<HSDK project>/framework/FSCI/Source/FsciCommunication.c' file. See FSCI_computeChecksum(). Example: TX: AspSetXtalTrim.Request 02 95 0A 01 30 AE    Sync            [1 byte] = 02    OpGroup     [1 byte] = 95    OpCode      [1 byte] = 0A    Length         [1 byte] = 01    trimValue     [1 byte] = 30    CRC            [1 byte] = AE     <------- (0x95) XOR (0A) XOR (0x01) XOR (0x30) = 0xAE Disable CRC field validation Every time a FSCI packet is received, the device verifies the checksum value.  The next changes will allow the board to receive FSCI packets without verifying the CRC field. However, the board will send the FSCI responses to the Host with this CRC field. Go to 'FsciCommunication.c' file. Search for 'fsci_packetStatus_t FSCI_checkPacket( clientPacket_t *pData, uint16_t bytes, uint8_t* pVIntf )' function. Comment all line codes related to checksum verifying. The image below shows what has to be commented. Compile project and load it to the board. Verify functionality with Test Tool. Select any command and check Raw Data checkbox. Delete the CRC data field and send the FSCI message pressing Send Raw. The loaded command set will vary depending on the demo you are using (Thread, ZigBee, BLE, etc.). The FSCI message is sent without a CRC field and the board responses to the command successfully.

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.  

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

MyWirelessAPP Demo Beacon(End device) code for RTS development

The RF parameters for KW01 can be changed by firmware using the KW01 connectivity software. Frequency band: The operational frequency band can be changed in app_preinclude.h file stored in Source folder. You can select the operational frequency band for your application only setting "1" to the desired band and "0" for the unused bands. In the same file also the default phy mode can be selected: Center frequency, channel spacing, number of channels, bit rate, frequency deviation, filter bandwidth, and other RF parameters: Most common RF parameters can be changed in declaration of "phyPibRFConstants" on PhyPib.c file. Search for your operational band and phy mode. For example for US ISM band in phy mode 1: Then change the desired parameters. If you want to change, for example, FDev: select "Fdev_25000", then go to declaration and change it from one of the predefined list of values: Regards, Luis Burgos.

Wireless Equipment: Ellisys:  Ellisys is a leading worldwide supplier of advanced protocol test solutions for Bluetooth®, Wi-Fi, WPAN, USB 2.0, SuperSpeed USB 3.1, USB Power Delivery, USB Type-C, DisplayPort and Thunderbolt technologies.  USB, Bluetooth and WiFi Protocol Test Solutions  Bluetooth Vanguard - Advanced Bluetooth Analysis System Bluetooth Qualifier - Bluetooth Qualification System   RFcreations:     RFcreations is a core team of highly skilled and knowledgeable, professional engineers with decades of experience across the design and development of both RF and digital hardware, embedded, protocol stacks and UI software mini-moreph morephCS   Teledyne Lecroy:    offers an extensive range of test solutions to help with design, development, and deployment of devices and systems frontline-x240 Wireless Protocol Analyzer  frontline-x500e Wireless Protocol Analyzer  Rohde&Schwarz:        is a global technology group striving for a safer and connected world. Offers Test & Measurement, Technology Systems and Networks & Cybersecurity Divisions R&S CMW270 wireless connectivity tester Useful links:  Top Online Bluetooth LE learning Resource Ellisys Bluetooth Video Series RFcreations Bluetooth Sniffers and Test Tools Learn Bluetooth Low Energy in a single weekend

In this document we will be seeing how to create a BLE demo application for an adopted BLE profile based on another demo application with a different profile. In this demo, the Pulse Oximeter Profile will be implemented.  The PLX (Pulse Oximeter) Profile was adopted by the Bluetooth SIG on 14th of July 2015. You can download the adopted profile and services specifications on https://www.bluetooth.org/en-us/specification/adopted-specifications. The files that will be modified in this post are, app.c,  app_config.c, app_preinclude.h, gatt_db.h, pulse_oximeter_service.c and pulse_oximeter_interface.h. A profile can have many services, the specification for the PLX profile defines which services need to be instantiated. The following table shows the Sensor Service Requirements. Service Sensor Pulse Oximeter Service Mandatory Device Information Service Mandatory Current Time Service Optional Bond Management Service Optional Battery Service Optional Table 1. Sensor Service Requirements For this demo we will instantiate the PLX service, the Device Information Service and the Battery Service. Each service has a source file and an interface file, the device information and battery services are already implemented, so we will only need to create the pulse_oximeter_interface.h file and the pulse_oximeter_service.c file. The PLX Service also has some requirements, these can be seen in the PLX service specification. The characteristic requirements for this service are shown in the table below. Characteristic Name Requirement Mandatory Properties Security Permissions PLX Spot-check Measurement C1 Indicate None PLX Continuous Measurement C1 Notify None PLX Features Mandatory Read None Record Access Control Point C2 Indicate, Write None Table 2. Pulse Oximeter Service Characteristics C1: Mandatory to support at least one of these characteristics. C2: Mandatory if measurement storage is supported for Spot-check measurements. For this demo, all the characteristics will be supported. Create a folder for the pulse oximeter service in  \ConnSw\bluetooth\profiles named pulse_oximeter and create the pulse_oximeter_service.c file. Next, go to the interface folder in \ConnSw\bluetooth\profiles and create the pulse_oximeter_interface.h file. At this point these files will be blank, but as we advance in the document we will be adding the service implementation and the interface macros and declarations. Clonate a BLE project with the cloner tool. For this demo the heart rate sensor project was clonated. You can choose an RTOS between bare metal or FreeRTOS. You will need to change some workspace configuration.  In the bluetooth->profiles->interface group, remove the interface file for the heart rate service and add the interface file that we just created. Rename the group named heart_rate in the bluetooth->profiles group to pulse_oximeter and remove the heart rate service source file and add the pulse_oximeter_service.c source file. These changes will be saved on the actual workspace, so if you change your RTOS you need to reconfigure your workspace. To change the device name that will be advertised you have to change the advertising structure located in app_config.h. /* Scanning and Advertising Data */ static const uint8_t adData0[1] =  { (gapAdTypeFlags_t)(gLeGeneralDiscoverableMode_c | gBrEdrNotSupported_c) }; static const uint8_t adData1[2] = { UuidArray(gBleSig_PulseOximeterService_d)}; static const gapAdStructure_t advScanStruct[] = { { .length = NumberOfElements(adData0) + 1, .adType = gAdFlags_c, .aData = (void *)adData0 }, { .length = NumberOfElements(adData1) + 1, .adType = gAdIncomplete16bitServiceList_c, .aData = (void *)adData1 }, { .adType = gAdShortenedLocalName_c, .length = 8, .aData = "FSL_PLX" } }; We also need to change the address of the device so we do not have conflicts with another device with the same address. The definition for the address is located in app_preinclude.h and is called BD_ADDR. In the demo it was changed to: #define BD_ADDR 0xBE,0x00,0x00,0x9F,0x04,0x00 Add the definitions in ble_sig_defines.h located in Bluetooth->host->interface for the UUID’s of the PLX service and its characteristics. /*! Pulse Oximeter Service UUID */ #define gBleSig_PulseOximeterService_d         0x1822 /*! PLX Spot-Check Measurement Characteristic UUID */ #define gBleSig_PLXSpotCheckMeasurement_d      0x2A5E /*! PLX Continuous Measurement Characteristic UUID */ #define gBleSig_PLXContinuousMeasurement_d     0x2A5F /*! PLX Features Characteristic UUID */ #define gBleSig_PLXFeatures_d                  0x2A60 /*! Record Access Control Point Characteristic UUID */ #define gBleSig_RecordAccessControlPoint_d     0x2A52 We need to create the GATT database for the pulse oximeter service. The requirements for the service can be found in the PLX Service specification. The database is created at compile time and is defined in the gatt_db.h.  Each characteristic can have certain properties such as read, write, notify, indicate, etc. We will modify the existing database according to our needs. The database for the pulse oximeter service should look something like this. PRIMARY_SERVICE(service_pulse_oximeter, gBleSig_PulseOximeterService_d)     CHARACTERISTIC(char_plx_spotcheck_measurement, gBleSig_PLXSpotCheckMeasurement_d, (gGattCharPropIndicate_c))         VALUE_VARLEN(value_PLX_spotcheck_measurement, gBleSig_PLXSpotCheckMeasurement_d, (gPermissionNone_c), 19, 3, 0x00, 0x00, 0x00)         CCCD(cccd_PLX_spotcheck_measurement)     CHARACTERISTIC(char_plx_continuous_measurement, gBleSig_PLXContinuousMeasurement_d, (gGattCharPropNotify_c))         VALUE_VARLEN(value_PLX_continuous_measurement, gBleSig_PLXContinuousMeasurement_d, (gPermissionNone_c), 20, 3, 0x00, 0x00, 0x00)         CCCD(cccd_PLX_continuous_measurement)     CHARACTERISTIC(char_plx_features, gBleSig_PLXFeatures_d, (gGattCharPropRead_c))         VALUE_VARLEN(value_plx_features, gBleSig_PLXFeatures_d, (gPermissionFlagReadable_c), 7, 2, 0x00, 0x00)     CHARACTERISTIC(char_RACP, gBleSig_RecordAccessControlPoint_d, (gGattCharPropIndicate_c | gGattCharPropWrite_c))         VALUE_VARLEN(value_RACP, gBleSig_RecordAccessControlPoint_d, (gPermissionNone_c), 4, 3, 0x00, 0x00, 0x00)         CCCD(cccd_RACP) For more information on how to create a GATT database you can check the BLE Application Developer’s Guide chapter 7. Now we need to make the interface file that contains all the macros and declarations of the structures needed by the PLX service. Enumerated types need to be created for each of the flags field or status field of every characteristic of the service. For example, the PLX Spot-check measurement field has a flags field, so we declare an enumerated type that will help us keep the program organized and well structured. The enum should look something like this: /*! Pulse Oximeter Service - PLX Spotcheck Measurement Flags */ typedef enum {     gPlx_TimestampPresent_c                      = BIT0,     /* C1 */     gPlx_SpotcheckMeasurementStatusPresent_c     = BIT1,     /* C2 */     gPlx_SpotcheckDeviceAndSensorStatusPresent_c = BIT2,     /* C3 */     gPlx_SpotcheckPulseAmplitudeIndexPresent_c   = BIT3,     /* C4 */     gPlx_DeviceClockNotSet_c                     = BIT4 } plxSpotcheckMeasurementFlags_tag; The characteristics that will be indicated or notified need to have a structure type that contains all the fields that need to be transmitted to the client. Some characteristics will not always notify or indicate the same fields, this varies depending on the flags field and the requirements for each field. In order to notify a characteristic we need to check the flags in the measurement structure to know which fields need to be transmitted. The structure for the PLX Spot-check measurement should look something like this: /*! Pulse Oximeter Service - Spotcheck Measurement */ typedef struct plxSpotcheckMeasurement_tag {     ctsDateTime_t              timestamp;             /* C1 */     plxSpO2PR_t                SpO2PRSpotcheck;       /* M */     uint32_t                   deviceAndSensorStatus; /* C3 */     uint16_t                   measurementStatus;     /* C2 */     ieee11073_16BitFloat_t     pulseAmplitudeIndex;   /* C4 */     uint8_t                    flags;                 /* M */ }plxSpotcheckMeasurement_t; The service has a configuration structure that contains the service handle, the initial features of the PLX Features characteristic and a pointer to an allocated space in memory to store spot-check measurements. The interface will also declare some functions such as Start, Stop, Subscribe, Unsubscribe, Record Measurements and the control point handler. /*! Pulse Oximeter Service - Configuration */ typedef struct plxConfig_tag {     uint16_t      serviceHandle;     plxFeatures_t plxFeatureFlags;     plxUserData_t *pUserData;     bool_t        procInProgress; } plxConfig_t; The service source file implements the service specific functionality. For example, in the PLX service, there are functions to record the different types of measurements, store a spot-check measurement in the database, execute a procedure for the RACP characteristic, validate a RACP procedure, etc. It implements the functions declared in the interface and some static functions that are needed to perform service specific tasks. To initialize the service you use the start function. This function initializes some characteristic values. In the PLX profile, the Features characteristic is initialized and a timer is allocated to indicate the spot-check measurements periodically when the Report Stored Records procedure is written to the RACP characteristic. The subscribe and unsubscribe functions are used to update the device identification when a device is connected to the server or disconnected. bleResult_t Plx_Start (plxConfig_t *pServiceConfig) {         mReportTimerId = TMR_AllocateTimer();         return Plx_SetPLXFeatures(pServiceConfig->serviceHandle, pServiceConfig->plxFeatureFlags); } All of the services implementations follow a similar template, each service can have certain characteristics that need to implement its own custom functions. In the case of the PLX service, the Record Access Control Point characteristic will need many functions to provide the full functionality of this characteristic. It needs a control point handler, a function for each of the possible procedures, a function to validate the procedures, etc. When the application makes a measurement it must fill the corresponding structure and call a function that will write the attribute in the database with the correct fields and then send an indication or notification. This function is called RecordMeasurement and is similar between the majority of the services. It receives the measurement structure and depending on the flags of the measurement, it writes the attribute in the GATT database in the correct format. One way to update a characteristic is to create an array of the maximum length of the characteristic and check which fields need to be added and keep an index to know how many bytes will be written to the characteristic by using the function GattDb_WriteAttribute(handle, index, &charValue[0]). The following function shows an example of how a characteristic can be updated. In the demo the function contains more fields, but the logic is the same. static bleResult_t Plx_UpdatePLXContinuousMeasurementCharacteristic ( uint16_t handle, plxContinuousMeasurement_t *pMeasurement ) {     uint8_t charValue[20];     uint8_t index = 0;     /* Add flags */     charValue[0] = pMeasurement->flags;     index++;     /* Add SpO2PR-Normal */     FLib_MemCpy(&charValue[index], &pMeasurement->SpO2PRNormal, sizeof(plxSpO2PR_t));     index += sizeof(plxSpO2PR_t);         /* Add SpO2PR-Fast */     if (pMeasurement->flags & gPlx_SpO2PRFastPresent_c)     {       FLib_MemCpy(&charValue[index], &pMeasurement->SpO2PRFast, sizeof(plxSpO2PR_t));       index += sizeof(plxSpO2PR_t);     }        return GattDb_WriteAttribute(handle, index, &charValue[0]); } The app.c handles the application specific functionality. In the PLX demo it handles the timer callback to make a PLX continuous measurement every second. It handles the key presses and makes a spot-check measurement each time the SW3 pushbutton is pressed. The GATT server callback receives an event when an attribute is written, and in our application the RACP characteristic is the only one that can be written by the client. When this event occurs, we call the Control Point Handler function. This function makes sure the indications are properly configured and check if another procedure is in progress. Then it calls the Send Procedure Response function, this function validates the procedure and calls the Execute Procedure function. This function will call one of the 4 possible procedures. It can call Report Stored Records, Report Number of Stored Records, Abort Operation or Delete Stored Records. When the project is running, the 4 LEDs will blink indicating an idle state. To start advertising, press the SW4 button and the LED1 will start flashing. When the device has connected to a client the LED1 will stop flashing and turn on. To disconnect the device, hold the SW4 button for some seconds. The device will return to an advertising state. In this demo, the spot-check measurement is made when the SW3 is pressed, and the continuous measurement is made every second. The spot-check measurement can be stored by the application if the Measurement Storage for spot-check measurements is supported (bit 2 of Supported Features Field in the PLX Features characteristic). The RACP characteristic lets the client control the database of the spot-check measurements, you can request the existing records, delete them, request the number of stored records or abort a procedure. To test the demo you can download and install the nRF Master Control application by Nordic Semiconductor on an Android Smartphone that supports BLE. This app lets you discover the services in the sensor and interact with each characteristic. The application will parse known characteristics, but because the PLX profile is relatively new, these characteristics will not be parsed and the values will be displayed in a raw format. Figure 1. nRF Master Control app

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.

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"  

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.   

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  

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"

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.