The purpose of this guide is to demonstrate the capability of the RW61x MCU generating an example application using Wi-Fi and Bluetooth features by combining the functionalities of the Wi-Fi shell and Bluetooth peripheral examples from the Zephyr repository using the FRDM-RW612.  The demo provides access to several Wi-Fi features controllable through a serial terminal while being able to test several GATT services from the Bluetooth Peripheral along the NXP's IoT Toolbox App.  Environment: MCUXpresso for Visual Studio Code. Zephyr v4.3.0. Zephyr SDK v0.17.4. FRDM-RW612. First, it is required to import both the Wi-Fi Shell and Bluetooth Peripheral examples to the workspace: Select "Import Example from Repository" in the Quickstart Panel. Select the Wi-Fi shell example and click on the "Import" button: Select Bluetooth Peripheral example and click on the "Import" button: Once the examples have been imported to your workspace, copy the content from the main file of the peripheral example to the main file of the Wi-Fi shell example in order to add the Bluetooth functionality and required initialization to the Wi-Fi example.  In this step you may overwrite the contents from the main file of the integration project, as it only contains an empty main structure. Then copy the configurations from the "prj.conf" file of the peripheral example to the "prj.conf" file of the modified Wi-Fi Shell example to enable Bluetooth functionality and services. IMPORTANT: Be careful of not erasing the settings in the prj.conf file of the modified example, just add the new ones below. Build the example by pressing the build button or by doing right click and then "Build Project" as shown: Flash or debug the example. To flash it, right click over the project's name and select "Flash the Selected Target" and select the "zephyr.elf" file. If you wish to debug the project, click on the green arrow beside the build button used earlier. Once flashed the project, open a serial terminal with the following configuration: Baudrate: 115200 Stopbits: 1 Data: 8 bits Parity: none In the terminal you should get the following output after a reset, in which initialization logs of both Bluetooth and Wi-Fi are printed: As printed on the Bluetooth logs, the integrated peripheral example starts advertising, to test this feature, you may use the NXP IoT Toolbox "Heart Rate" tool, which will allow to pair with the board as shown in the image below: To start the pairing, tap on the "Set PHY" box and select the preferred PHY. Once paired, you should be able to see the heart rate indication increasing and decreasing as shown: On the serial terminal you will be able to see the following logs once paired with your phone: To test the Wi-Fi shell features, you may display all of the NXP-Wi-Fi features by writing in the terminal "nxp_wifi help", as well as "wifi help" to see the commands to use the default Wi-Fi features to scan/connect to a network. To test the connection to an access point, do a "wifi scan" to display the available networks, once identified the network to join, write "wifi connect …" with the rest of the required attributes to join the network, then you should get an output similar to the following: Notice that you are able to do this while connected to the heart rate tool in the mobile application via Bluetooth, demonstrating the capability of having both a Wi-Fi and Bluetooth connections working concurrently.

This document describes how to use the RW61x DevHSM Loader Application in combination with an OEM Manufacturing Firmware (OEM MFW) to perform secure device provisioning. Two DevHSM loader images are available depending on the boot flow: RW61x_DevHSM_Loader_ISP_Boot_FW.sb3 → Used when loading via ISP boot mode. This method communicates via UART, USB, I2C or SPI RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 → Used for zero‑touch provisioning from external flash. This method communicates via SWD or JTAG. Both flows ultimately load and execute an OEM Manufacturing Firmware (OEM_MFW.sb3) that provisions the device (e.g., secure keys, identities, certificates, etc.). You may generate this firmware using the SEC tool.  The DevHSM Loader firmwares are provided in the SEC tool package once downloaded. The SEC tool by default will use the ISP loader application.   1. DevHSM Loader Using ISP Boot Mode Firmware Image RW61x_DevHSM_Loader_ISP_Boot_FW.sb3 This method uses the boot ROM ISP protocol. It’s commonly used during development, factory bring‑up, or initial programming before flash is configured. Procedure Step‑by‑step Boot the device in ISP boot mode Ensure the correct boot pins are set so the device enters ISP mode and communicates with blhost. Download the DevHSM Loader Firmware Use the receive-sb-file command to send RW61x_DevHSM_Loader_FW.sb3 over the serial interface. Verify updated device state Use get-property 0x1 to confirm the firmware was accepted and the boot state changed accordingly. Download and execute OEM MFW (OEM_MFW.sb3) Once the DevHSM Loader is active, send the provisioning firmware SB3 file. The OEM MFW will load, execute, and begin provisioning operations. Example Script: set blhost=blhost.exe set comport=COMxx,115200 set timeout=-t 100000 %blhost% -p %comport% -- get-property 0x1 pause blhost.exe -p %comport% %timeout% -- receive-sb-file RW61x_DevHSM_Loader_ISP_Boot_FW.sb3 pause %blhost% -p %comport% -- get-property 0x1 pause blhost.exe -p %comport% %timeout% -- receive-sb-file OEM_MFW.sb3   2. DevHSM Loader Using FlexSPI Boot Mode (Zero‑Touch Provisioning) Firmware Image RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 In this flow, the device boots directly from external flash (FlexSPI). This is intended for zero‑touch provisioning scenarios, such as factory lines where devices must self‑provision automatically on first boot. You have two options for placing the OEM Manufacturing Firmware (OEM MFW) in flash.  Option 1: Fixed OEM MFW Address (0x08010000) Required Flash Layout Address Purpose 0x08000400 Flash Configuration Block (FCB) 0x08001000 DevHSM Loader FlexSPI Boot Firmware 0x08010000 OEM_MFW.sb3 Steps Program the FCB at 0x08000400 Must match the external flash device in use (size, timing, SPI mode, etc.). Program RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 at 0x08001000 Program OEM_MFW.sb3 at 0x08010000 On next boot, the DevHSM Loader automatically locates the OEM MFW at 0x08010000 and executes it. Option 2: OEM MFW at Custom Address If you want OEM_MFW.sb3 to reside at a different address, you must provide a configuration block at a fixed location: Configuration Block Location: 0x08006000 Size: 64 bits Format: Magic word (0x4448534D) || OEM_MFW target address Example @0x08020000: 4448534D00000208 This tells the DevHSM Loader where the OEM MFW is stored. Steps Program the FCB at 0x08000400 Write configuration block at 0x08006000 First 32 bits: 0x4448534D Next 32 bits: address of OEM_MFW.sb3 Program RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 at 0x08001000 Program OEM_MFW.sb3 at the desired flash address   Provisioning Behavior on Next Boot When the device powers up: The DevHSM loader initializes, Reads the fixed or custom location of the OEM MFW, Loads and executes OEM_MFW.sb3, OEM MFW provisions the device and may optionally: Configure dual‑boot setups, or Reprogram a new application at 0x08001000. Important Note The OEM_MFW.sb3 is responsible for installing or updating the device’s operational application after provisioning. It must either load the new app at the configured offset or reprogram the default application location (0x08001000).        

If you are trying to flash your FRDM-RW612 and one of the following J-Link errors appears: Error 1: ****** Error: Verification failed @ address 0x18000000 Error while programming flash: Verify failed.   Error 2:  ****** Error: Verification failed @ address 0x08000000 Error while programming flash: Verify failed.   This issue can occur for several reasons; one common case is when flashing an RD-RW612-BGA binary onto an FRDM-RW612 board. Doing so will lock the board, preventing any further writes to the flash until it is unlocked. Please try the following:  1. Get MCUXpresso Secure Provisioning Tool 2. Create a New Workspace and select RW612 3. In Source executable image select   <path_to>\MCUX_Provi_v9\bin\_internal\data\sample_data\targets\RW612\source_images\frdmrw612_gpio_led_output.s19    Click on the check box of the Configuration Helper message that appeared and click OK. 4. Set your board in ISP mode:    - Ensure the board is powered off (fully disconnected)    - Press and hold the ISP button (SW3)    - While holding SW3, connect the USB cable to J10 and your PC    - Release SW3 after the board powers up 5. In the options of the tool please select RW612, UART (select the correct PORTx), Plain, Flex SPI NOR - complete FCB, InField shadow regs, No TrustProvi and PyOCD.   6. Click on Build Image 7. Move to Write Image section and click on Write Image 8. Once the example is flashed, the LED in the board should start to blink 9. Power reset your board and try flashing a MCUXpresso SDK hello_world    I hope this helps. Regards, Daniel.  

This document summary BT classical RF parameters and give examples of nxp wif&bt product Bluetooth rf test and results analysis. The document includes:  Introduction BT key parameters Test Procedure & Result Analysis

 

Learn how to bring Wi-Fi connectivity to Zephyr’s projects based on the FRDM-RW612 board. This guide walks you through adapting the Ethernet-based mqtt_publisher sample to work over Wi-Fi using Zephyr v4.2.0. You'll explore the built-in wifi/shell example, configure the networking stack, and create a custom shell command to control MQTT publishing. Perfect for developers building IoT applications that need seamless cloud communication over wireless networks.

In the context of TF-M(Trusted Firmware-M), BL2 refers to the second stage bootloader. When using TF-M, the BL2 is based on open-source MCUBoot. It is responsible for verifying and loading the secure and non-secure images.  Current configuration of our downstream TF-M examples do not support enabling BL2. The following steps demonstrate how to configure the TF-M project, so that it can be linked directly with MCUBOOT from the upstream repository without enabling BL2.  Before starting, import/clone the downstream ZSDK repo at https://github.com/nxp-zephyr/nxp-zephyr using the release tag  nxp-v4.0.0 .  These steps are using the JLink debug probe. Once the repository is ready build and flash the FRDM-RW612. west init -m https://github.com/nxp-zephyr/nxp-zsdk.git nxp_zephyr cd nxp_zephyr west update   Build and Flash MCUBoot from Downstream west build -b frdm_rw612 -d build-mcuboot bootloader/mcuboot/boot/zephyr –-pristine west flash -d build-mcuboot  After resetting the device, the output will be seen as image below. At this point there isn't any image in the primary or secondary slots, as expected MCUBoot will not find an application to jump to.   Build and Flash TF-M from Downstream Modify secure image Using a text editor of choice locate the following two files in the folder: nxp_zephyr\modules\tee\tf-m\trusted-firmware-m\platform\ext\target\nxp\frdmrw612\partition Open the flash_layout.h header file Edit the FLASH_IMAGE_HEADER_SIZE macro. Since we know that MCUBoot uses a header this will be equal to 0x400. #define FLASH_IMAGE_HEADER_SIZE (0x400) Open the region_defs.h header file  Edit the S_IMAGE_PRIMARY_PARTITION_OFFSET macro. Based on the calculated above, the offset used in this example of the primary image will be 0x20400. #define S_IMAGE_PRIMARY_PARTITION_OFFSET (0x20400) Edit the M_BOOT_FLASH_CONF_START macro. This should be the same as the base address being used in MCUBoot's BOOT_FLASH_ACT_APP. #define M_BOOT_FLASH_CONF_START (0x18020000)  Locate the hardware_init.c source file in: nxp_zephyr\modules\tee\tf-m\trusted-firmware-m\platform\ext\target\nxp\frdmrw612\project_template/s  Edit the SystemInitHook and add the VTOR configuration at the beginning of this function: extern void *__VECTOR_TABLE[]; SCB->VTOR = (uint32_t)&(__VECTOR_TABLE[0]); Locate the CMakeLists.txt to disable the boot header in: nxp_zephyr\modules\tee\tf-m\trusted-firmware-m\platform\ext\target\nxp\frdmrw612 target_compile_definitions(tfm_s PUBLIC BOOT_HEADER_ENABLE=0 )​​ Modify non-secure image Using a text editor of choice locate the following two files in the folder: nxp_zephyr\zephyr\build\tfm\api_ns\platform\partition Open the flash_layout.h header file Edit the FLASH_IMAGE_HEADER_SIZE macro. Since we know that MCUBoot uses a header this will be equal to 0x400. #define FLASH_IMAGE_HEADER_SIZE (0x400) Open the region_defs.h header file  Edit the S_IMAGE_PRIMARY_PARTITION_OFFSET macro. Based on the calculated above, the offset used in this example of the primary image will be 0x20400. #define S_IMAGE_PRIMARY_PARTITION_OFFSET (0x20400) Edit the M_BOOT_FLASH_CONF_START macro. This should be the same as the base address being used in MCUBoot's BOOT_FLASH_ACT_APP. #define M_BOOT_FLASH_CONF_START (0x18020000)  Locate frdm_rw612_rw612_ns.dts in: nxp_zephyr\zsdk\boards\nxp\frdm_rw612  Edit the partitions to accomodate the non-secure image in the correct location according to the shift done in the memory layout. This will move the non-secure image from offset A_0000 to C_0000. partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; /* Note slot 0 has one additional sector, * this is intended for use with the swap move algorithm */ slot0_ns_partition: partition@80C0000 { label = "image-0-nonsecure"; reg = <0x080C0000 0x083C0000>; }; /* This partition is reserved for connectivity firmwares storage * and shouldn't be moved. */ fw_storage: partition@400000 { label = "fw_storage"; reg = <0x400000 0x280000>; read-only; }; }; }; &flexspi { reg = <0x40134000 0x1000>, <0x080C0000 DT_SIZE_M(128)>; };​ Build image Build  image using pristine paramter: west build -b frdm_rw612//ns samples/tfm_integration/psa_crypto/ --pristine Merge Binaries The Zephyr ecosystem does in fact create a tfm_merged.hex. Currently it is not compatible with the modifications made in this guide, so as a short-term solution the following steps will manually merge the two individual binaries that are also generated in the previous build step and are found in the build folder of the project.  tfm_s.bin - Secure image located in nxp_zephyr\zephyr\build\tfm\bin zephyr.bin -Nonsecure image located in nxp_zephyr\zephyr\build\zephyr  Note: This article does not show detailed steps of using the SPSDK command line tool. If detailed steps are needed please refer to spsdk.readthedocs.io. Additionally, the SPSDK is not necessary to merge the binaries, it can also be done manually by pasting the non-secure image at offset shown below in secure image binary. Use the following command to generate the template to merge the binaries. nxpimage utils binary-image get-template -o binary_merge_template.yaml Edit the template. Calculate the offset of the location of the non-secure image using FLASH_S_PARTITION_SIZE from the flash_layout.h header file. In this example the value is 0x9FC00.   Use the following command to merge the binaries. nxpimage utils binary-image merge -c binary_merge_template.yaml -o merged_tfm_demo.bin Place the merged_tfm_demo binary in a known location to easily find and sign it in the following steps.   Sign Binaries There are several options available to sign the image. To avoid downloading additional programs, the following steps use the imgtool.py that can be found in zephyr repository. To sign the binary in the command line use: imgtool sign --version 1.0 --header-size 0x400 --pad-header --slot-size 0x440000 --max-sectors 800 --align 4 --pad --confirm --key "nxp_zephyr\bootloader\mcuboot\root-rsa-2048.pem" "\knownPath\merged_tfm_demo.bin" "\knownPath\signed_tfm_demo.bin"   Flash the TFM Signed binary Using Jlink Since the mcuboot image has already been flashed to the device. Lets flash the signed image using jlink directly. Assuming that Jlink has been installed to your PC. You can find jlink.exe at: C:\Program Files\SEGGER\JLink_V###\JLink.exe To connect to the device. > connect > RW612 > SWD > 4000 The primary slot is at 0x18020000 loadfile "\knownPath\signed_tfm_demo.bin" 0x18020000   Using MCUXpresso for VSCode Copy the signed_tfm_demo.bin to your build/zephyr path of your repository if you stored elsewhere. Right click on the project select Flash the Selected Target   Select the signed_tfm_demo.bin and enter the address to program the binary.In this case it will be 0x18020000 Console Output Reset the device to run the mcuboot application + the tfm demo. *** Booting MCUboot v2.1.0-rc1-233-g346f7374ff44 *** *** Using Zephyr OS build v4.1.0-rc1-35-gc031e127b0fd *** I: Starting bootloader I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Secondary image: magic=bad, swap_type=0x0, copy_done=0x2, image_ok=0x2 I: Boot source: none I: Image index: 0, Swap type: none I: Bootloader chainload address offset: 0x20000 I: Image version: v1.0.0 I: Jumping to the first image slot Booting TF-M v2.1.1 [INF] Beginning TF-M provisioning [WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! Creating an empty ITS flash layout. Creating an empty PS flash layout. [INF][PS] Encryption alg: 0x5500200 [INF][Crypto] Provision entropy seed... [INF][Crypto] Provision entropy seed... complete. *** Booting Zephyr OS build nxp-v4.0.0 *** [00:00:09.058,779] <inf> app: app_cfg: Creating new config file with UID 0x55CFDA7A [00:00:10.092,276] <inf> app: att: System IAT size is: 367 bytes. [00:00:10.092,303] <inf> app: att: Requesting IAT with 64 byte challenge. [00:00:10.097,404] <inf> app: att: IAT data received: 367 bytes. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 D2 84 43 A1 01 26 A0 59 01 23 AA 3A 00 01 24 FF ..C..&.Y.#.:..$. 00000010 58 40 00 11 22 33 44 55 66 77 88 99 AA BB CC DD X@.."3DUfw...... 00000020 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000030 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000040 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000050 EE FF 3A 00 01 24 FB 58 20 A0 A1 A2 A3 A4 A5 A6 ..:..$.X ....... 00000060 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 ................ 00000070 B7 B8 B9 BA BB BC BD BE BF 3A 00 01 25 00 58 21 .........:..%.X! 00000080 01 4E 62 2B 02 F1 1A 68 BD 16 A3 44 CD 21 78 6D .Nb+...h...D.!xm 00000090 41 F6 F0 66 B7 C0 CA B9 CE FF CB 58 2C 70 C2 52 A..f.......X,p.R 000000A0 27 3A 00 01 24 FA 58 20 AA AA AA AA AA AA AA AA ':..$.X ........ 000000B0 BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC ................ 000000C0 DD DD DD DD DD DD DD DD 3A 00 01 24 F8 3A 3B FF ........:..$.:;. 000000D0 FF FF 3A 00 01 24 F9 19 30 00 3A 00 01 24 FE 01 ..:..$..0.:..$.. 000000E0 3A 00 01 24 F7 71 50 53 41 5F 49 4F 54 5F 50 52 :..$.qPSA_IOT_PR 000000F0 4F 46 49 4C 45 5F 31 3A 00 01 25 01 77 77 77 77 OFILE_1:..%.wwww 00000100 2E 74 72 75 73 74 65 64 66 69 72 6D 77 61 72 65 .trustedfirmware 00000110 2E 6F 72 67 3A 00 01 24 FC 73 30 36 30 34 35 36 .org:..$.s060456 00000120 35 32 37 32 38 32 39 2D 31 30 30 31 30 58 40 50 5272829-10010X@P 00000130 EA 50 C2 2A 43 83 D2 48 DC 35 75 36 97 F6 43 4C .P.*C..H.5u6..CL 00000140 98 BA BE 1E 24 F3 F5 23 6A 08 34 2B 0B 59 7A F1 ....$..#j.4+.Yz. 00000150 C6 C3 2E 1B CC E8 57 51 F3 0A C7 99 7E 91 DE FB ......WQ....~... 00000160 18 EE 55 D5 6D 49 D6 D4 6C 3A 3C 5E 9F 7E 47 ..U.mI..l:<^.~G [00:00:10.287,009] <inf> app: Persisting SECP256R1 key as #1 [00:00:10.434,117] <inf> app: Retrieving public key for key #1 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 04 3B E8 D6 DE DF BE 17 E4 C5 EC 80 8E 79 8D DE .;...........y.. 00000010 50 9C A6 28 D1 9D DA 83 E1 90 21 01 0D 17 77 E2 P..(......!...w. 00000020 D6 AD C7 84 11 C1 16 CA 2B 81 4F 58 0E A0 EF 6C ........+.OX...l 00000030 89 CE 9C 3E F7 F2 D3 8D D7 56 FE 3C C0 88 E3 EC ...>.....V.<.... 00000040 49 I [00:00:10.486,689] <inf> app: Calculating SHA-256 hash of value 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 50 6C 65 61 73 65 20 68 61 73 68 20 61 6E 64 20 Please hash and 00000010 73 69 67 6E 20 74 68 69 73 20 6D 65 73 73 61 67 sign this messag 00000020 65 2E e. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 9D 08 E3 E6 DB 1C 12 39 C0 9B 9A 83 84 83 72 7A .......9......rz 00000010 EA 96 9E 1D 13 72 1E 4D 35 75 CC D4 C8 01 41 9C .....r.M5u....A. [00:00:10.535,947] <inf> app: Signing SHA-256 hash 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 C0 01 00 60 0F 91 B2 7C 45 23 27 78 2E DC E4 D5 ...`...|E#'x.... 00000010 EB A3 00 A5 36 AD E3 07 4A 77 F8 8C 8F 53 B2 D5 ....6...Jw...S.. 00000020 A0 D4 87 F6 E9 81 A8 8D 48 6F 41 8A 7E 66 3B D2 ........HoA.~f;. 00000030 43 17 FC 28 BD 48 54 80 0F 85 7A AD EB 6D 7E D7 C..(.HT...z..m~. [00:00:10.582,417] <inf> app: Verifying signature for SHA-256 hash [00:00:10.604,945] <inf> app: Signature verified. [00:00:10.741,295] <inf> app: Destroyed persistent key #1 [00:00:10.747,691] <inf> app: Generating 256 bytes of random data. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 DA CD 89 21 56 F4 0A F8 46 F9 17 1B A2 3F 47 63 ...!V...F....?Gc 00000010 1E DC 08 3E 77 1E 4F 2D 0A 6F 0B 95 FF 12 2E BD ...>w.O-.o...... 00000020 1E CA 6E 0F 07 21 A1 B1 FB E1 EE C6 25 FF 8A 3D ..n..!......%..= 00000030 C3 9E D0 6E E1 DA 2B 44 C3 64 EF D1 DF 9C 41 B1 ...n..+D.d....A. 00000040 26 BE 1E 9A 6A F6 CC 90 1D E1 26 A7 70 A8 90 F9 &...j.....&.p... 00000050 E6 54 EB 08 2B B8 A6 D4 5C 4D B7 0F 2A 60 E3 B2 .T..+...\M..*`.. 00000060 63 99 E6 35 4D C8 A3 32 EA DF BE CD F6 C6 77 7E c..5M..2......w~ 00000070 40 41 7D DB 9C AD 48 96 C6 EA 36 2C 9B F6 62 F5 @A}...H...6,..b. 00000080 55 CE 74 62 83 F2 93 A5 4A 1D 8E 16 0B 7C 0F A7 U.tb....J....|.. 00000090 80 07 0C 35 44 08 EF 45 F8 E3 47 A8 CE 1A 5B C2 ...5D..E..G...[. 000000A0 75 F0 F9 AF E9 4C A7 E8 70 25 0E BC E6 76 70 1E u....L..p%...vp. 000000B0 0D E7 83 51 22 1F 1F B8 05 59 7F B6 B5 E0 43 95 ...Q"....Y....C. 000000C0 9E 2C C7 D1 09 BA FD BF E2 F5 26 97 6B 07 0D 60 .,........&.k..` 000000D0 15 3A 63 32 D8 28 C2 6E 16 31 C9 B1 4E D6 1E B4 .:c2.(.n.1..N... 000000E0 D3 F5 74 78 C0 3E B0 6F E3 98 C8 EE F2 19 ED 99 ..tx.>.o........ 000000F0 A7 39 E2 2E 87 C0 BD A7 C0 03 2C 96 B2 67 50 38 .9........,..gP8 [00:00:10.865,339] <inf> app: Initialising PSA crypto [00:00:10.870,839] <inf> app: PSA crypto init completed [00:00:10.876,564] <inf> app: Persisting SECP256R1 key as #1 [00:00:11.025,601] <inf> app: Retrieving public key for key #1 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 04 D9 A2 50 5E 46 60 72 AC E5 80 10 E6 4D 6D 0D ...P^F`r.....Mm. 00000010 B5 02 AB FC 7A 07 3E 98 74 D4 F0 EC 4F 83 D8 47 ....z.>.t...O..G 00000020 49 D0 A3 E8 0C 14 7E 24 79 A3 15 F6 37 77 4C E1 I.....~$y...7wL. 00000030 48 95 7A A6 78 8A E6 60 32 C8 64 BC B2 0F 55 B4 H.z.x..`2.d...U. 00000040 A4 . [00:00:11.078,458] <inf> app: Adding subject name to CSR [00:00:11.084,291] <inf> app: Adding subject name to CSR completed [00:00:11.090,857] <inf> app: Adding EC key to PK container [00:00:11.097,031] <inf> app: Adding EC key to PK container completed [00:00:11.103,883] <inf> app: Create device Certificate Signing Request [00:00:11.129,706] <inf> app: Create device Certificate Signing Request completed [00:00:11.137,653] <inf> app: Certificate Signing Request: -----BEGIN CERTIFICATE REQUEST----- MIHpMIGQAgEAMC4xDzANBgNVBAoMBkxpbmFybzEbMBkGA1UEAwwSRGV2aWNlIENl cnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2aJQXkZgcqzlgBDm TW0NtQKr/HoHPph01PDsT4PYR0nQo+gMFH4keaMV9jd3TOFIlXqmeIrmYDLIZLyy D1W0pKAAMAoGCCqGSM49BAMCA0gAMEUCIQCvq1EVicUgZyv80QV4T/sqhYiI9jbq 3feb7bcfImCU9QIgAt5ATTnQUan9zKasUVxBeHAdorHo+dW9oj86wdM1v4I= -----END CERTIFICATE REQUEST----- [00:00:11.178,921] <inf> app: Encoding CSR as json [00:00:11.184,360] <inf> app: Encoding CSR as json completed [00:00:11.190,364] <inf> app: Certificate Signing Request in JSON: {"CSR":"-----BEGIN CERTIFICATE REQUEST-----\nMIHpMIGQAgEAMC4xDzANBgNVBAoMBkxpbmFybzEbMBkGA1UEAwwSRGV2aWNlIENl\ncnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2aJQXkZgcqzlgBDm\nTW0NtQKr/HoHPph01PDsT4PYR0nQo+gMFH4keaMV9jd3TOFIlXqmeIrmYDLIZLyy\nD1W0pKAAMAoGCCqGSM49BAMCA0gAMEUCIQCvq1EVicUgZyv80QV4T/sqhYiI9jbq\n3feb7bcfImCU9QIgAt5ATTnQUan9zKasUVxBeHAdorHo+dW9oj86wdM1v4I=\n-----END CERTIFICATE REQUEST-----\n"} [00:00:11.233,581] <inf> app: Done.

Hardware : i.MX8MN-EVK Wi-Fi module on the board is 88W8987. Software: BSP is i.MX Yocto Linux BSP L6.12.3_1.0.0.   Topics: Introduction of Wi-Fi driver configuration file : wifi_mod_para.conf  How to load the Wi-Fi driver How to configure the WPA2/WPA3  5G/2G connection How to use wpa_supplicant to connect to the AP Introduction of some wpa_supplicant.conf parameters    

Hardware board : NXP i.MX8MN-EVK  Wi-Fi module on the board is 88W8987. Software : BSP is i.MX Yocto Linux BSP L6.12.3_1.0.0.   Topic: Wi-Fi driver configuration :  wifi_mod_para.conf file How to load the Wi-Fi driver How to use hostapd to configure the 2G connection (uap0) How to start the uap0 2G connection How to use hostapd to configure the 5G connection (uap0) How to start the uap0 5G connection uap0 + ethernet connection    

The article will introduce the following contents. No.1 Preparation          1. Ubuntu 20.04 Host          2. Downloading Mass Market Driver(FP92)source code No.2 For ARM Platform          1. Toolchain For cross compilation          2. Linux Kernel source code of target board          3. Building Linux Kernel source code of target board          4. Building NXP Wi-Fi Mass Market Driver source code No.3 For X86 Platform          1. Compilation on different ubuntu version 1.1 Ubuntu 16.04 LTS 1.2 Ubuntu 18.04 LTS 1.3 Ubuntu 20.04 LTS 1.4 Ubuntu 22.04 LTS         2. Cross Compilation on Ubuntu 20.04 LTS 2.1 Linux kernel 4.9 2.2 Linux kernel 5.10 2.3 Linux kernel 6.12 No.4 Conclusion     NXP TIC Connectivity Team Weidong Sun Apr-18-2025

The article described steps on how to enable SDIO Wi-Fi & Bluetooth on M.2 interface. The main contents are like below: ========================= 1. Introduction  2. Steps            2.1 Board Configurations            ① BoardConfig.mk            ② evk_8mp.mk            ③ SharedBoardConfig.mk            ④ imx8mp_gki.fragment           2.2 Wi-Fi & Bluetooth Configurations            ① wifi_mod_para.conf            ② bt_vendor.conf            ③ vendor_interface.cc  3. Building & Downloading images to i.MX8MP-EVK          3.1 Building images          3.2 Downloading images  4. Running Android images to verify Wi-Fi & Bluetooth  =========================   For other versions of Android bsp or SDIO Wi-Fi/BT on M.2, same steps.   NXP TIC Connectivity Team, Weidong Sun    

The article introduces steps on how to transmit files between IW612 Bluetooth and remote devices on linux platform.   NXP TIC Connectivity Team Weidong Sun

The article introduces the following contents related to 88W9098. 1. Introduction     1.1 Software Tools     1.2 Hardware Tools     1.3 Diagram of connections 2. Configurations     2.1 Loading Wi-Fi driver     2.2 Connecting external AP          2.2.1 mlan0 to external AP with 5G          2.2.2 mmlan0 to Mobile with 2.4G 2.3 Configuring iptables 2.4 DHCP service on ethernet 3. Wi-Fi Bridge Verification     3.1 Verification of Ethernet to mlan0     3.2 Verification of Ethernet to mmlan0   NXP TIC Connectivity Team Weidong Sun  

Previously, we discussed how to compile the SDK_2.16 zigbee source code. The article is here: https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/NXP-Wi-Fi-amp-Bluetooth-Product-Building-RW612-Zigbee-Source/ta-p/2097613 The latest SDK zigbee source code compilation method is different. The author conducted an experiment and recorded the relevant steps for users' reference. In the article, we will discuss the following contents.  1. Introduction 2. Preparation before compilation                 2.1 CMake                 2.2 Ninja                 2.3 ARM GCC tool chain                 2.4 Python3                 2.5 West                 2.6 MCUXPress SDK 3. Building Zibgee Source Code on ubuntu 20.04 host                 3.1 Setting up environment                 3.2 Building coordinator                 3.3 Building mcu bootloader                 3.4 Building router 4. Verified ARM GCC Version 5. Programing QSPI Nor Flash   NXP TIC Connectivity Team Weidong Sun June-09-2025  

The article introduces steps on how to build RW612 zigbee source code, it includes the following contents: 1. Introduction 2. Preparation before compilation       2.1 CMake       2.2 Ninja       2.3 ARM GCC tool chain      2.4 Python3      2.5 MCUXPress SDK 3. Building Zibgee Source Code on ubuntu 20.04 host      3.1 Setting up environment      3.2 Compilation steps 4. Compilation on other ubuntu host      4.1 ubuntu 22.04      4.2 ubuntu 24.04 5. Verified ARM GCC Version 6. Programing QSPI Nor Flash   NXP TIC connectivity team  Weidong Sun May-15-2025