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

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 can happen because of different reasons; the one I have addressed is when we flash a RD-RW612-BGA binary into FRDM-RW612. When doing this the board will get locked, and we will no longer be able to write data into the flash until we unlock it.  Please try the following:  1. Get MCUXpresso Secure Provisioning Tool 2. Create a New Workspace and select RW612 3. In Source executable image select i.e. "<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; Connect the USB cable to your PC via J10 with the ISP (SW3) button pressed. 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.  

HCI Application is a Host Controller Interface application which provides a serial communication to interface with the KW40/KW41/KW3x/QN9080 BLE radio part.   It enables the user to have a way to control the radio through serial commands.   The format of the HCI Command Packet is composed by the following parts.   Figure 1. HCI Command Packet   Each command is assigned a 2 byte Opcode which is divided into two fields, called the OpCode Group Field (OGF) and OpCode Command Field (OCF).   The OGF uses the upper 6 bits of the Opcode, while the OCF corresponds to the remaining 10 bits.   The OGF of 0x3F is reserved for vendor-specific debug commands. The organization of the opcodes allows additional information to be inferred without fully decoding the entire Opcode.    For further information regarding this, please check the BLUETOOTH SPECIFICATION Version 5.0 | Vol 2, Part E, 5.4 EXCHANGE OF HCI-SPECIFIC INFORMATION.    This document will guide you through the implementation of custom HCI commands in the KW36, but it can be applied as well for the rest of the NXP Bluetooth LE MCU’s that support HCI.   The following changes were made and tested in the FREEDOM KW38 and will generate a continuous with both channel and power configurable.      You will need to perform the following changes to the HCI black box demo.   Modify the hci_transport.h public constants and macros section by adding:       #define gHciCustomCommandOpcodeUpper (0xFC90) #define gHciCustomCommandOpcodeLower (0xFC00) #define gHciInCustomVendorCommandsRange(x) (((x) <= gHciCustomCommandOpcodeUpper) && \ ((x) >= gHciCustomCommandOpcodeLower))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍       In this case, the opcodes 0xFC90 to 0xFC00 are not used by our stack. These opcodes meet the requirements for vendor specific commands (OCF = 3F).   Then you will need to declare the handler for the custom command.       void Hcit_InstallCustomCommandHandler(hciTransportInterface_t mCustomInterfaceHandler);‍‍‍‍‍         In the  hcit_serial_interface.c modify the following :   Add in the private memory declarations section       static hciTransportInterface_t mCustomTransportInterface = NULL;‍‍‍‍‍     Change the Hcit_SendMessage as it is shown:       static inline void Hcit_SendMessage(void) { uint16_t opcode = 0; /* verify if this is an event packet */ if(mHcitData.pktHeader.packetTypeMarker == gHciEventPacket_c) { /* verify if this is a command complete event */ if(mHcitData.pPacket->raw[0] == gHciCommandCompleteEvent_c) { /* extract the first opcode to verify if it is a custom command */ opcode = mHcitData.pPacket->raw[3] + (mHcitData.pPacket->raw[4] << 8); } } /* verify if command packet */ else if(mHcitData.pktHeader.packetTypeMarker == gHciCommandPacket_c) { /* extract opcode */ opcode = mHcitData.pPacket->raw[0] + (mHcitData.pPacket->raw[1] << 8); } if(gHciInCustomVendorCommandsRange(opcode)) { if(mCustomTransportInterface) { mCustomTransportInterface( mHcitData.pktHeader.packetTypeMarker, mHcitData.pPacket, mHcitData.bytesReceived); } } else { /* Send the message to HCI */ mTransportInterface( mHcitData.pktHeader.packetTypeMarker, mHcitData.pPacket, mHcitData.bytesReceived); } MEM_BufferFree( mHcitData.pPacket ); mHcitData.pPacket = NULL; mPacketDetectStep = mDetectMarker_c; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍       Implement the registration of the handler     void Hcit_InstallCustomCommandHandler(hciTransportInterface_t mCustomInterfaceHandler) { OSA_EXT_InterruptDisable(); mCustomTransportInterface = mCustomInterfaceHandler; OSA_EXT_InterruptEnable(); return; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍        Once those changes are done, we will need to modify the  hci_black_box.c with the following changes.    Add the files to support HCI Custom commands.       #include "hci_transport.h" #include "fsl_xcvr.h"‍‍‍‍‍‍‍‍‍‍       Define the custom commands, in this case, we will create some to turn ON/OFF the continuous wave as well as to set up the channel and power.        //@CC custom command #define CUSTOM_HCI_CW_EVENT_SIZE (0x04) #define CUSTOM_HCI_EVENT_SUCCESS (0x00) #define CUSTOM_HCI_EVENT_FAIL (0x01) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍     Also, adding some app auxiliar variables      static uint16_t channelCC = 2402; static uint8_t powerCC = 0x3E;       Create the custom event packet        uint8_t eventPacket[6] = {gHciCommandCompleteEvent_c, CUSTOM_HCI_CW_EVENT_SIZE, 1, 0, 0, 0 };‍‍‍‍‍       In the main_task() after the BleApp_Init() register the callback for the custom commands.       /* Initialize peripheral drivers specific to the application */ BleApp_Init(); //Register the callback for the custom commands. Hcit_InstallCustomCommandHandler(BleApp_CustomCommandsHandle);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍       Once that it’s added, add the handler for the command       bleResult_t BleApp_CustomCommandsHandle(hciPacketType_t packetType, void* pPacket, uint16_t packetSize) { uint16_t opcode = 0; uint8_t error=0; switch(packetType) { case gHciCommandPacket_c: opcode = ((uint8_t*)pPacket)[0] + (((uint8_t*)pPacket)[1] << 8); if (opcode >= 0xfc00 & opcode <= 0xfc50) { channelCC = 2400+(opcode - 0xfc00); eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else if (opcode <= 0xfc70) { powerCC = (opcode-0xfc50)*2; if (gXcvrSuccess_c ==XCVR_ForcePAPower(powerCC) eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; else eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } else if (opcode == 0xfc80) { if (gXcvrSuccess_c == XCVR_DftTxCW(channelCC*1000000)) { eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } else if(opcode == 0xfc90) { XCVR_ForceTxWd(); /* Initialize the PHY as BLE */ XCVR_Init(BLE_MODE, DR_1MBPS); eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else { eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } eventPacket[3] = (uint8_t)opcode; eventPacket[4] = (uint8_t)(opcode >> 8); Hcit_SendPacket(gHciEventPacket_c, eventPacket, sizeof(eventPacket)); break; default: break; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍}     The format of this HCI command is: 01 XX FC 00 Where: When 0<=XX<=50: set the transmitting channel. The transmitting frequency is (2400+XX (in hexadecimal) )*1000MHz When 50<xx<70: set the transmitting power. 51 is the minimum Tx power and 69 corresponds to the maximum Tx power. When XX = 80: start the CW transmission When XX = 90: Stop the CW transmission   For example, if you want to transmit a CW on the frequency 2420MHz at maximum frequency, you should send the following command: 01 14 FC 00 01 69 FC 00 01 80 FC 00   whenever you want to change the channel or Tx power, please stop the ongoing Tx first by sending 01 90 FC 00 Then repeat the previous step.   If you want to add some parameter to it, please consider that the fourth byte of the packet will correspond to the number of parameters to enter and you will need to indicate it there. 

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.  Our MCUXpresso SDK takes the open-source MCUBoot and leverages the HW features available to the specific SoC that is being used. In addition, TF-M support for the SoC is also available in the SDK package. Current configuration of TF-M within the SDK does not support enabling BL2. The following steps demonstrate how to configure the TF-M project in the SDK, so that it can be linked directly with MCUBOOT from our SDK without enabling BL2.  Import MCUBOOT_OPENSOURCE example Select Import SDK Example and select the board you are working with. Browse the ota_examples to find the mcuboot_opensource example. Select this and press Next. The following window will contain the memory configuration of the example. It is important to change the Location address(0x18000000) to the secure alias and the Driver(*_S.cfx) to the secure version of the driver. Then press Finish.   Locate the flash_partioning.h header file within the project to determine the start address of where the TF-M secure image will be located. This will be represented by the BOOT_FLASH_ACT_APP macro. #define BOOT_FLASH_ACT_APP 0x18020000. In this example, I know that the secure image should be located in the offset 0x20000. Additionally, using MCUBoot means that we will have a header attached to the image when signed, this will add an addition 0x400. In total my offset will be 0x20400.  Open the preprocessor configurations in the project by right clicking the project and select Properties. With the window open navigate to the following location: C/C++ Build -> Settings -> MCU C Compiler -> Preprocessor Set BOOT_HEADER_ENABLE = 0 Press Apply and Close. Build mcuboot image. Import TFM_DEMO_S/NS example Select Import SDK Example and select the board you are working with. Browse the tfm_examples to find the tfm_demo_s/ns examples. Select these and import.  Open the preprocessor configurations in the project by right clicking the project and select Properties. With the window open navigate to the following location: C/C++ Build -> Settings -> MCU C Compiler -> Preprocessor Set BOOT_HEADER_ENABLE = 0 Open the flash_layout.h header file under the following folder in the tfm_demo_s project: tf-m/platform/ext/target/nxp/*board*/partition/ 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 under the following folder: tf-m/platform/ext/target/nxp/*board*/partition/ 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) Open the startup_*board*.c source file under the following folder: tf-m/platform/ext/target/nxp/*board*/Device/Source Edit the void Reset_Handler(void) function. Add the VTOR configuration so that it points to the top of the vector table.  // Config VTOR & MSPLIM register __asm volatile ("LDR R0, =0xE000ED08 \n" "STR %0, [R0] \n" "LDR R1, [%0] \n" "MSR MSP, R1 \n" "MSR MSPLIM, %1 \n" : : "r"(__VECTOR_TABLE), "r"(__STACK_LIMIT) : "r0", "r1"); *Note: This step is only done on the secure image. Press Apply and Close. Build secure image. Repeat the same steps 2- 8 in this section for the non-secure image and build. Generate Binaries Under the Debug folder you will find the .axf file generated automatically by MCUXpresso IDE under the secure project. Right click on this and navigate to Binary Utilities -> Create Binary.  Repeat for non-secure image. Merge Binaries 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.  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   Use Secure Provisioning Tool to Sign Images Note: This article does not show detailed steps of using MCUXpresso Secure Provisioning Tool. If detailed steps are needed please refer to the its user guide available in the Help Menu of the tool.  Select the MCUBOOT_OPENSOURCE image as your source. Open the MCUBoot -> Sign Image tool.  Select the merged binary as your source. The output image should be filled automatically to the bootable_images folder of the secure provisioning workspace. Select the key used to authenticate the image. In mcuboot_opensource workspace there is a key folders that contain example keys used for development.   4. Press Sign, then make sure that the target address matches the based address defined in the mcuboot for the primary partition, then save & close.  5. Build and Write Image accordingly with the Secure Provisioning Tool.  Run Application  

Where to find Wi-Fi Software Drivers   NXP Recommends using Wi-Fi source code drivers available from GitHub based on the following decisions:     Software Drivers NXP Processor Linux software drivers on NXP host processor (i.MX6, 7, 8 or 9) Driver: GitHub - nxp-imx/mwifiex: WiFi extensions Radio firmware: GitHub - nxp-imx/imx-firmware Pre-built binary demo files for each quarterly BSP release are available here: Linux: Embedded Linux for i.MX Applications Processors | NXP Semiconductors Android: Android OS for i.MX Applications Processors | NXP Semiconductors Software Drivers NXP Microcontrollers RTOS software drivers on NXP host processor (MCX, MCU, or i.MX RT) Wi-Fi driver: GitHub - NXP/wifi_nxp: NXP Wi-Fi driver and networking utilities Bluetooth middleware: GitHub - nxp-mcuxpresso/mcux-sdk-middleware-edgefast-bluetooth: EdgeFast Bluetooth PAL Software Drivers Non-NXP Processor Non-nxp host processor with Linux or Android Driver: GitHub - nxp-imx/mwifiex: WiFi extensions Radio firmware: GitHub - nxp-imx/imx-firmware Software Drivers Non-NXP Microcontrollers Non-nxp host MCU RTOS Link: https://www.keil.arm.com/packs/wifi-nxp/versions In addition to GitHub, RTOS drivers are available on NXP web site and as an Open CMSIS Pack from ARM: SDK BUILDER mcuxpresso.nxp.com/en/welcome NXP Website Available in SDK Builder on nxp.com Distributed in .zip folder alongside entire SDK    OPEN-CMSIS-PACKS www.keil.arm.com/packs/wifi-nxp/versions/ ARM Open-CMSIS Pack NXP Wi-Fi driver CMSIS Pack Distributed as ARM CMSIS pack   Linux Drivers are available as a .ZIP folder from each of the Wi-Fi specific product pages.

This document shares how to porting specific mfg sdk to specific Linux version. Then this document introduce how to configure labtool.  mfg tool is used for wireless product rf test and calibration. The setup environment:  DUT: EVK: iw612 QFN-IPA V2 Driver version: Linux_5_15_32_IMX8_SD-UART-BT-IW612-18.99.1.p154.38-18.99.1.p154.38- MXM5X18364.p19_V1-MGPL Labtool Package: MFG-AW-IW61X-MF-BRG-U16-WIN-X86-1.0.0.39.1-18.80.1.p154.38 o Host: Host board: i.MX8mm-evk OS: i.MX8mm Linux 5.15.32 demo image

This article shares setup steps and test examples of mfg_tool. The mfg_tool is used for non-singling RF test and calibration.  The test environment as belows:  SW: J-Link: https://www.segger.com/downloads/jlink/JLink_Windows_x86_64.exe MFG Software Package: https://www.nxp.com/webapp/Download?colCode=MFG-RW61X-MF-BRG-U16-WIN-X86-200200-18806-p1&appType=license HW: Rd-RW612-BGA-IPA-2A/1A-V4 LitePoint MW7G Windows PC   For more cmd details and calibration steps, please refer to following document: AN13619; UM11801

SC16is752 is a I2C to dual UART bridge, it is often used to expand UART interface when SoC UART can't provide sufficient interfaces, some users also select the chip to connect Bluetooth UART, in the article, the following 4 contents will be described. 1. Hardware connections (1) i.MX8MP-EVK--->SC16IS752---->nxp  IW416-EVK UART (2)i.MX8MP-EVK--->SC16IS752 (CPU UART <--->SC16IS752 UART Channel A) 2. Software configurations (1) Kernel options (2) SC16IS752 device tree 3. UART Test  Transmitting data between CPU uart3 & SC16is752 UART_A 4. Bluetooth test UART_A of SC16IS752 is connected to IW416 BT UART, and make a file transmission between PC & IW416 using obexd & obexctl tool.   NXP TIC Connectivity Team Weidong Sun Oct-28-2024

This article gives detailed hands-on steps about how to do Bluetooth A2DP music playing and Wi-Fi 2.4G iperf throughout coexist test. The hands-on test is based on 88W8997 with I.MX8MQ which is based on Linux 5.15.71 host platform. Using driver is  Q1-2024 released Wi-Fi driver + Q1-2024 released FW version. You can refer to this article to do similar Bluetooth A2DP music playing and Wi-Fi 2.4G iperf throughout test on other Wi-Fi/Bluetooth chips based on other Linux platform. For detailed steps, please refer to attached pdf file.   Best regards, Christine.