SEGGER emUSB-Host MSC: USB Mass Storage File Transfer for Indian Medical and Industrial Devices

“Put a USB port on the front panel so the clinician can plug in a pen drive and export the logs” is a feature request that sounds trivial, and then swallows six months of engineering when a team tries to build the stack themselves. A production USB host with Mass Storage Class support is a multi-layer problem: the host controller driver, the USB stack, the class driver, the SCSI command set, the filesystem, the partition table, the power and hot-plug logic, and the recovery story when someone yanks the stick mid-write. SEGGER emUSB-Host, the commercial USB host stack from SEGGER Microcontroller GmbH, handles all of that in one integrated product, and pairs cleanly with SEGGER emFile for the filesystem side. At GSAS, as the authorised SEGGER engineering partner for India, we integrate emUSB-Host MSC on customer silicon across medical device OEMs, industrial HMI builders and test-equipment programmes. This post is a practical walkthrough of what the stack does, why it is the right call for Indian commercial programmes, and how it lands on the silicon Indian OEMs actually ship.

What emUSB-Host MSC actually is

emUSB-Host is a modular host stack. The core handles USB enumeration, device descriptors, endpoint configuration, transfer scheduling and the common USB host state machine. On top of the core, SEGGER ships class drivers for the classes embedded devices actually need: HID for keyboards and barcode scanners, CDC for serial-over-USB adapters, MSC for mass storage, a printer class, and an audio class. The MSC class driver is the one that matters when the product requirement is “ingest or emit files via a plugged-in USB stick”, and it is the focus of this post.

The MSC driver implements the Bulk-Only Transport protocol, the dominant MSC transport in the wild, which wraps SCSI commands inside USB bulk transfers. When a stick is plugged in, emUSB-Host enumerates it, reads its device descriptor, identifies it as MSC, and then runs the standard SCSI inquiry, read-capacity and test-unit-ready commands to bring the device online. From the application’s point of view, the USB stick then looks like a block device, and is mounted by emFile as a FAT or exFAT volume. The application opens files, reads, writes, and closes them with the same API it would use for an on-board SD card. There is no custom SCSI handling, no hand-rolled endpoint parser, and no filesystem tax beyond the normal emFile calls.

Why a commercial host stack beats open-source for production

There are open-source USB host implementations, and for a hobby project they are fine. For an Indian commercial programme that will ship in volume, carry a medical or industrial compliance story, and live in the field for years, they run into predictable problems.

The first is coverage. MSC sticks in the real world are not uniform. They come from dozens of manufacturers, with different firmware revisions, different quirks, different maximum packet sizes, different responses to corner-case SCSI commands, and different behaviour when they are plugged in while the host is already busy. A production host stack is tested against a large matrix of real sticks over years of field use, and the edge cases are documented and fixed upstream. TinyUSB’s host side, to take the most common open-source option, is explicitly not positioned as a production-grade MSC host, it is a reference, it is hobbyist-friendly, and the project’s own documentation is honest about that. Rolling your own stack from scratch is a multi-month programme risk that has to be repeated every time a new stick quirk shows up in production.

The second is support. When a customer in the field calls your support line because “this one brand of pen drive does not work”, you need an answer within days, not weeks. SEGGER ships the source, has engineers who have been writing USB host code for decades, and responds through a commercial support channel. For a medical device under IEC 62304 or an industrial programme with a signed-off compliance evidence package, the provenance, traceability and change history of the stack matter for the audit, and a commercial product with a named supplier gives you all of that out of the box.

The third is the filesystem integration. emUSB-Host plus emFile is a tested pairing: the block device interface the MSC class driver exposes is the same interface emFile’s storage layer consumes, so mounting a stick is a single call. The filesystem buffer sizing, alignment and cache behaviour are pre-tuned by SEGGER to work well over the bulk-endpoint transport. There is no impedance mismatch between layers.

The enumeration and mount flow, end to end

When a clinician or a plant engineer plugs a stick into your device, here is what happens under the cover. emUSB-Host’s host controller driver sees the VBUS-connect event and starts the bus reset. Once the device replies, the stack issues a GetDescriptor request for the device descriptor, reads the configuration descriptor, identifies the MSC interface class (0x08), and sets the configuration. It then instantiates the MSC class driver for that interface.

The MSC driver issues a SCSI inquiry. The response tells it the vendor and product identifiers, which it passes up to the application for logging. It then sends a ReadCapacity command to learn the block count and block size, usually 512 bytes for traditional sticks and 4096 bytes for modern large-capacity ones. It runs TestUnitReady until the device reports ready (some sticks need a few tries to spin up their internal flash translation layer). At this point the stick is a block device.

The application asks emFile to mount the block device as a FAT or exFAT volume. emFile reads the partition table from LBA 0. It walks the MBR or GPT partition entries, picks the first partition of a supported type, and mounts the filesystem on it. If the stick is multi-LUN, rare but not unheard of on card readers and some enterprise sticks, emUSB-Host’s MSC driver exposes each LUN as a separate block device and the application can choose which one to mount. From the clinician’s point of view, the workflow is plug in, wait a second, press “export”, and the export completes without any visible plumbing.

On unplug, emUSB-Host sees the disconnect event, notifies the MSC class driver, which notifies the application, which asks emFile to unmount cleanly. If the application is in the middle of writing a file and the clinician yanked the stick, the filesystem ends up in whatever state the stick was last flushed to, which is precisely the reason we turn on emFile’s Journaling add-on for any write-back path. The combination of emUSB-Host’s disconnect handling plus emFile’s Journaling means that a rudely-unplugged stick, on its next mount somewhere else, still presents a consistent filesystem. The file being written might be truncated, but the filesystem itself is not corrupt.

Hot-plug, power, over-current and the real-world details

USB host design on an embedded device is not complete without the hardware-side plumbing. VBUS has to be switched by the host, most Cortex-M USB host peripherals drive a VBUS-enable signal to a high-side power switch. That switch needs an over-current output, wired back to the USB peripheral or to a GPIO, so that a shorted stick does not take down the whole device. emUSB-Host consumes the over-current signal and reports it up to the application so the UI can tell the user “this device is drawing too much current”. On a battery-powered medical device, the power budget for VBUS is a real constraint, and the application decides whether to enable the host port at all based on battery state of charge.

Hot-plug detection is handled by the host controller driver. Plug events surface as callbacks to the application. The application is in charge of showing the right UI, “USB stick detected, press export to begin”, or “USB keyboard detected, ready to type patient ID”. The MSC-driven workflow is one of several; emUSB-Host’s architecture lets you register multiple class drivers and dispatch by whatever is actually plugged in.

Indian use cases: where emUSB-Host MSC earns its keep

Indian medical device OEMs exporting logs to a clinician’s USB stick. Patient monitors, infusion pumps, ventilators and diagnostic devices produce event logs, vital-sign trends and alarm records that are part of the device’s record-keeping obligation. For devices where the programme is developing against IEC 62304, Class B lifecycle rigour applies to the software driving the export, and the stack must be traceable, reviewable and supported. A USB port on the front panel plus a “export session” button plus emUSB-Host MSC plus emFile writing to a FAT or exFAT stick is the most common export path. The clinician plugs in, exports, unplugs, takes the stick to a workstation for the full record view. emFile’s Journaling guarantees that if the stick is pulled mid-export the filesystem is still consistent; the device can also detect the truncation and flag the export as incomplete.

Indian industrial HMI controllers importing recipes. Process machines, packaging lines, CNC, food processing, pharma batching, are configured with recipes that come from a plant engineer’s laptop. The engineer generates the recipe file on a PC, copies it to a USB stick, walks to the machine, plugs the stick into the HMI, and imports. The HMI runs emUSB-Host MSC, mounts the stick as FAT or exFAT, parses the recipe, validates it against machine limits, and stages it for the next run. Because the recipe files are Windows-generated, native FAT/exFAT interop is not negotiable, any custom filesystem would mean a custom PC-side tool, which is a support burden. emUSB-Host plus emFile makes the import a pure file-copy operation on the engineer’s side.

Indian test equipment saving captures. Bench instruments, signal analysers, data acquisition front ends, automated test fixtures, save capture files that can be large. A front-panel USB port plus emUSB-Host MSC lets operators pull captures straight onto a stick for analysis. exFAT is often the right choice here because captures can exceed the FAT32 4 GiB limit. The emFile + emUSB-Host combination handles both transparently, and the Journaling add-on protects the write path against unplug events.

In every one of these cases, the alternative to a commercial stack is to either (a) adopt an open-source host stack that is not production-class for MSC in the field, or (b) write the host and class driver in-house. Both options burn multiples of the license cost in engineering time, and neither gives you a named supplier when the compliance auditor asks.

Target silicon: which Indian-market parts are the right fit

emUSB-Host supports a wide range of USB host controllers on the Cortex-M parts that dominate Indian programmes.

STMicroelectronics STM32H7 is the workhorse. The OTG_HS peripheral on the H7 drives USB 2.0 high-speed host at 480 Mbit/s, which matters when the application is exporting large capture files or long medical session logs, high-speed is roughly an order of magnitude faster than full-speed for bulk transfers, and on a stick-write path you can feel the difference. For a patient monitor doing a multi-megabyte export, or an HMI importing a hundred-megabyte recipe package, the STM32H7 OTG_HS is the reference host for Indian programmes.

NXP i.MX RT1050, RT1060 and RT1170 have USB high-speed host built in with external or integrated PHYs, and the RT series’ large RAM makes it comfortable for the emFile buffer pool. These parts show up in premium medical and industrial HMI programmes where the display is also large and the application is Qt or similar. emUSB-Host’s RT driver is the production path here.

Renesas RA6M4 and RA8 parts include USB 2.0 high-speed with the USBHS module. For Indian industrial control and metering programmes that want a Cortex-M33 or Cortex-M85 core with TrustZone-M isolation, RA6M4 plus emUSB-Host plus emFile is a clean path. The RA8 variants pair high performance with the same host stack.

For lower-throughput needs, an HMI that only imports small recipe files, or a handheld device with tight battery budget, STM32F4/F7 parts running emUSB-Host on full-speed USB are still a perfectly valid target. The class driver, the filesystem pairing and the application API do not change; only the host controller driver varies by part.

Further reading

External, canonical SEGGER references:

• SEGGER emUSB-Host product page (segger.com)
• SEGGER emUSB-Host MSC class driver (segger.com)

GSAS internal cross-links:

• SEGGER partner page, full catalogue and India engineering support
• emUSB-Host product page
• emFile, filesystem layer for the mounted stick
• embOS, the RTOS most Indian emUSB-Host customers run above
• SEGGER emFile with NAND for Indian industrial and railway storage
• SEGGER emModbus for Indian industrial automation and energy metering
• Medical device solutions
• Industrial automation solutions

A front-panel USB port is one of those features where the difference between “works on the bench” and “works in the field across ten thousand units and a long tail of weird sticks” is the difference between a reference stack and a production stack. SEGGER emUSB-Host with the MSC class, paired with emFile and its Journaling add-on, is the commercial path we recommend for Indian medical, industrial and test-equipment programmes because it is production-tested, supported with source, pre-integrated with the filesystem, and backed by a named engineering supplier for the compliance story. If you are specifying a new device with a USB host requirement and you want to walk the architecture and the target silicon choice, the GSAS engineering team works with SEGGER customers across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai and Pune: reach out and we will sit down with your firmware lead.