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.   

Useful Links: Bluetooth Ranging Access Vehicle Enablement System - NXP Community

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.

See the necessary steps to enable additional SDK components for a project when using GitHub SDK and Kconfig/CMake.

NXP wireless solutions build upon decades of Wi-Fi, Bluetooth®, multiprotocol silicon, software and system design expertise, including 802.15.4 in the latest tri-radio architectures. NXP is committed to driving large-scale deployment across multiple markets by a broad array of power- and cost-optimized Wi-Fi, Bluetooth and 802.15.4 transceivers, enabling products with advanced Wi-Fi and multiradio capabilities including Wi-Fi 4, Wi-Fi 5 and Wi-Fi 6 chips.   Markets Product Wi-Fi Spec Wi-Fi Support IoT IW623 802.11ax (Wi-Fi 6E) 2x2 Tri-band (2.4G/5/76 GHz) + 1x1 Single Band (2.4 GHz) IoT IW693 802.11ax (Wi-Fi 6/6E) CDW 2x2 Dual Band (5-7 GHz) + 1x1 Single Band (2.4 GHz) IoT IW610 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) IoT IW612 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) IoT IW611 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) IoT IW620 802.11ax (Wi-Fi 6) 2x2 DB (2.4/5 GHz) IoT IW416 802.11n (Wi-Fi 4) 1x1 DB (2.4/5 GHz) Wireless MCU Hostless RW612 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) Wireless MCU Hostless RW610 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) Automotive AW692 802.11ax (Wi-Fi 6) 2x2 + 1x1 CDW DB (2.4/5GHz + 2.4Ghz) Automotive AW693 802.11ax (Wi-Fi 6E) 2x2 + 1x1 CDW TB (2.4/5/6Ghz + 2.4Ghz) Automotive AW611 802.11ax (Wi-Fi 6) 1x1 DB (2.4/5 GHz) Automotive AW690 802.11ax (Wi-Fi 6) 1x1 CDW DB (2.4/5 GHz)   Wireless Module Partners Leading wireless connectivity solution providers offer NXP wireless modules in their wireless connectivity solutions. Module manufacturers develop Wi-Fi modules using NXP’s broad portfolio of Wi-Fi chips (system-on-chip (SoC)), including Wi-Fi 6 chips, Wi-Fi and Bluetooth® combo integrated circuits (ICs) and tri-radio SoCs with 802.15.4. NXP enables a broad range of wireless applications with an ecosystem of wireless module partners.   Why Use a Module Vendor? Accelerate time-to-market Avoid the complexity of RF design and testing Ensure regulatory compliance more easily (e.g. FCC, CE, ISED) Focus on the host product’s functionality while relying on the vendor for wireless performance   Useful Links Wi-Fi Basic concepts: This post provides information about the different terms used in Wi-Fi, 802.11 standards and the three types of 802.11 MAC frames. Wi-Fi Security Concepts: This post covers the security and authentication processes  Wi-Fi Connection/Disconnection process: In 802.11 standards, the connection procedure includes three major steps that shall be performed to make the device part of the Wi-Fi network and communicate in the network. Wi-Fi Software Drivers Locations: NXP Recommends using Wi-Fi source code drivers WiFi_BT_Integretation-(Linux_BSP_compilation_for_iMX_platform): This article describes how to compile the Linux BSP of the i.MX platform under ubuntu 18.04, 20.04 LTS and debian-10. This is a necessary step to integrate WIFI/BT to the I.MX platform. See the attachment for detailed steps. Enabling i.MX8MP-EVK uSDHC1 M.2 for Wi-Fi on Android-11.0.0_2.6.0: Detailed steps on enabling usdhc1 NXP Wi-Fi and Bluetooth Product:  The article will introduce how to build Wi-Fi Mass Market Driver Wi-Fi Firmware Automatic Recovery on RW61x: This article introduces the Wi-Fi automatic recovery feature as well as how to enable and verify it on RW61x SDK. Access Point Wi-Fi configuration on i.MX8 Family: This guide explains how to achieve that, using the i.MX8M Plus EVK (8MP) as the AP device and the i.MX8M Mini EVK (8MM) as the connected device. How to connect to a Wi-Fi network on i.MX8MP: this article guides you step by step how to connect to a Wi-Fi network NXP Wi-Fi/Bluetooth firmware on the i.MX8M series: steps to replace Wi-Fi/Bluetooth firmware on the i.MX8M series on Linux Training FRDM-iMX91 connectivity Wi-Fi Basic Hands-on FRDM-iMX91 connectivity Wi-Fi Bluetooth LE and OT COEX RW612/MCXW71 - Wi-Fi and thread border router Training FRDM-RW612 Getting Started, Wi-Fi CLI on VScode Community Support If you have questions regarding this training, please leave your comments in our Wireless MCU Community! here 

KW43 uses dual Arm Core ‘CM33’ and supports multiple interfaces and security features. One instance of the Arm core is used for System use and other one is for Radio/Wireless applications and shared single 1.5MB FLASH for program execution. Pin-to-pin compatibility with KW47/KW45: Please refer to the sildes attached below for the pin-to-pin compatibility, thanks.