Making Connections

Introducing the Type-C SuperMUTT

Posted by Terry Moore
Terry Moore
User is currently offline
on Tuesday, 01 August 2017
in USB 3

MCCI introduced our Model 3501 Type-C SuperMUTT today, the latest addition to our line of USB development tools!

You may be wondering, however, "What's a SuperMUTT?"

Let's break it down.

In the beginning...

Back in the early days of USB 2.0, Microsoft needed a tool that would let them verify the operation of high-speed host controllers and of their USB host stack. So they invented a test tool, and named it the "Microsoft USB Test Tool", or "MUTT".  This device has a Cypress FX2 controller chip and a lot of test firmware that let it emulate a variety of devices and thoroughly exercise all four transfer types on USB: bulk, interrupt, control and isochronous. It was a small device, that plugged into the USB port like a thumb drive.

The next generation...

When USB 3.0 came out, Microsoft wanted a similar tool for testing SuperSpeed host ports. So the "SuperMUTT" was born.  This device has a Cypress FX3 controller, which adds SuperSpeed support (now known as USB 3.1 gen 1, or 5 gigabit USB).  Again, they added a lot of firmware and host software, but the concept was the same -- a small devic ethat plugs into the USB port like a thumb drive.


I suspect you can guess where this is going.  The Type-C SuperMUTT is simply the SuperMUTT, enhanced for Type-C support. But why is it so much bigger?

Well, the Type-C connector can do a lot more than the original Type-A connector.  For example:

  • You can power your PC through the port
  • You can use DisplayPort alternate mode to drive a monitor from the port
  • If your PC is running from another power source, you supply a lot of power to external devices

This is very nice for the user, but it's a big job to test Type-C software thoroughly.  So the Type-C SuperMUTT adds the following features to the original SuperMUTT

  • Support for signaling over the CC wire of the Type-C cable
  • Support for the USB Power Delivery specification
  • Ability to pass power from an external supply to the unit under test (as instructed by the Power Delivery specification)
  • Support for alternate modes, particularly DisplayPort
  • Support for connecting to an external charger, again for testing.

In order to be able to accurately emulate all the variants of the PD specification, the PD interface is implemented with a Lattice iCE 40 UltraPlus FPGA. This gives the ability to emulate the different design decisions of different manufacturers, as well as the ability to emulate and inject various kinds of faults.

With all of this functionality, and all of the electrical power that can be handled, we needed to have a fan. And we needed to have a robust enclosure.

Hence the model 3501 as you see it above.

As you might guess, the 3501 was developed in conjunction with Microsoft; they'll be supplying the Windows test software and embedded firmware for the product. We'll be receiving the second production lot in late September, and we're taking orders now via our online store.

A slight digression

You might have noticed that some of our literature calls the Model 3101-family of USB Connection Exercisers the "MUTT ConnEx-C". This is because it's really a part of the Microsoft USB Test Tool family (and you can see it here on the MUTT page at Microsoft).


Interested in learning more about the details? Post a comment here with your questions, or tweet me at @TmmMCCI, and I'll do my best to answer.

Hits: 62 0 Comments
0 votes

Website update 2016-05-22

Posted by Terry Moore
Terry Moore
User is currently offline
on Sunday, 22 May 2016
in MCCI Website Updates

It's baseball season (and then some), so if you're keeping score at home, here's a summary of our recent website updates.

  • The Model 3101 Type C Connection Exerciser has gone from announced to beta to production status. devtools/exerciser-type-c.html.
  • MCCI now has a support portal for handling our development tools and and entry-level USB software. Customers with support contracts will still use our existing mechanisms, but there's a more structured alternative for customers without a support contract. For information, see support/support.html; or go directly to the MCCI support portal, hosted on Zoho.
  • Of course, numerous minor updates all through the site.

Feedback is always welcome. (And now, if you send email to This email address is being protected from spambots. You need JavaScript enabled to view it. , we'll open a ticket and track it!)

Hits: 461 2 Comments

Website updates 2015-10-04

Posted by Terry Moore
Terry Moore
User is currently offline
on Sunday, 04 October 2015
in MCCI Website Updates

One major update today, and some minor ones.

The major update: our USB OTG product now supports Type C dual role, and so we're renamed it TrueTask Dual-Role USB. We've supported Microchip FlexConnect hubs for a while, but somehow it never made it to the website; so that was added too. Find out more on the TrueTask Dual Role USB stack page.

With that, we made the usual small changes here and there.

As always, please let us know what you think! Leave a comment, or find me on Twitter (@TmmMcci) or LinkedIn (

Hits: 765 0 Comments

Website updates 2015-10-01

Posted by Terry Moore
Terry Moore
User is currently offline
on Thursday, 01 October 2015
in MCCI Website Updates

A variety of minor updates today, thanks to our eagle-eyed proof-reader, Sherri Russo.

As always, please let us know what you think! Leave a comment, or find me on Twitter (@TmmMcci) or LinkedIn (

Tags: Untagged
Hits: 661 0 Comments
0 votes

Using Microsoft's VHD version of Windows Server 2015 R2

Posted by Terry Moore
Terry Moore
User is currently offline
on Sunday, 06 September 2015
in Useful Tips

Microsoft has a pre-installed VHD version of Windows Server 2012 R2 available for download. 

The reference can be found here:, under the section titled "Installing versions distributed as VHDs".  The VHD can be downloaded from here:

I can confirm that the download evaluation image works well, and is much faster to set up than installing from distribution ISOs. But I could not make their instructions work for me, and a quick search of the web indicated that others were puzzled.

Here are the original instructions:

To use the VHD distribution, you must have a computer running Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2. The Hyper-V server role must be installed.

To install the VHD

  1. Download the VHD file.
  2. Start Hyper-V Manager. On the Action menu, select Import Virtual Machine.
  3. Navigate to the directory that the virtual machine file was extracted to and select the directory (not the directory where the VHD file is located).
  4. Select the Copy the virtual machine option.
  5. Confirm that the import was successful by checking Hyper-V Manager.
  6. Configure the network adapter for the resulting virtual machine: right-click the virtual machine and select Settings. In the left pane, click Network Adapter. In the menu that appears, select one of the network adapters of the virtualization server, and then click OK.
  7. Start the virtual machine.

These instructions don't quite work. 

First of all, the VHD is not a VM, so you can't copy or import it.

Second, it's not clear (from web searches) that this will work at all under Server 2008 R2 -- there were hotfixes suggested.

Luckily, I have Windows 10 Pro, and this works fine as a host. (In fact, it appears that Windows 8.1 Enterprise also works; I used that for some of the screenshots. But I did most of this on Windows 10, and that's what I'd recommend to others.)

Here's the procedure I followed.

To prepare the Windows 10 Pro system

  1. Make sure you have Windows 10 Pro installed. Press [Windows}R and type "winver", then press enter. In the resulting text box, confirm that you see the text, "The Windows 10 Pro operating system and its user interface are protected..." If you see Windows 10 Home, you'll need to upgrade.
  2. Right click on Start, and select "Programs and Features"
  3. Select "Turn Windows features on or off" (on left)
  4. Scroll down to Hyper-V, and make sure the top level checkbox and subordinate checkboxes are all ticked. If not, check them, and go through the installation process. A reboot will be needed at this point.
  5. Once you've confirmed that Hyper-V is installed, press [Windows]R and type "mmc", then press enter. You'll probably get a UAC pop-up ("do you want to allow this app to make changes to your PC?"); if you do, click [Yes].
  6. Select File>Add/Remove Snap-In...
  7. Scroll down to Hyper-V Manager, click "Add". There typically will be a pregnant pause, followed by a progress bar; then Hyper-V Manager will appear under "Selected snap-ins" on the right. Click OK.  (The process of doing this creates an applet; from this point on, you can click start and type "Hyper" and "Hyper-V Manager" will show up.
  8. You'll now see Hyper-V Manager under Console Root:

  9. Click on "Hyper-V Manager" in the left pane, expand things if necessary, and you'll see something like the following:

  10. You probably want to configure one or more networks for use by Hyper-V. To do this, make sure your machine is selected in the left panel, then on the Action menu select Virtual Switch Manager... I created an External switch, Connection type  "External network", and selected my Ethernet adapter in the drop-down list. (I've also successfully selected a Wi-Fi adapter at this step.) Very important: be sure to select "[x] Allow management operating system to share this network adapter".  Click OK.
  11. You're now ready to proceed.

To install the VHD

  1. Download the VHD file. 
  2. If needed, copy the VHD file to a suitable location. On my system, Hyper-V looks for VHD files in C:\Users\Public\Documents\Hyper-V\Virtual hard disks, so I put it there.
  3. Start Hyper-V Manager, and make sure your machine is selected in the left panel. On the Action menu, select New... > Virtual Machine.
  4. Go through the steps of creating a new virtual machine. On the following menu, make sure you select "Generation 1 Virtual Machine". Click Next.

  5. "Assign Memory": Specify 2GB of RAM. I didn't select "[ ] Use Dynamic Memory for this virtual machine". Click Next.
  6. "Configure Networking": you can do this later -- just click Next
  7. "Connect Virtual Hard Disk" -- I selected "Attach a virtual hard disk later". Click Next.

  8. "Completing the New Virtual Machine Wizard" -- review the options, and click "Finish" to create the VM.
  9. Verify that the VM was successfully created by checking Hyper-V Manager
  10. Configure the downloaded VHD file as the disk for the resulting virtual machine: right-click the virtual machine and select Settings. In the left pane, click IDE Controller 0. In the right pane, select "Hard Drive", then Add. In the menu that appears, under Virtual Hard Disk, select Browse..., and navigate to the VHD image you downloaded. Select the file and click OK.
  11. Configure the network adapter for the resulting virtual machine: right-click the virtual machine and select Settings. In the left pane, click Network Adapter. In the menu that appears, select one of the network adapters of the virtualization server, and then click OK.
  12. Start the virtual machine.

Was this post useful to you? Want to see more on some topic? Leave a comment, or find me on Twitter (@TmmMcci) or LinkedIn (



Hits: 2313 0 Comments
0 votes

Cygwin home directories

Posted by Terry Moore
Terry Moore
User is currently offline
on Saturday, 04 July 2015
in Useful Tips

I recently installed some new tools from a third party, and had to update my Cygwin installation.  There is no official version of the overall release (see the FAQ); but I was running a release from November 2014, or so, and I updated today (July 4).

After the update, my Cygwin home directory had changed, and wasn't what I wanted.

Summary: if your Cygwin home directory is wrong after an update, you need to look at /etc/nsswitch.conf, not /etc/passwd.

Here are the details.

After I updated, my home directory was a different place than before. I recognized this immediately because the prompt changed from

bash:redacted::~ $


terry@redacted ~

And of course, all the other settings from my .bashrc were not taking effect.

In my setup, for historical reasons, my home directory is "c:\usr\terry" -- I've been running this setup since Windows NT days, and it's been nice not having a name that changed based on the Windows version in use. I use the same home directory for Cygwin and Windows.

Also for historical reasons, I have let Windows continue to assign whatever it felt like for a home directory. On my current Win8.1 machine, that's "c:\users\terry".

In the old version of Cygwin, this was accomplished by editing the /etc/passwd file (as on Unix). My passwd file contains the following line:


In previous versions of Cygwin, this was all that was needed; when I launched a Cygwin window, bash found my .bashrc file in c:usrterry, and things proceeded as I expected.

After I updated to the version including Cygwin 2.0.4, this no longer worked. Cygwin was not honoring the contents of /etc/passwd.

I'll omit a discussion of the things I tried. It turns out that, by default, the newer versions of Cygwin no longer use /etc/passwd.  Instead, there's a new mechanism, /etc/nsswitch.conf, based on a similar mechanism from Linux. This page has all the details.  Search for nsswitch.conf, and don't worry too much about all the AD and SAM stuff; I was able to ignore it.

In order to get my home directory setup working again, I added the following to /etc/nsswitch.conf:

db_home: /cygdrive/c/usr/%U

%U is expanded to the current user's Windows login name (terry in my case).

The following setting is similar and useful, but it don't do what I want.

db_home: windows

It doesn't do what I want, because it uses the Windows home directory, which is c:\users\terry. This causes my home directory to be /cygdrive/c/Users/terry, which isn't the place I want. (Something like this might be good for other people, however, which is why I mention it.)

(Updated 2015-09-06: add some missing backslashes, make one-page article.)

Was this post useful to you? Want to see more on some topic? Leave a comment, or find me on Twitter (@TmmMcci) or LinkedIn (

Hits: 2541 0 Comments
0 votes

Standardizing LTE modems for IoT

Posted by Terry Moore
Terry Moore
User is currently offline
on Wednesday, 06 May 2015

The Ikanos announcement today (D-Link Selects the Ikanos Vx500 Fusiv Processor Family for Its Next-Generation of LTE Routers and Gateways) was doubly significant to me, because they're using the MBIM USB standard for communications between the embedded SoC and the modem. I chair the MBIM committee; it's great to see this work being applied outside the PC world.

I recently (well, back in January) did a presentation for the Wireless Technology Association (formerly PCCA) on using the MBIM spec as part of a strategy for adding LTE support to IoT devices. The announcement reminded me that I ought to post the presentation, so... here it is: Standardizing LTE modems for IoT. The presentation covers the underlying economics, the relevant standards, current status, and next steps, with a particular emphasis on USB standardization.

Tags: Untagged
Hits: 783 0 Comments

Building one driver for Win7, Win8, Win8.1

Posted by Terry Moore
Terry Moore
User is currently offline
on Wednesday, 18 March 2015
in Useful Tips

Among other things, MCCI creates Windows kernel-mode drivers for internal product use and for licensing to customers to bundle with their products.

We want to run the same binaries on all compatible platforms. So (for example) we build one driver for x86 that will run on all supported operating systems.

This article summarizes our experience in doing this, and offers some concrete tips on how to do things (and how to solve problems).

We'll start with some reference material.

You have two choices, either limit yourself to the features of the oldest operating system, or dynamically determine what version you're running on, and dynamically import symbols using MmGetSystemRoutineAddress().

MCCI needs to do the latter (use the newer features on newer OS versions, and fall back to a reasonable substitute on older operating systems).

Microsoft has specific recommendations about what to do, posted in two MSDN articles: (writing), and (building). It is odd to find a recommendation about kernel mode drivers in the "Office Dev Center", but let us not digress. The salient points for our use case are:

  1. Use the most recent applicable WDK (if you want to target 7 through 8.1, use WDK 8.1)
  2. Use RtlIsNtDdiVersionAvailable() to query whether a given feature is available, and then use MmGetSystemRoutineAddress() to get the function name if so.
  3. Use the Microsoft C "typedef typeExp ( functionName ) extension. This extension is somewhat like gcc "typedef typeof(function) typename"; it creates a type from a function, including all the SAL annotations and attributes like calling sequence (CDECL, STDCALL, FASTCALL, etc.)  You can directly create a pointer type from the function, but MCCI normally prefers to create a function type, as this lets us also define substitute functions that can be used when needed.
  4. Don't directly call functions that are not present in all systems of interest.
  5. Link with $(DDK_LIB_PATH)\BufferOverflowK.lib if you need to support Win7 and earlier. (The default if you're targeting Win8.1 willl be $(DDK_LIB_PATH)\BufferOverflowFastFailK.lib -- this is not what you want. Drivers built with the Win8.1 WDK will immediately bug-check on Win7.

This advice is all good -- but not sufficient.  (More about that below.)  Let's start by amplifying some of the above points.

Dynamically Importing APIs

It's very important to check RtlIsNtDdiVersionAvailable() before calling MmGetSystemRoutineAddress() -- MmGetSystemRoutineAddress() doesn't necessarily return NULL on platforms where the function is not supported.

Defining types for your imported functions

Because of calling-sequence issues, it's very important to use the typedef trick. But bear in mind that, at least with some Microsoft compilers, it doesn't work right for FASTCALL functions on X86. MCCI's workaround in that case is to cut and paste the exact definition from the WDK header file (normally wdm.h) and put it in our header file.

Selecting the right Buffer Overflow library

Linking with BufferOverflowK.lib is critical. But you have to make sure that you add this in the right place, because it uses the variable $(DDK_LIB_PATH), which must be already defined.

Find the following place in your .vcxproj file:

The above line will end up assigning a value to DDK_LIB_PATH.

After that line, insert the following:


The label "KernelBufferLib" is arbitrary.

If you put the property group in the wrong place, it won't have effect, and the WDK will silently use BufferOverflowFastFailK.lib -- which is definitely not what you want.

It's a very good idea to look at your msbuild.log and examine the link.exe invocation -- make sure that the library you wanted was linked. I just search for BufferOverflow in the log, and make sure that it's the library I want.

Don't directly call functions that are not present (KeInitializeSpinLock as an example)

This one is trickier than it looks. Microsoft sometimes changes function calling sequence, or changes from inline to calling a function exported by the kernel. In these cases, the MSDN documentation doesn't help you -- the API is present, but the way it compiles is different.

For example, the API KeInitializeSpinLock() is present in all versions of Windows. However.... In Windows 7 and earlier, it was implemented as an inline function. The kernel (ntkern.sys) didn't export a function named KeInitializeSpinLock.  A driver built with the Win7 WDK will not import KeInitializeSpinLock(); on Win8.1, it will use the inline instead of calling the kernel-exported function. No great loss, as the kernel function does the same thing, plus possibly inserting barriers and/or doing more Driver Verifier checks. (To be honest, I haven't looked into why they made the change.)

The tricky part is building the same driver with the Win8.1 WDK. It will run fine on Windows 8.1, but on Win7, the system won't load it. (You'll get a Code 39 error in device manager, and a message about the driver possibly being corrupt.)

To a developer, Code 39 almost always means "oops, I'm using an export that doesn't exist on this system". Finding the missing export can be tricky. I use depends.exe/depends.dll/depends.chm from the WDK 8.1 tools tree. (There's a website that claims to have it, but there wasn't enough authentication, so I didn't want to download it.) I put the three files on a thumb drive and carry it to the Win 7 system, and run the tool.

"depends.exe" is useful, but itself is a bit tricky. For me, it always complains that it can't find wmilib.sys. I have learned to ignore that as a false positive. The key thing is select each imported DLL, then click on the PI^ button in the top-right box. This will bring any unsatisfied imports to the top of the list, as in the following screenshot.

In fact, on Win7, you'll see that KeInitializeSpinLock appears in red. This tells you (1) Win7 doesn't export KeInitializeSpinLock(), and (2) Win8.1 does.  (You know it does, because your driver loads on Win8.1.) This should cause you to immediately compare the Win7 WDK wdm.h definition of KeInitializeSpinLock with the Win8.1 equivalent. You will immediately see that on Win7, KeInitializeSpinLock is always a FORCEINLINE function; whereas on Win8.1, it may be an external function. You will see some complicated conditional compiles, and (if you're like me) you'll conclude that trying to force the header file to generate the inline when targeting Win8.1 would be a mistake -- you don't know what else will happen. Finally (again, if you're like me), you will realize that there probably is an important reason to use the kernel's KeInitializeSpinLock if it's available.

So we have to do the run-time import MmGetSystemRoutineAddress() trick.

How to do this?

We have to start by defining a symbolic type based on KeInitializeSpinLock(). If you don't need to worry about compiling on older WDKs (no legacy code or systems, lucky you), you can probably just do this:

typedef MYDRIVER_KeInitializeSpinLock_t (KeInitializeSpinLock);

[MCCI has 20 years of customers who need to be supported, which means that I can't simply mandate that the Win7 WDK will go away; and we use common code; so I'm not as lucky as you. But we will discuss the solution to Win7 / Win8.1 WDK source compatibility in another post, if at all.]

You'll need someplace to store the pointer; you don't want to look this up every time.

MYDRIVER_KeInitializeSpinLock_t *MYDRIVER_gpKeInitializeSpinLock;

You'll need a function to use in case you're on an old system and there's no kernel export to call:

MYDRIVER_KeInitializeSpinLock_t KeInitializeSpinLock_DownLevel;

VOID KeInitializeSpinLock_DownLevel(PKSPIN_LOCK pSpinLock) {
    *pSpinLock = 0;

At driver initialization, you need to check the system version and import the name:

if (RtlIsNtDdiVersionAvailable(NTDDI_WIN8)) {
   RtlInitUnicodeString(&fName, L"KeInitializeSpinLock");
   pKeInitializeSpinLock = (MYDRIVER_KeInitializeSpinLock_t *)MmGetSystemRoutineAddress(&fName);
} else {
   pKeInializeSpinLock = KeInitializeSpinLock_DownLevel;

Then you must find all calls to KeInitializeSpinLock() in your code, and change (for example):




MCCI driver code isn't permitted to use global variables at all; so instead of using a global, MCCI would put it in a "driver object extension", but the principle is the same.

By the way, the "MYDRIVER_" prefix is whatever prefix you use in your driver to distinguish your symbols from Microsoft's symbols. (You do use a prefix, don't you?)

Was this post useful to you? Want to see more on some topic? Leave a comment, or find me on Twitter (@TmmMcci) or LinkedIn (

Tags: Untagged
Hits: 2123 0 Comments

Creating a .lib file for libclang on Windows

Posted by Terry Moore
Terry Moore
User is currently offline
on Thursday, 06 November 2014
in Useful Tips

I'm doing some code refactoring work. For a variety of reasons, I want to try libclang, the C interface for clang/llvm. I want to get to doing my tests immediately, and not waste time building it.

I downloaded the LLVM 3.5 distribution for Visual Studio.

Immediate roadblock: they ship "libclang.dll" (the code I want to use, in compiled form), but no "libclang.lib" (which the Visual Studio linker wants for linking my C apps to libclang).

Some searching found this very useful page: Create .lib file from .dll

However, it was manual; I'll never edit by hand if I can write a script. So here are my steps. Obviously, this can be used for any .dll, if it uses C APIs. (Equally obviously, you'll need a header file to compile your C, but ... I have that.)

  1. Start a command window from Visual C. I do this to get all the paths set up correctly for the VC tools. I don't like having my path set statically -- I use many different compilers, and several different versions of Visual C side by side.

  2. In the VC command window, use dumpbin.exe to generate a listing of the exports.
    dumpbin libclang.dll /exports >clangdefs.txt
  3. Then in a cygwin window:
    awk 'BEGIN { print "EXPORTS" }
        /ordinal hint/,/Summary/ {
            if ( $1 ~ /^[0-9]+$/ ) print $1,$4
        }' clangdefs.txt >libclang.def
  4. Finally, back in the VC window (from steps 1 & 2):
    lib /def:libclang.def /out:libclang.lib
    Microsoft (R) Library Manager Version 10.00.40219.01
    Copyright (C) Microsoft Corporation.  All rights reserved.

    LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
       Creating library liblang.lib and object liblang.exp

 Of course, this can all be combined into a single script.

Thanks to Adrian for posting the instructions. You can find terse instructions in MSDN (, but I certainly agree with Adrian that his instructions are much more to the point.


Tags: Untagged
Hits: 1907 0 Comments

IPextreme's "Take 5" Interview

Posted by Terry Moore
Terry Moore
User is currently offline
on Friday, 10 October 2014
in Business

Warren Savage of IPextreme recently interviewed me for an segment of his "Take 5 with Warren" series.

I think I made three important points.

First, once it's possible to buy an IP block, or system software, from an external vendor, that techology almost by definition is no longer core technology, but is mission critical. 

Aside: I hear someone asking, "Why?"  My answer: if a competitor can buy that technology, so possession of the technology (by itself) no longer differentiates one product from a competitor's. Anything that is not differentiating is therefore (almost certainly) not core technology. 

Another aside: I hear someone else asking "core? mission-critical?"  Gordon Moore popularized this terminology in Crossing the Chasm. My example comes from digital cameras:  lens and imager are core technology (and are a basis of competition between vendors); USB is mission critical (everyone has it, but nobody competes on that basis).

Yet another aside: "what's an IP block?" An IP block is essentially a hardware component that performs a specific function, and is packaged to be bought by a chip maker and incorporated into a chip. Warren's company, IPextreme, specializes in IP blocks, and also in design for reuse. MCCI does a very similar thing, except that our blocks are pure software, and instead of being incorporated into the chip, are incorporated into the software that accompanies the chip.

Second, modern IP blocks (USB hardware blocks, for example) must be accompanied by specialized system software in order to actually perform the desired function. In order to reduce hardware complexity and increase flexibility, higher-level functions are delegated to system software. Much of this system software (like a TCP stack or a USB stack) only performs housekeeping operations; but without the housekeeping, nothing works. T

Third, and a consequence of my previous point: IP providers, embedded system software makers, and SoC IP users, and the software team that's supporting the SoC deployments need to cooperate closely. Our timescales differ a lot -- IP providers typically develop their code a year before the chip design starts. Then there's a need for system software for verification of the SoC design. Later, when the chip is ready, there's a need for cooperation between the various groups for problem resolution. At that point, if the IP providers and the embedded software company (like MCCI) have already been working together, we can do a much better job of helping resolve problems.

Many thanks to Warren for the interview and the interest!

Tags: Untagged
Hits: 1803 0 Comments

WinHEC is back

Posted by Terry Moore
Terry Moore
User is currently offline
on Friday, 26 September 2014
in Business

Just heard from my friends at Microsoft: WinHEC is back.

I think the new team at Microsoft is moving in the right direction: not only cloud first, etc., but engineering as a foundation.

Tags: Microsoft
Hits: 804 0 Comments

DisplayPort over USB type C

Posted by Terry Moore
Terry Moore
User is currently offline
on Monday, 22 September 2014
in USB 3

I attended the USB 3.1 developer's conference last week in Seattle; but the big news about type C didn't come out until today. 

The VESA press release is here:

Interesting points:

  1. This wasn’t mentioned during the USB 3.1 Developer Days last week (not even hinted at)
  2. This may have a dampening effect on display-over-USB technologies such as DisplayLink or the USB AV class
  3. This will compete directly with technologies like MHL, DiiVA, and micro HDMI
  4. The press release is confusing. Today, USB 3.1 (gen1 and gen2 in the new lingo, SuperSpeed and SuperSpeed Plus in the old lingo) can use exactly two lanes (one for TX, one for RX). Support for four lanes is "future". So DisplayPort can readily use the extra two lanes with no effect on existing deployment
  5. DisplayPort over type C does conflict with a use case shown for docking stations last week, using type C, in which PCIe Gen2 was run over the spare two pairs of wires.
  6. So far I see no announcements of silicon support, which is unusual when a new technology specification is announced.

Until Intel, Qualcomm or MediaTek provide support in their system chips, or a third party announces a mux chip, this won't show up in real systems. Silicon support is the key. Watch for responses from Silicon Image and DisplayLink.

(Although this is all over the web, I found this thanks to Tom's Hardware, who posted this:,27731.html)

Hits: 1124 0 Comments

Synopsys demos USB 3.1 support with MCCI's USB host stack

Posted by Terry Moore
Terry Moore
User is currently offline
on Wednesday, 17 September 2014
in USB 3

I'm attending the USB 3.1 Developer Days conference in Seattle, and I was pleasantly surprised to see Synopsys demonstrating USB 3.1 host, talking to a USB 3.1 BOT device, using MCCI's host stack on Windows 8.1. (Click on the picture to see the details.) Yep, 918 megabytes per second, or roughly 7.5 gigabits/sec on the bus.

Note that we're getting 918 MB/sec read speed, roughly twice as fast as MCCI's stack with USB 3.0 host controllers.The really gratifying thing is that no modifications to MCCI's USB host stack were required. If you zoom in on the device manager portion of the screenshot, you'll see that they're using MCCI's host stack, along with MCCI's high-performance mass storage drivers. (Which I've written about before: see "MCCI's UASP and BOT Drivers".) Of course, the Microsoft stack would also have worked; we're pleased they chose to demo using our stack.

Since MCCI's Windows stack consists of our embedded system stack (TrueTask® USB), plus Windows-specific wrappers, this means that our embedded stack can offer similar performance for USB 3.1 systems, in addition to providing the peace of mind of a stack that has been tested at USB-IF PIL, and used by millions of users on Windows systems.

Of course, the kudos should really go to Synopsys -- it's very impressive. Glad we could be a part of it. I'm looking forward to even better performance once we have a chance to tune the software part of the demo.

Hits: 838 0 Comments

Website update 2014-09-08

Posted by Terry Moore
Terry Moore
User is currently offline
on Monday, 08 September 2014
in MCCI Website Updates

It's September in NY, and at least upstate in Ithaca, you can really understand why they say that meteorological autumn begins September 1. So... time for another website update!

Today's changes are all related to adding a new page:, which describes MCCI's support for USB Wi-Fi adapters from Mediatek/Ralink. 

As always, please let us know what you think!


Tags: Untagged
Hits: 724 0 Comments
0 votes

FTDI Chip announces technology partnership with MCCI Corporation

Posted by Terry Moore
Terry Moore
User is currently offline
on Tuesday, 26 August 2014
in TrueTask USB

Everyone doing USB knows FTDI Chip - one of the pioneers in USB peripheral silicon -- USB serial adapters, USB to SPI, USB to FIFO, and so forth.

MCCI is therefore very honored to have been selected by FTDI Chip to support the USB host portions of their FT900 MCU product line.

As the CEO of the company, sometimes I get the nasty jobs, but sometimes I get the fun ones. I've been working with the FT900, porting MCCI's Os/None environment to the FT900, and bringing up our EHCI stack. It's really been great fun. I started programming in assembly language in 1970 or so, and I've done system software for everything from 12-bit avionics computers to modern 64-bit systems. It's been a pleasure to do the low-level assembly-language work for the FT900 -- despite being a RISC machine, it's a pleasure to program. It's been fun figuring out how to take maximum advantage of the Harvard architecture from MCCI's portable code base, without making major changes; I'm pretty happy with the results so far.

I don't want to steal FTDI Chip's thunder -- for more info you can look at their MCU page -- but I think a lot of designers who are used to working on the bare iron will fall in love with this device. It is not a general purpose CPU, but it takes all the features from general purpose CPUs that make them more pleasant to program than the MCUs of the 80s and 90s, without the overhead that comes with trying to re-purpose a general-purpose CPU for MCU purposes.

Hits: 1471 0 Comments

Website update 2014-08-16

Posted by Terry Moore
Terry Moore
User is currently offline
on Sunday, 17 August 2014
in MCCI Website Updates

Updated the website today, to refresh the home page and add a new video overview of MCCI.

Updated pages: 

As always, let us know what you think by leaving a comment or sending us a note.


Tags: Untagged
Hits: 791 0 Comments
0 votes

Catena 1910 Software Update V1.34

Posted by Terry Moore
Terry Moore
User is currently offline
on Tuesday, 24 June 2014
in Catena 1910

MCCI has a new software update, V1.34, for the Catena 1910 HSIC USB Verification and Protocol Analyzer System. Updates included in this release are:

  • HSIC Aux support.
  • Improved bus-keeper compatibility.*
  • Improvements to FPGA update functionality.
  • Improvements to Soft-PHY timing.
  • GUI-based FPGA download and capture control.

The bus-keeper compatibility change makes the 1910 compatible with the latest HSIC ECRs. Depending on when the Catena 1910 was delivered, it may require probe hardware modification for full bus-keeper support. Please contact us to find out whether you need your probe updated.

Software updates are available for all Catena 1910 systems that are currently under maintenance. To find out whether you qualify, please contact MCCI via email at This email address is being protected from spambots. You need JavaScript enabled to view it. . Please include your unit's serial number.

Information about earlier software releases is available below.


Tags: Untagged
Hits: 1524 0 Comments

A little more on MBIM

Posted by Terry Moore
Terry Moore
User is currently offline
on Friday, 20 June 2014

There's been a bit of discussion in the LinkedIn USB Experts group regarding my recent PCCA presentation, "The end of AT? MBIM and the long goodbye to modem emulation."

Sten Carlsen asked me whether we'd referred to the Bluetooth LE (marketing name: "Bluetooth Smart") specification. We didn't, but his question led me to take a look at the specification. Bluetooth LE devices use a profile called GATT, which is conceptually quite similar; but it wasn't something we discussed in the NCM committee. I think, rather, that both groups were influenced by architectural concepts that date back to the Apollo DomainOS of the 1980s. Here's my take on the family tree:

Tags: MBIM
Hits: 1169 0 Comments

The end of AT? MBIM and the long goodbye to modem emulation

Posted by Terry Moore
Terry Moore
User is currently offline
on Tuesday, 17 June 2014

I presented today at the PCCA Workshop on New Wireless Services and Applications Through Connectivity Management at Smith Micro in Aliso Viejo, CA.  (PCCA is a great organization that sponsors periodic technical workshops for the wireless community.)  My topic: the adoption of MBIM, which is rapidly replacing POTS modem emulation and AT-commands for LTE modules.

The presentation is both historical and technical, tracing the technologies that were incorporated into MBIM, and exploring in moderate depth the technologies and the reasons for its success.

You can get the slides here: pcca-moore-2014-06-17c.pdf

You can get the MBIM specification from USB-IF. The current version is

(I grew up in southern California, and I dig Raymond Chandler, for example his description of Santa Ana winds:

It was one of those hot dry Santa Anas that come down through the mountain passes and curl your hair and make your nerves jump and your skin itch.... Meek little wives feel the edge of the carving knife and study their husbands' necks.

The title is a lame attempt at homage.) 


2014-06-19: I added some additional information about MBIM and Bluetooth LE GATT profile n a subsequent post, A little more on MBIM.

2014-06-18: eliminated duplicate slides.

2014-08-19: correct a mangled link.

Tags: MBIM
Hits: 1709 0 Comments
0 votes

Decoding Arbitrary USB Protocols Captured with Total Phase Beagle

Posted by Terry Moore
Terry Moore
User is currently offline
on Monday, 16 June 2014
in Useful Tips

One of the most useful tools for USB development is a protocol analyzer, such as the Total Phase Beagle 480. These tools not only capture data, but include class protocol decoders that interpret the trace at a higher level of abstraction.

Sometimes, however, the analyzer software doesn't have the ability to decode the protocol of your device. MCCI often has to capture USB data for new protocols, or for vendor-specific protocols. In this case, the analyzer software doesn't have the appropriate class decoder. In this case, we typically write tools to parse the output from the analyzer and display the data in terms of the target protocol.

MCCI's Yogender Saroha recently wrote a case study of how to do this for Remote NDIS and the Beagle 480, which Total Phase has published on their website, and sent out with their June newsletter. You can access the case study here. The case study includes a link to the complete source code distribution. The tool that Yogi built integrates nicely with the scripting facilities of the Total Phase Data Studio, and works on Windows, OS X, and Linux. You can readily modify the code to parse other protocols (and you'll get an idea of how MCCI does things).

If you find the tool useful, please let us know!

Tags: Useful tips
Hits: 1378 0 Comments
0 votes
Legal and Copyright Information