Skip to main content

iMX RT and NXP/Marvel

Introduction​

This section is a step-by-step guide to get Wi-Fi up and running in the shortest possible time:

  1. The first step is to download and install the SDK.
  2. The second step describes how to physically mount the M.2 module.
  3. The third step describes how to set up, modify, and run the example project.

Above are the three simple steps to get up-and-running immediately!

NXP's SDK supports several IDEs, but this guide is focusing on the free MCUXpresso IDE from NXP. Combining this document and the more general Program Development Guide should make it easy to use another IDE as well.

note

This document focuses only on the NXP/Marvell based modules as the support for Cypress/Infineon was removed in SDK 2.10.0. For information about Cypress/Infineon modules see here.

NXP IW416NXP 88W8801NXP 88W8987NXP MW32x
1XK2DS1ZMABR
SDIOSDIOSDIOUART
Board
imxrt1052--------
imxrt1062Wi-Fi/BTWi-FiWi-Fi/BT--
imxrt1064 1Wi-FiWi-FiWi-FiWi-Fi
imxrt1166Wi-FiWi-FiWi-FiWi-Fi
imxrt1176Wi-Fi/BTWi-FiWi-Fi/BTWi-Fi
1 Requires use of uSD-to-M.2 adapter

Further Information​

Supported Examples​

These are the examples found in the SDKs (availability may vary depending on CPU and SDK version). Examples with AWS in the name or with a description mentioning AWS requires an account. The process of setting one up is described in each project’s readme.txt file.

Table is for iMX RT1176 SDK 2.11.1

ExampleDescription
aws_tests_wifi_nxpAmazon FreeRTOS Qualification (AFQ) Tests.
greengrass_discovery_wifi_nxpRequires an AWS account and something running the AWS Greengrass. From the readme.txt for the example:
This example demonstrates how the board can discover Greengrass core and communicate with AWS IoT cloud through it.
You will need device (A Mac, Windows PC, or UNIX-like system) for running AWS Greengrass. Example will connect to Wi-Fi network, try to discover your AWS Greengrass device and send Hello World message to AWS IoT cloud through it.
This demo needs Wi-Fi network with internet access and opened 8883 and 8443 ports.
ota_demo_wifiThis example demonstrates how to perform OTA (over-the-air) firmware update of the board using AWS IoT. It requires an AWS account and the firmware built from the mcuboot_opensource example.
remote_control_wifi_nxpUses an Android App and the AWS IoT framework to control an LED
shadow_wifi_nxpUses the AWS IoT framework to communicate with a "shadow" of the device in the cloud.
lwip_httpscli_ota_wifiLike ota_demo_wifi but does not rely on AWS IoT. This example will connect to an HTTPS server (a simple python3-based server is included) and request the OTA binary that will be downloaded and installed.
lwip_httpssrv_ota_wifiThis example has a webserver and the user can connect to it to upload a new version of the firmware and then restart to perform the update.
wifi_certThe example presents a shell in a serial terminal where the user can interact with the Wi-Fi module by entering different commands to initialize, scan, connect, setup access point etc.
wifi_cliLike wifi_cert but fewer supported commands.
wifi_cli_fw_dumpDemonstrates how to dump the firmware onto a USB memory.
wifi_ipv4_ipv6_echoAn UDP and TCP echo server supporting IPv4 and IPv6
wifi_setupSimple example showing how to search for and connect to a Wi-Fi network
wifi_test_modeShows how to use the Wi-Fi Test Mode
wifi_webconfigExample that starts of in provisioning mode where the board starts up an access point which the user can connect to. After connecting it is possible to open an URL where a list of all found Wi-Fi networks are listed. The user can then pick and configure one of the networks. The credentials are stored in the flash of the MCU and after a reboot the board connects to that Wi-Fi network instead of starting an access point.
a2dp_sink / a2dp_sourceShowcases A2DP (Advanced Audio Distribution Profile) which is a Bluetooth profile for audio streaming between two devices.
The a2dp_sink example receives the audio from either a mobile phone or another iMX RT Developer’s Kit running a2dp_source and plays it in the headphones.
The a2dp_source example searches for and connects to either a phone or another iMXRT Developer’s Kit running a2dp_sink and plays music.
audio_profileRequires an AWS account, an Android App, a Bluetooth headset and a USB memory with mp3 files to play.
The Android App connects to the AWS cloud and controls the audio demo (play/pause). The iMX RT Developer’s Kit is connected to the AWS cloud using Wi-Fi and to the headset using Bluetooth.
central_hpc / peripheral_hpsShowcases HPS, HTTP Proxy Service (https://www.bluetooth.com/specifications/specs/http-proxy-service-1-0/)
This HTTP Proxy Service (HPS) Specification introduces a service that allows a Client device, typically a sensor, to communicate with a Web Server through a gateway device. The gateway device implements the HTTP Proxy Service and therefore provides the services available through the Internet to the Client sensor device.
The central_hpc is the client device, peripheral_hps is the gateway device.
central_ht / peripheral_htShowcases HTS, Health Thermometer Service (https://www.bluetooth.com/specifications/specs/health-thermometer-service-1-0/):
The Health Thermometer Service exposes temperature and other data related to a thermometer used for healthcare applications.
The central_ht example will search for and connect to the first BLE device which advertises the Health Thermometer Service and then report the temperature readings.
The peripheral_ht example will advertise the Health Thermometer Service and publish simulated temperature readings to subscribed clients.
central_ipsp / peripheral_ipspShowcases IPSP, Internet Protocol Support Profile (https://www.bluetooth.com/specifications/specs/internet-protocol-support-profile-1-0/)
This Profile Specification proposes the support of exchanging IPv6 packets between devices over the Bluetooth Low Energy transport.
The central_ipsp example will search for and connect to the first BLE device that advertises IPSP and then send a message every 5 seconds.
The peripheral_ipsp example will advertise the IPSP Service and display messages from clients in the console.
central_pxm / peripheral_pxrShowcases PXP, Proximity Profile (https://www.bluetooth.com/specifications/specs/proximity-profile-1-0-1/)
The Proximity profile defines the behavior when a device moves away from a peer device so that the connection is dropped or the path loss increases above a preset level, causing an immediate alert. This alert can be used to notify the user that the devices have become separated. As a consequence of this alert, a device may take further action, for example to lock one of the devices so that it is no longer usable.
The central_pxm example will search for and connect to the first BLE device that advertises IPSP (or more specifically the Link Loss Service) and then monitor the Tx Power Level as well as register for alarms.
The peripheral_pxr example will advertise the Link Loss Service.
handsfree / handsfree_agShowcases HFP, Hands-Free Profile (https://www.bluetooth.com/specifications/specs/hands-free-profile-1-8/)
The Hands-Free Profile (HFP) specification defines a set of functions such that a Mobile Phone can be used in conjunction with a Hands-Free device (e.g., installed in the car or represented by a wearable device such as a headset), with a Bluetooth Link providing a wireless means for both remote control of the Mobile Phone by the Hands-Free device and voice connections between the Mobile Phone and the Hands-Free device.
The handsfree example demonstrates basic functionality of the HFP HF (Hands-Free Unit) and must be connected to an HFP AG (Audio Gateway) like a mobile phone or an iMX RT Developer’s Kit running the handsfre_ag example. The device supports basic functionality including accepting/rejecting/ending the incoming call from an AG (Audio Gateway).
The handsfree_ag example demonstrates the basic functionality of the HFP AG (Audio Gateway) and can simlate an incoming call and the call can be answered and ended.
shellThe example presents a shell in a serial terminal where the user can interact with the Bluetooth module by entering different commands to initialize, scan, connect, advertise etc.
sppShowcases SPP, Serial Port Profile (https://www.bluetooth.com/specifications/specs/serial-port-profile-1-2/)
This profile defines the requirements for Bluetooth® devices necessary for setting up emulated serial cable connections using RFCOMM between two peer devices
The example presents a shell in a serial terminal where it is possible to configure for either a client or a server.
wifi_provisioningRequires an AWS account and an Android App. From the readme.txt for the example:
This example demonstrates how the Wi-Fi of the board can be configred by Android mobile application, and publish the Wi-Fi AP information to the AWS IoT.
AWS Wi-Fi provisioning example will start advertising if the Wi-Fi AP is not configured and wait the Wi-Fi AP configuration. After connected to the Android APK, the example will execute the request from cellphone and reply the response. When the Wi-Fi AP is configured, the Shadow demo will connect to the AWS via Wi-Fi and publish the configured Wi-Fi AP information.
wireless_uartFrom the readme.txt for the example:
The application implements a custom GATT based Wireless UART Profile that emulates UART over BLE.the application can work as central and peripheral at the same time. central and peripheral role can be switched by user button.
To test the service/profile the "IoT Toolbox" application can be used which is available for both Android and iOS.IoT Toolbox can be found on iTunes or Google playstore.

Step #1: Downloading and Installing MCUXpresso SDK​

This section will walk you through the installation of the MCUXpresso SDK, which is a package of sample software projects (with device drivers and peripheral examples and demos) that will get you started immediately with your i.MX RT software development. Note that even though the name of the SDK suggests the code package is for the MCUXpresso IDE, the sample projects have project files for other IDEs as well, such as Keil uVision/MDK, IAR Embedded Workbench, and more.

Start by downloading the patched SDK (making sure to pick the correct version according to the table above) from this URL: http://imx.embeddedartists.com/.

SDK Downloads from imx.embeddedartists.com

Save the file on your computer. Note the download location. The file name always contains the CPU, SDK version and release date.

The SDK needs to be installed in MCUXpresso before it can be used. To do that start MCUXpresso and then drag-n-drop the downloaded SDK archive (eaimxrt1176_sdk_2_11_1_2022-03-28.zip) on to the "Installed SDKs" tab:

Installed SDKs

Step #2: Mount M.2 Module​

Make sure the iMX RT Developer's Kit is powered off and then mount the M.2 Module, as illustrated in the pictures below:

M.2 Module on iMX OEM Carrier Board

M.2 Module on uCOM Carrier Board

M.2 Module in uSD-to-M2 adapter on uCOM Carrier Board

note

Do not put too much force/pressure on the M2 screw (into the M.2 connector stand-off) so that the PCB is bent. Bending the PCB too much will damage the board!

Use your fingers on the bottom side (while screwing) to give a counter-force, keeping the PCB straight.

The picture below illustrates the typical angle (about 25 degrees) to use when inserting the M.2 module into the connector. The pictures illustrate another carrier board, but the principle is exactly the same, regardless of carrier board.

M.2 Module on Carrier Board

The picture below illustrates how to use two fingers, placed under the grounding stand-off, to avoid bending the board. Make sure to always use this method to avoid damaging the board.

M.2 Module on Carrier Board

Step #3: Import, Configure, Run Example​

Running any of the examples requires the following steps:

  1. Import the example
  2. Select which Wi-Fi solution to use
  3. Configure the example for your environment (e.g. SSID + password for your network)
  4. Compile and debug/run

Import Example​

The following steps will guide you through opening the wifi_cli application from the SDK.

  1. Install the SDK as described in Step #1 if you have not done so already
  2. Click the Import SDK example(s)... link in the Quickstart Panel.
    Quickstart Panel
  3. This step will use the iMX RT1176, but the instructions are the same for any of the supported iMX RT boards. Select the MIMXRT1170 and eaimxrt1176. Click Next to go to the project selector.
    Select Board
  4. Select the wifi_cli example and make sure to switch from Semihost to UART for the SDK Debug Console.
    Select UART as Debug Conole
  5. With the changes made, click Finish to have MCUXpresso complete the project setup

Select M.2 Module​

The first thing to do after importing a new project it to make sure that it is setup for the correct M.2 module. This is done in app_config.h with a define. The line is surrounded with TEST_ANCHOR comments and looks like this:

Select M.2 Module

Select what to define based on what you use. Note that not all combinations are available in every example and for every board (e.g. the 2DS module cannot be selected for a Bluetooth example as it does not support Bluetooth).

DefineComment
WIFI_88W8801_BOARD_MURATA_2DS_M22DS M.2 module
WIFI_IW416_BOARD_MURATA_1XK_M21XK M.2 module
WIFI_IW416_BOARD_MURATA_1XK_ONBOARDSpecial mounting option for some OEM/uCOM boards to have an onboard 1XK chip
WIFI_88W8987_BOARD_MURATA_1ZM_M21ZM M.2 module
WIFI_88W8801_BOARD_MURATA_2DS_USD2DS M.2 module in uSD-to-M.2 adapter in uSD socket
WIFI_IW416_BOARD_MURATA_1XK_USD1XK M.2 module in uSD-to-M.2 adapter in uSD socket
WIFI_88W8987_BOARD_MURATA_1ZM_USD1ZM M.2 module in uSD-to-M.2 adapter in uSD socket

Configure The Example​

Some Wi-Fi examples (like the wifi_cli example) don’t need any configuration as everything is handled at runtime (searching, adding networks, connecting etc.)

However, most of the Wi-Fi examples have settings that must be configured before compiling for the program to connect to your network or to use the correct channel etc.

The settings are typically found in the project’s main file, like this for the wifi_setup example:

Configure Project

These are some common configuration options:

DefineComment
AP_SSIDSSID of the Access Point that the example will create
AP_PASSPHRASEPassword for the Access Point
PING_ADDRAddress that the example will attempt to ping
WIFI_SSIDSSID of the network to connect to
WIFI_PASSWORDPassword

Compile and Run/Debug​

To download and run the application, perform these steps:

  1. Click Build in the Quickstart Panel
    Build Project
  2. The program builds without errors
  3. Connect a debug probe (LPC-Link2, ULINK2, J-LINK, MCU-Link etc.) to the iMX RT Developer’s Kit and to your PC. See chapter Debug Interface for details how to connect the debug probe
  4. Open the terminal application on the PC, such as TeraTerm or PuTTY, and connect to the debug serial port number. Configure the terminal with 115200 baud, 8N1. You can alter the baud rate be searching for the reference BOARD_DEBUG_UART_BAUDRATE variable in file: board.h
  5. Click the "Debug" button in the Quickstart Panel to download the application to the target.
    Debug Project
  6. The application is then downloaded to the target and automatically runs to the main() function.
  7. Run the code by clicking the "Resume" button to start the application.
    Run Project

Explanation of one example – wifi_cli​

This will describe how to use the wifi_cli example. For other examples, see the table in Supported Examples.

The wifi_cli example presents a shell in the terminal in which you can enter commands. At the start it shows all the available commands (same as running the help command):

help
wlan-version
wlan-mac
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-start-network <profile_name>
wlan-stop-network
wlan-disconnect
wlan-stat
wlan-info
wlan-address
wlan-get-uap-channel
wlan-get-uap-sta-list
wlan-ieee-ps <0/1>
wlan-deep-sleep-ps <0/1>
wlan-host-sleep <0/1> wowlan_test <0/1>
wlan-send-hostcmd
wlan-set-uap-bandwidth <1/2> 1:20 MHz 2:40MHz
ping [-s <packet_size>] [-c <packet_count>] [-W <timeout in sec>] <ip_address>
iperf [-s|-c <host>|-a|-h] [options]
dhcp-stat

It is possible to get more information about a command by typing the command followed by help:

wlan-add help
Usage:
For Station interface
  For DHCP IP Address assignment:
    wlan-add <profile_name> ssid <ssid> [wpa2 <secret>]
      If using WPA2 security, set the PMF configuration if required.
    wlan-add <profile_name> ssid <ssid> [wpa3 sae <secret> mfpc <1> mfpr <0/1>]
      If using WPA3 SAE security, always set the PMF configuration.
  For static IP address assignment:
    wlan-add <profile_name> ssid <ssid>
    ip:<ip_addr>,<gateway_ip>,<netmask>
    [bssid <bssid>] [channel <channel number>]
    [wpa2 <secret>]
For Micro-AP interface
    wlan-add <profile_name> ssid <ssid>
    ip:<ip_addr>,<gateway_ip>,<netmask>
    role uap [bssid <bssid>]
    [channel <channelnumber>]
    [wpa2 <secret>] [wpa3 sae <secret>]
    [mfpc <0/1>] [mfpr <0/1>]
Error: invalid number of arguments

To scan for Wi-Fi networks, run the wlan-scan command:

wlan-scan
Scan scheduled...

# 10 networks found:
60:38:E0:9D:B6:F7  "VSG1_5G" Infra
        channel: 100
        rssi: -51 dBm
        security: WPA/WPA2 Mixed
        WMM: YES
60:38:E0:9D:B6:F8  "VSG1" Infra
        channel: 11
        rssi: -60 dBm
        security: WPA/WPA2 Mixed
        WMM: YES
3C:7C:3F:45:7F:8C  (hidden) Infra
        channel: 100
        rssi: -75 dBm
        security: WPA2
        WMM: YES
...

It will show the networks and if/how they are protected.

Before you can connect to a network it must be configured which is done with the wlan-add command. Assuming you want to connect to the VSG1 network with password test1234 and give it the alias "hello":

wlan-add hello ssid VSG1_5G wpa2 test1234
Added "hello"
wlan-list
1 network:
"hello"
        SSID: VSG1_5G
        BSSID: 00:00:00:00:00:00
        channel: (Auto)
        role: Infra
        security: WPA2

        IPv6 Addresses

Now that there is a network, connect to it.

wlan-connect hello
Connecting to network...
Use 'wlan-stat' for current connection status.

# ========================================
app_cb: WLAN: received event 1
========================================
app_cb: WLAN: authenticated to network
========================================
app_cb: WLAN: received event 0
========================================
app_cb: WLAN: connected to network
Connected to following BSS:
SSID = [VSG1_5G]
IPv4 Address: [10.158.186.137]
IPv6 Address: Link-Local : FE80::2E4C:C6FF:FEF4:D3D0 (Preferred)

To show some information about the network that you are connected to, use wlan-stat, wlan-info or wlan-address:

wlan-stat
Station connected (Active)
uAP stopped
wlan-info
Station connected to:
"hello"
        SSID: VSG1_5G
        BSSID: 60:38:E0:9D:B6:F7
        channel: 100
        role: Infra
        security: WPA2

        IPv4 Address
        address: DHCP
                IP:             10.158.186.137
                gateway:        10.158.186.69
                netmask:        255.255.255.0
                dns1:           10.158.186.69
                dns2:           0.0.0.0

        IPv6 Addresses
        Link-Local   :  FE80::2E4C:C6FF:FEF4:D3D0 (Preferred)

uAP not started
wlan-address
        IPv4 Address
        address: DHCP
                IP:             10.158.186.137
                gateway:        10.158.186.69
                netmask:        255.255.255.0
                dns1:           10.158.186.69
                dns2:           0.0.0.0

        IPv6 Addresses
        Link-Local   :  FE80::2E4C:C6FF:FEF4:D3D0 (Preferred)

To test that it really is connected to a network, try using ping.

ping help
Incorrect usage
Usage:
        ping [-s <packet_size>] [-c <packet_count>] [-W <timeout in sec>] <ip_address>
Default values:
        packet_size: 56
        packet_count: 10
        timeout: 2 sec
ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data
64 bytes from 8.8.8.8: icmp_req=1 ttl=113 time=94 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=113 time=211 ms

--- 10.158.186.137 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Ping is a great way to test if the hardware is connected to the network, or not, but to really test the network interface it is better to use a program like iperf. Iperf requires both a server and a client to run the tests. The wifi_cli program can act as client with the server software either installed on a computer on the local network (https://iperf.fr/iperf-download.php) or one of the online servers can be used (https://iperf.fr/iperf-servers.php). It is also possible to run wifi_cli in server mode and the client on a PC in the same local network.

note

Make sure to select the latest version of the 2.0.* branch (2.0.9 seems to be the last released version) when downloading the iperf software from https://iperf.fr/iperf-download.php. Version >=3.0 is not supported by this example, and it will not work as iperf and iperf3 are completely different protocols.

The iperf command in wifi_cli has several options:

iperf help
Incorrect usage
Usage:
        iperf [-s|-c <host>|-a] [options]
        iperf [-h]

        Client/Server:
           -u             use UDP rather than TCP
           -B    <host>   bind to <host> (including multicast address)
           -V             Set the domain to IPv6 (send packets over IPv6)
           -a             abort ongoing iperf session
        Server specific:
           -s             run in server mode
        Client specific:
           -c    <host>   run in client mode, connecting to <host>
           -d             Do a bidirectional test simultaneously
           -r             Do a bidirectional test individually
           -t    #        time in seconds to transmit for (default 10 secs)
           -b    #        for UDP, bandwidth to send at in Mbps, default 100Mbps without the parameter
Error: argument 1 is invalid

Use Case 1 – Server on target and client on local PC​

Start the server on target with the following command:

iperf -s
IPERF initialization successful

Use the wlan-info or wlan-address commands as shown earlier to find the IP number of the server, in this example 10.158.186.114. Run the following command on the PC (the program exists for most common operating systems but is shown here for Windows):

C:\temp> iperf -c 10.158.186.114 -i 2 -t 20 -P 4

The parameters specify the IP number of the iMX RT board, that a report should be printed every 2 seconds, that the test will run for 20 seconds and use 4 threads/connections.

After the test completes it will print something like this on the PC:

[SUM]  0.0000-20.5761 sec  83.4 MBytes   34.0 Mbits/sec

The log from the iMX RT will show something like this for each of the 4 connections after the test completes:

-------------------------------------------------
 TCP_DONE_SERVER (RX)
 Local address : 10.158.186.137  Port 5001
 Remote address : 10.158.186.131  Port 60430
 Bytes Transferred 17528456
 Duration (ms) 21028
 Bandwidth (Mbitpsec) 6
note

The information shown on the target is not entirely correct. It shows the correct number of bytes transferred but does not calculate the time correctly. As seen above the time is 21028ms for a test that takes 20 seconds. The wifi_cli code measures time from the connection is established and not from the first byte is sent over the connection. Depending on the PC software it may take extra time (in this case roughly 1 second) to set up the test and this should not be included in the test result, but it is. When checking the result look at the PC instead of the target (i.e., the iMX RT1176). There will also be rounding errors as the wifi_cli program shows Mbits/sec with no decimals.

Press ENTER to return to the main menu to run this or another test again.

Use Case 2 - Client on target and server on local PC​

Before running this test the PC must be running the server:

C:\temp> iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------

Assuming the IP number of the PC is 10.158.186.131, run the tests with this command.

iperf -c 10.158.186.131 -t 20
Abort ongoing IPERF session

IPERF initialization successful

After the test completes (it takes 20 seconds) it will print the something like this:

# -------------------------------------------------
TCP_DONE_CLIENT (TX)
 Local address : 10.158.186.137  Port 49153
 Remote address : 10.158.186.131  Port 5001
 Bytes Transferred 107637794
 Duration (ms) 20000
 Bandwidth (Mbitpsec) 43

Press ENTER to return to the main menu to run this or another test again.

There are other modes (but those are left as exercises for the reader):

  • bidirectional simultaneously
  • bidirectional individual
  • UDP instead of TCP

Explanation of one example – wireless_uart​

This will describe how to use the wireless_uart example. For other examples, see the table in Supported Examples.

The wireless_uart example emulates an UART over BLE. The example can run as either central or peripheral and can be used either together with another iMX RT Developer’s Kit or with the NXP IoT Toolbox app (https://apps.apple.com/se/app/iot-toolbox/id1362450908 or https://play.google.com/store/apps/details?id=com.freescale.kinetisbletoolbox).

Use Case 1 – Two iMX RT Developer’s Kits​

This will be showcased with

  • One iMX RT1062 kit with an 1XK M.2 module (referred to as A below) and
  • One iMX RT1176 kit with an 1ZM M.2 module (referred to as B below) and

Start the A board

Built for WIFI_IW416_BOARD_MURATA_1XK_M2
BLE Wireless Uart demo start...
Bluetooth initialized
Advertising successfully started

Now press the WAKEUP (SW4) button to enter central mode where it will start the search for a peripheral. During the search it will spam prints like these.

Scanning successfully started
[DEVICE]: 50:61:F6:8D:E7:D0 (public), AD evt type 0, AD data len 29, RSSI -94
[DEVICE]: ED:ED:D4:87:8B:53 (random), AD evt type 0, AD data len 31, RSSI -91
[DEVICE]: ED:ED:D4:87:8B:53 (random), AD evt type 4, AD data len 20, RSSI -90
...

Now power on the B board and watch as they connect.

B:

Built for WIFI_88W8987_BOARD_MURATA_1ZM_M2
BLE Wireless Uart demo start...
Bluetooth initialized
Advertising successfully started
Connected to 2C:4C:C6:F4:D3:D1 (public)
Security changed: 2C:4C:C6:F4:D3:D1 (public) level 2 (error 0)
GATT MTU exchanged: 65
[ATTRIBUTE] handle 10
[ATTRIBUTE] handle 11

A:

Connected to 2C:4C:C6:F4:9A:74 (public)
GATT MTU exchanged: 65
Security changed: 2C:4C:C6:F4:9A:74 (public) level 2 (error 0)
[ATTRIBUTE] handle 10
[ATTRIBUTE] handle 11

Now that they are connected, what’s typed in one terminal appears on the other. Here B sends "hello" followed by A typing "goodbye1234", B typing "5678".

A:

Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):h
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):e
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):l
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):l
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):o
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):5
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):6
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):7
Data received from 2C:4C:C6:F4:9A:74 (public)(length 1):8

B:

Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):g
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):o
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):o
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):d
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):b
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):y
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):e
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):1
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):2
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):3
Data received from 2C:4C:C6:F4:D3:D1 (public)(length 1):4

If a message is pasted into the terminal instead of typed it will appear as a longer message on the receiver side instead of single characters. Here "Hello World" is sent from A.

B:

Data received from 2C:4C:C6:F4:D3:D1 (public)(length 11):Hello World

The boards will disconnect after a while and to reconnect press the WAKEUP (SW4) button on (A) again.

Note that it is possible to switch A and B so that B is the one doing the searching. On the uCOM Carrier Board used by B, use the WAKEUP (SW5) button.

Use Case 2 – iMX RT Developer’s Kit and Android Phone​

This will be showcased with

  • One iMX RT1062 kit with an 1XK M.2 module (referred to as A below) and
  • One Android phone with the IoT Toolbox app installed

Start the A board

A:

Built for WIFI_IW416_BOARD_MURATA_1XK_M2
BLE Wireless Uart demo start...
Bluetooth initialized
Advertising successfully started

Start the IoT Toolbox app on the phone and then click the Wireless UART which will start to scan for nearby wireless UARTs and list them.

Overview Overview

Click on the found wireless UART to open up a new view:

Overview

If the phone asks to connect to the device, accept it. If asked for a password/passphrase/pin code look in the terminal for (A):

Passkey for 4D:49:95:86:0C:7B (random): 304696

After entering it on the phone the two-way terminal should now work as it did between two kits.

Overview

The IoT Toolbox application can be used in combination with several of the other examples in the SDK. For more information about that, see the UM11442-NXP-Wi-Fi-and-Bluetooth-Demo-Applications-for-i.MX-RT-platforms-User-Guide.pdf that comes with the SDK.

Troubleshooting​

Some things to check if the application is not working as expected:

Program not starting after being flashed​

This can happen if the flash operation failed.

wlan-info
Station connected to:
"hello"
        SSID: VSG1_5G
        BSSID: 60:38:E0:9D:B6:F7
        channel: 100
        role: Infra
        security: WPA2

        IPv4 Address
        address: DHCP
                IP:             10.158.186.137
                gateway:        10.158.186.69
                netmask:        255.255.255.0
                dns1:           10.158.186.69
                dns2:           0.0.0.0

        IPv6 Addresses
        Link-Local   :  FE80::2E4C:C6FF:FEF4:D3D0 (Preferred)

uAP not started

For the tests to work the "Station connected to" message must be shown and the board must have received an IP address from DHCP. If one of those is missing check the parameters that you passed to wlan-add again.

Cannot find M.2 module​

A successful detection of the M.2 module looks like this when the program starts:

Built for WIFI_IW416_BOARD_MURATA_1XK_M2
========================================
wifi cli demo
========================================
Initialize CLI
========================================
Initialize WLAN Driver
========================================
MAC Address: 2C:4C:C6:F4:D3:D0
========================================
app_cb: WLAN: received event 11
========================================
app_cb: WLAN initialized
========================================
WLAN CLIs are initialized
========================================
CLIs Available:
========================================

If the M.2 module cannot be detected, check that the module is correctly inserted. Make sure that the project has been configured for the correct M.2 module (see Step #3).

Firewalls​

As with all network tests make sure that the firewall on the test PC is not stopping the traffic from the iMX RT board. This is probably not a problem when running the iperf client on the PC as it is outgoing traffic, however when running the iperf server it expects incoming connections and those may be blocked by a firewall.

Throughput​

The exact speed that can be achieved during testing is heavily dependent on the test environment including but not limited to:

  • Use of onboard antenna vs external antenna
  • Wireless router performance
  • Distance between iMX RT and router
  • PC that is running the software
  • Usage of the 2.4GHz/5GHz band by others

Debug Interface​

It is strongly recommended using a debug/JTAG probe during program development. The low-cost LPC-Link2 or MCU-Link are excellent choices. Keil ULINK2 and ULINKplus, as well as Segger J-LINK, are also excellent debug probes.

There are two debug interface connectors available on the iMX OEM Carrier board:

  • J10 – this is a Cortex Debug connector. It is a 2x5 pos, 50 mil pitch connector without a shroud. Be careful when inserting the debug probe cable. Position 1 is in specifically marked on the PCB silkscreen. It is located in the lower right corner, see Figure 2 below. The connector supports both the SWD and JTAG interfaces.

  • J11 – this is an ARM Debug connector. It is a 2x10 pos, 100 mil pitch connector with shroud.

Both connectors are defined and supports both the SWD and JTAG type of debug interfaces.

Note that in order to enable the JTAG/SWD interface on the i.MX RT, JP5 shall not be shorted/inserted.

Debug Interfaces on rev B1 iMX OEM Carrier board

note

Note that due to the powering sequencing requirements on the i.MX RT family, the debug probe I/O voltage MUST follow the i.MX RT I/O voltage.

The debug adapter must not drive any output higher than the Vcc/Vref voltage (and if that voltage is zero, then the debug adapter must not drive any output signal). Vcc/Vref is pin 1 on both J10 and J11.

Make sure the debug probe does not have a fixed output voltage, but rather follow Vcc/Vref. If using LPC-Link2 as debug interface, make sure there is NO jumper inserted in JP2 on the LPC-Link2.

J-LINK/J-TRACE Support​

This chapter describes the steps necessary to get the Segger J-TRACE to work with NXP MCUXpresso and Keil uVision. The same instructions are likely to work for Segger J-LINK as well, but it has not been verified.

Install J-LINK Software

The software for the J-TRACE/J-LINK is installed in a central location (i.e. outside of the IDEs). The latest version (v6.60d) as of January 2020 has support for the iMX RT1062 but needs a configuration change to support the EcoXiP flash memory:

  1. Download and install the latest version of Segger's software: https://www.segger.com/downloads/jlink/JLink_Windows.exe (v6.42, or later). The rest of the steps will use <jdir> as abbreviation for the folder that the driver was installed in, for example c:\Program Files (x86)\SEGGER\JLink_V642b\

  2. Open <jdir>\JLinkDevices.xml

  3. Search for MCIMXRT1062 to find <Device>

  4. In each of the <Device> entries, change
    Loader="Devices/NXP/iMXRT106x/NXP_iMXRT106x_HyperFlash.elf" to Loader="Devices/NXP/iMXRT106x/NXP_iMXRT106x_QSPI.elf"

    Change the MaxSize="0x04000000" to MaxSize="0x00400000" and then save the file.

Debug Troubleshooting​

In some cases, the IDE complains about not being able to connect to the target. This is most likely because the program already running on the target is interfering. The solution is to put the hardware in ISP mode before starting the flash/debug operation in the IDE. To do this:

  1. Push and hold down the ISP enable button
  2. Press the Reset button
  3. Release the Reset button
  4. Wait 1 seconds
  5. Release the ISP enable button

If the LPC-Link2 debugger is used then there are some additional things to note:

  1. Make sure that the J2 jumper on the LPC-Link2 is not inserted. If the jumper is inserted/closed then the target will be powered by the LPC-Link2 which might be too much power for the USB port that the LPC-Link2 is connected to.
  2. If the LPC-Link2 is not found by the IDE and you are working on a laptop then try using a powered USB hub instead.
  3. The troubleshooting section in this forum post has a couple of additional things to try: https://community.nxp.com/thread/388964
  4. There is a Using and troubleshooting LPC-Link2 in the Appendix - Additional Hints and Tips of the User Guide for MCUXpresso IDE. The location of the document is c:\nxp\MCUXpressoIDE_11.5.0_7232\MCUXpresso_IDE_User_Guide.pdf if the IDE was installed with the default settings.