24
Mar

UM232H = $20 Logic Analyzer

DSC_1755

Long story short, the UM232H can easily be turned into a 7.5 Msps Logic Analyzer (async 245 mode) with some added software (in progress).

What is a Logic Analyzer? No, it doesn't explode when an anti-vaxer blows into it. Nor does it help explain why the opposite sex is clearly crazier than you. A logic analyzer simply allows you to capture, display and decode digital signals. Very helpful when debugging your robot army, or making little Arduino circuits work.

Some friends and I wanted to build a really fast FPGA based Logic Analyzer (LA), but we all have lives (unfortunately?) and many other side projects. During the early design phase, we selected the FTDI FT232H USB IC as the link to a computer. After reading through the datasheet a bit, I noticed that it may be possible to have that single IC function as a low speed logic analyzer. Even better, FTDI sells a small $25 dev board for the FT232H called the UM232H that plugs directly into a breadboard and saves us work (other dev boards 1, 2). When it became clear that the group didn't have the time required to bring an epic FPGA design to life, we decided to try wrangling the UM232H into a cheap LA. The idea was to have the UM232H sample its 8 input pins as fast as possible and dump the data upstream to a computer for analysis and storage. This idea isn't novel as there are many other cheap analyzers (read: Saleae clones) that do that exact thing with a Cypress FX2 IC. However, the FTDI IC is 2-3 times cheaper than the more capable Cypress IC, and I was looking to learn something new anyway.

The diagram below shows the wiring required to make the UM232H work as a cheap LA.


um232h-wiring-1

Essentially, we program the FT232H to output a 30, 15, or 7.5 MHz clock (our LA sampling rate) on pin AC8 and feed that back to its write input.

There are 2 primary modes of interest: synchronous 245 mode and async 245 mode. Both modes have a dedicated output pin that is used to indicate when the IC is busy and cannot sample any more data. This allows us to easily monitor whether samples are being dropped with an ultra bright LED or microcontroller interrupt.

  1. Synchronous 245 mode boasts transfer speeds of up to 40 MB/s, but requires that the write input signal be synchronized with an internally generated 60 MHz clock. This limitation is fine if you have a FPGA connected to it, but makes things awkward if you are trying to make an uber cheap LA. Below, you can see how to use the IC's own generated signals (on pins AC8 and AC9) to make it sample at 30 Msps or 15 Msps with an OR gate (or a diode equivalent).
  2. Asynchronous 245 mode allows us to provide the sampling clock signal whenever we want, but only boasts transfer speeds of up to 8 MB/s. Booo.

Unfortunately, I could not get sync 245 mode sampling at a consistent 30 Msps - it was always a consistent 28.5 Msps. Changing from Java to C, old laptop (USB2) to a new powerful (USB3) laptop,  tweaking every setting I could think of did nothing to change this.

30 msps

How to achieve 30 Msps in synchronous mode.
Synchronous mode samples when WE# input is low before a rising CLK edge.

 

15 msps

How to achieve 15 Msps in synchronous mode.
Synchronous mode samples when WE# input is low before a rising CLK edge.

I then tied WE# directly to ground to make it sample as fast as it was capable, and noticed it capped out around 36.7 Msps when the data sheet specified up to 40 Msps.

ORing together a 30 MHz and 15 MHz signal to provide the correct WE# input to sample at 15 Msps, I still noticed regular faint LED flashes indicting samples were still being dropped even though my bench test software calculated a transfer rate of 15.023948 MB/s (131072000 B / 8.724205 s). Wellllll frack. Hopefully I missed a setting somewhere, but I'm pretty sure this limitation is due to the small internal buffers in the FT232H. It just fills up too quick between reads by the computer. Adding some external buffering would allow you to easily hit the 30 Msps mark, but it would defeat the goal of the UM232H hack to keep it super simple in hardware. If I wanted to add buffers cheaply, I would investigate using a PSoC 42xx device as the buffer.

Trying this all again in async mode, I saw the exact same problematic behavior at 15 Msps (as I expected), but saw that everything looked perfect at 7.5 Msps.

7.5 Msps is slower than I would like, but it will meet the majority of my current needs just fine.

I also tried CPU mode and it seemed to do 15 Msps based off of timing (just like the others), but there was no easy output pin to monitor for dropped samples (you have to poll the device).

 

How do you view the captured data?

I'd like to use Sigrok's PulseView application to view the data. It isn't perfect, but it continues to improve and has a committed team. It is also the best free open source option that I've come across. I might write a driver for Sigrok/PulseView (so you can directly capture from PulseView) or just have a program create a valid sigrok file (super easy zipped file format) that can be opened in PulseView.

 

Code

All details at Github repo

Windows .exe file (must install FTDI drivers and use FT_PROG as detailed on github)

Unfortunately, FT_PROG (the program used to put the FT232H IC into 245 mode) currently only runs on Windows. There are options for Linux, but I prefer to use the FTDI officially supported tool to avoid bricking the IC (definitely possible).

Code, install, and driver info moved to Github repo.

Comments

  1. Just wanted to say that I thought your idea was pretty neat to use the FTDI as an LA.

    I bought a couple of the 4-bit wide UMFT220XA to implement memory-address based transfer of data to/from a Commodore Amiga.

    I created a replacement memory expansion card, and I have plans to add high-speed file transfer, but have got too many other projects....

    I'll have to read your blog post carefully because I'll eventually need to figure out how to handle/program the FTDI. Which mode, whether to bitbang, how to do so, and so on.

    I've worked fairly extensively with their UART-mode converters, methods exposed through their DLLS, using as a VCPs, etc.

    Keep up the good work, and I'd love to see more code, etc.

    How do you make your graphical timing diagrams?

    thanks!

  2. Adam Fraser-Kruck says:

    Hi Keith!

    your project sounds fun! I'd love to see some pics someday. I know what you mean about too many projects :)

    I've updated the bottom of this post with links to the github repo and a Windows binary for quick speed tests.

    I created the timing diagrams in Google Docs by coloring borders using short cut keys. The arrows are simply a UTF-8 character ↓.

    Adam

Leave a Reply

Your email address will not be published. Required fields are marked *