This application note explains how to use a USB Flash device with the USB High Speed (HS) interfaces of the i.MX RT1170 microcontroller running uCLinux. The chip has Universal Serial Bus 2.0 Integrated PHY which contains two integrated USB 2.0 PHY macrocells capable of connecting to USB host/device systems at the USB low-, full-, and high-speed rates.

1. Hardware Platform

The hardware platform is the NXP i.MX RT1170 EVK/EVKB board or Avnet MaaXBoard-RT.

This demo assumes that a Micro-B to USB 2.0 A Female cable is plugged into the USB1 interface connector on the NXP i.MX RT1170 EVK/EVKB board and that a pre-formatted USB Flash disk with an FAT32 partition is plugged into the USB 2.0 A Female connector of the above USB cable.

For the Avnet MaaXBoard-RT board, the USB Flash disk should be plugged directly into the J18 USB-A connector.

2. Accessing USB Flash in U-Boot

1. Boot the target board to U-Boot by pressing any key after reset or power on. The boot log below is from the NXP EVK board; MaaxBoard-RT output will differ (NOR flash boot instead of MMC):

   U-Boot SPL 2025.04-gab4b0ed9ca1f (Jan 21 2026 - 13:25:13 +0300) Trying to boot from MMC1 U-Boot 2025.04-gab4b0ed9ca1f (Jan 21 2026 - 13:25:13 +0300) Model: NXP imxrt1170-evk board DRAM: 64 MiB Core: 77 devices, 16 uclasses, devicetree: separate MMC: FSL_SDHC: 0 Loading Environment from MMC... Reading from MMC(0)... OK In: serial@4007c000 Out: serial@4007c000 Err: serial@4007c000 Net: eth0: ethernet@40424000 Hit any key to stop autoboot: 0 =>

2. Scan USB controller by running the usb scan command:

   => usb start starting USB... Bus usb1@40430000: USB EHCI 1.00 Bus usb2@4042c000: USB EHCI 1.00 scanning bus usb1@40430000 for devices... 2 USB Device(s) found scanning bus usb2@4042c000 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found =>

3. Show details of the USB storage device:

   => usb storage Device 0: Vendor: SanDisk Rev: 1.00 Prod: Cruzer Blade Type: Removable Hard Disk Capacity: 14664.0 MB = 14.3 GB (30031872 x 512) =>

4. List files from the USB storage device:

   => fatls usb 0 System Volume Information/ 0 file(s), 1 dir(s)

5. Load the binary file rootfs.uImage from a TFTP server on the network. Make sure the Ethernet cable is connected and a TFTP server with the file is available:

   => dhcp ${loadaddr} rootfs.uImage BOOTP broadcast 1 DHCP client bound to address 192.168.0.105 (5048 ms) Using ethernet@40424000 device TFTP from server 192.168.0.1; our IP address is 192.168.0.105 Filename 'rootfs.uImage'. Load address: 0x80007fc0 Loading: ################################################################# 4.2 MiB/s done Bytes transferred = 10433180 (9f329c hex)

6. Write the file rootfs.uImage to the USB storage device:

   => fatwrite usb 0 ${loadaddr} rootfs.uImage ${filesize} 10433180 bytes written in 394 ms (25.3 MiB/s) =>

7. Load the rootfs.uImage file from the USB storage device to a different memory address:

   => fatload usb 0 0x81000000 rootfs.uImage 10433180 bytes read in 231 ms (43.1 MiB/s)

8. Make sure that the data in 2 areas are identical:

   => cmp.b ${loadaddr} 0x81000000 ${filesize} Total of 10433180 byte(s) were the same =>

3. Accessing USB Flash in Linux

On power-up or reset, U-Boot loads the Linux and Device Tree images to the SDRAM and passes control to the kernel entry point. The kernel proceeds to boot up, initializing the configured I/O interfaces and sub-systems. The boot log below is from the NXP EVK board; MaaxBoard-RT output will differ:

3.1. USB Host Controller

1. Connect USB Flash device to the board as described in 1. Hardware Platform . Observe it is detected and configured:

   scsi 0:0:0:0: Direct-Access SanDisk Cruzer Blade 1.00 PQ: 0 ANSI: 6 sd 0:0:0:0: [sda] 30031872 512-byte logical blocks: (15.4 GB/14.3 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk

2. At this point, the USB Flash is accessible as a disk. The following command is used to examine the disk, which is detected as a disk partitioned to have a single FAT32 partition:

   / # fdisk -l /dev/sda Disk /dev/sda: 14 GB, 15376318464 bytes, 30031872 sectors 14664 cylinders, 64 heads, 32 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/sda1 1,0,1 31,63,32 2048 65535 63488 31.0M 83 Linux / #

3. Let's mount the FAT32 file system. As expected, it contains only rootfs.uImages from previous test at this point:

   / # mount /dev/sda1 /mnt/usbflash / # ls -l /mnt/usbflash/ drwxr-xr-x 2 root root 8192 Jan 28 2026 System Volume Information -rwxr-xr-x 1 root root 10433180 Jan 1 2000 rootfs.uImage / #

4. Let's "harvest" some data and store what is collected into a file on the USB Flash disk. In this demo, we emulate a data stream by taking a snapshot of the system time each second:

   ~ # while true; do date >> /mnt/usbflash/data.log; sleep 1; done

5. Having let the "data harvesting" run for a few seconds, let's interrupt it (by pressing ^-C) and take a look at what data we have collected:

   / # cat /mnt/usbflash/data.log Thu Jan 1 00:11:27 UTC 1970 Thu Jan 1 00:11:28 UTC 1970 Thu Jan 1 00:11:29 UTC 1970 Thu Jan 1 00:11:30 UTC 1970 Thu Jan 1 00:11:31 UTC 1970 Thu Jan 1 00:11:32 UTC 1970 Thu Jan 1 00:11:33 UTC 1970 Thu Jan 1 00:11:34 UTC 1970 Thu Jan 1 00:11:35 UTC 1970 Thu Jan 1 00:11:36 UTC 1970 / #

6. Now, let's unmount the USB Flash and unplug the device from the USB cable:

   / # umount /mnt/usbflash

At this point, the USB Flash device can be taken to a PC for further data processing. Just plug in the USB Flash into a USB port on your PC and the PC software will be able to mount the device as a FAT32 file system.

Note that the format of Windows and Unix text files differs slightly. In Windows, lines end with both the line feed and carriage return ASCII characters, but Unix uses only a line feed. As a consequence, some Windows applications will not show the line breaks in Unix-format files. Assuming that data is stored in a text file (vs a binary file) and Windows is a data processing host, Linux data harvesting applications should take care of the difference by adding a carriage return character to data logs.

Note further that you can hot plug your USB Flash device on the running system at any time:

3.2. Data Synchronization Considerations

It is important to understand that VFAT supports write-back in Linux, which means that file changes do not go to the physical media straight away and instead are cached in memory and go to the Flash at a later time. This helps to reduce amount of I/O to the physical Flash, resulting in a better performance overall.

The write-back creates a certain issue for embedded devices however. If the power to the device is shut down unexpectedly, or the USB Flash is unplugged without a proper unmount or sync, some of latest file changes may be lost.

As it is typical with Linux, the issue can be handled in many ways. Data synchronization can be ensured on a per-file, per-subtree, per-filesystem or system-wide basis. Synchronization can be transparent for the user or may require issuing an explicit API call or a shell command.

The most obvious solution is to mount the file system in synchronous mode (note the -o sync parameter in the call below):

When the file system is mounted for synchronous operation, Linux guarantees that data is written to the physical media before any write()returns to a calling application. The tradeoff is that written data is no longer cached in memory, which reduces the write performance substantially.