/
Using USB Flash with the USB High Speed Interfaces on the i.MX RT10XX

Using USB Flash with the USB High Speed Interfaces on the i.MX RT10XX

Owned by Natalia Sofronova
Last updated: Jan 15, 2025 by Alexander Sanochkin
6 min read

This application note explains how to use a USB Flash device with the USB High Speed (HS) interfaces of the i.MX RT10XX 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 RT1050 EVKB board or NXP i.MX RT1060 EVKB.

This demo assumes that a Micro-B to USB 2.0 A Female cable is plugged into the USB1 J9 interface connector on the NXP i.MX RT1050 EVKB board or into the USB1 J47 interface connector on the NXP i.MX RT1060 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.

2. Logging Data onto USB Flash

On power-up or reset, U-Boot loads the Linux and Device Tree images from the SD Card to the SDRAM and passes control to the kernel entry point:

U-Boot SPL 2024.04 (Dec 19 2024 - 08:16:46 +0000) Trying to boot from MMC1 U-Boot 2024.04 (Dec 24 2024 - 06:30:18 +0000) DRAM: 32 MiB Core: 79 devices, 18 uclasses, devicetree: separate MMC: FSL_SDHC: 0 Loading Environment from MMC... OK In: serial@40184000 Out: serial@40184000 Err: serial@40184000 Net: eth0: ethernet@402d8000 Hit any key to stop autoboot: 0 8579371 bytes read in 5857 ms (1.4 MiB/s) ## Booting kernel from Legacy Image at 80007fc0 ... Image Name: Linux-6.6.36 Image Type: ARM Linux Multi-File Image (uncompressed) Data Size: 8579307 Bytes = 8.2 MiB Load Address: 80008000 Entry Point: 80008001 Contents: Image 0: 8567460 Bytes = 8.2 MiB Image 1: 11835 Bytes = 11.6 KiB Verifying Checksum ... OK ## Flattened Device Tree from multi component Image at 80007FC0 Booting using the fdt at 0x80833ab0 Working FDT set to 80833ab0 Loading Multi-File Image to 80008000 Loading Device Tree to 81dfa000, end 81dffe3a ... OK Working FDT set to 81dfa000 Starting kernel ... Booting Linux on physical CPU 0x0 Linux version 6.6.36 (sasha@workbench.emcraft.com) (arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release), GNU ld (GNU Arm Embedded Toolchain 10.3-2021.10) 2.36.1.20210621) #2 PREEMPT Tue Dec 24 06:42:32 UTC 2024 CPU: ARMv7-M [411fc271] revision 1 (ARMv7M), cr=00000000 CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: NXP IMXRT1060-evk board Reserved memory: created DMA memory pool at 0x81e00000, size 1 MiB OF: reserved mem: initialized node dmapool@81e00000, compatible id shared-dma-pool OF: reserved mem: 0x81e00000..0x81efffff (1024 KiB) nomap non-reusable dmapool@81e00000 OF: reserved mem: 0x81f00000..0x81ffffff (1024 KiB) nomap non-reusable memory@81f00000 ... Freeing unused kernel image (initmem) memory: 3256K This architecture does not have kernel memory protection. Run /init as init process [51] Jan 01 01:02:41 Running in background / # Micrel KSZ8081 or KSZ8091 402d8000.ethernet-1:02: attached PHY driver (mii_bus:phy_addr=402d8000.ethernet-1:02, irq=POLL) fec 402d8000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

2.1. USB OTG 1 Controller (USB OTG)

Connect just a Micro-B to USB 2.0 A Female cable to the USB1 J9 connector on the NXP i.MX RT1050 EVKB board or to the USB1 J47 interface connector on the NXP i.MX RT1060 EVKB board .

Connect USB Flash device to the cable. Observe it is detected and configured:

usb 1-1: new high-speed USB device number 2 using ci_hdrc usb-storage 1-1:1.0: USB Mass Storage device detected scsi host0: usb-storage 1-1:1.0 scsi 0:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 8228864 512-byte logical blocks: (4.21 GB/3.92 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk

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 4GBytes disk partitioned to have a single empty FAT32 partition:

/ # fdisk -l /dev/sda Disk /dev/sda: 4018 MB, 4213178368 bytes, 8228864 sectors 512 cylinders, 255 heads, 63 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/sda1 * 0,32,33 511,254,63 2048 8228863 8226816 4017M c Win95 FAT32 (LBA) Partition 1 has different physical/logical end: phys=(511,254,63) logical=(512,56,56)

Let's mount the FAT32 file system. As expected, it is empty at this point:

/ # mount /dev/sda1 /mnt/usbflash / # ls -l /mnt/usbflash/ drwxr-xr-x 2 root root 4096 May 25 2023 System Volume Information / #

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

Having let the "data harvesting" run for a few seconds, let's interrupt it (by pressing CTRL-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 / #

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.

usb 2-1: USB disconnect, device number 2 ci_hdrc ci_hdrc.0: remove, state 1 usb usb2: USB disconnect, device number 1 ci_hdrc ci_hdrc.0: USB bus 2 deregistered

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:

ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb 1-1: new high-speed USB device number 2 using ci_hdrc usb-storage 1-1:1.0: USB Mass Storage device detected scsi host0: usb-storage 1-1:1.0 scsi 0:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 8228864 512-byte logical blocks: (4.21 GB/3.92 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk / # mount /dev/sda1 /mnt/usbflash / # ls -l /mnt/usbflash drwxr-xr-x 2 root root 4096 May 25 2023 System Volume Information -rwxr-xr-x 1 root root 232 Jan 1 1980 data.log / # umount /mnt/usbflash

3. 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 to 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):

/ # mount -o sync /dev/sda1 /mnt/usbflash / # mount rootfs on / type rootfs (rw) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,relatime,mode=777) tmpfs on /run type tmpfs (rw,nosuid,relatime,mode=777) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) /dev/sda1 on /mnt/usbflash type vfat (rw,sync,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

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.

Related content