So, just a brief overview here of the Logicport Logic Analyzer and it’s top-line features and set-up. When I set out to figure this thing out, I took a decent “known” set-up that was running a not terribly complicated, but still useful protocol — SPI. As it happens, the Playstation 2 communication between its controller is roughly the SPI protocol, so that’s as good a test as any, seeing as I had been doing some work with the PS2 anyway.
I wrote a bit about that set up already, so this is the part where I describe how I set the Logicport up. Here are links to two other posts related to the Logicport.
PS2 Logic Analysis
Logic Analyzer
There are three main features of the Logicport I’ll describe — Interpreter’s, Triggers and Measurements. (I’ll also briefly describe some of the basic set-up things that I learned.) Interpreters are like templates for specific protocols. The Logicport supports four protocols as these Interpreter “templates — I2C/TWI, SPI, RS232 and CAN 2.0A/2.0B. For the work done at the Near Future Laboratory, we’re basically covered with these.
Creating a new Interpreter from one of these templates is pretty easy. Just with the case of a SPI Interpreter, your job is to specify which of the Logicport’s channels is probing which of the standard SPI channels. In my setup, I configured two different Interpreters — one for the “master” side and one for the “slave” side. On the master side, the Interpreter probes for the MOSI (master-out, slave-in), SCK (serial clock) and SS (slave select — active low) channels. The “slave” side the Interpreter probes for the same stuff, except the data moves across the MISO (master-in, slave-out) channel.
The Interpreter configuration window also allows you to specify a whole bunch of other useful things. First off is the bit order. The PS2 SPI style protocol sends data least-significant bit first, which is okay, but opposite of the canonical SPI protocol. Fortunately, the Interpreter allows you to specify this. You can also tell it how many bits to interpret as data, and what format you want that data to be represented — Hex, Binary, Decimal, Signed or ASCII. So, that’s super useful.
In the lower image above (click it to enlarge it if you need), I’ve set up this additional slave Interpreter, called PSX-MISO-4, to take advantage of a few additional features of the Interpreter. What I wanted to do was isolate the 5th byte of slave data. So, the fifth chunk of information sent by the slave across the MISO channel. In the PS2-controller communication, this represents the right bank of buttons on the controller — triangle, square, circle, ex — as well as the front triggers — L1, L2, R1, R2. (Here’s more information about the frames of data and what they represent.) So, simply for convenience and to make things easy to interpret, I can specify that this particular Interpreter ignore the first 32 bits of data — four bytes — and just start interpreting and showing the data afterwards. Because I _really_ want to isolate this one byte alone, I also tell it to ignore basically everything else after it does the interpretation of the fifth byte — so I just say, ignore the next 800 bits.
[ad#ad-4]
And, you can see in that second image above, that that one byte is represented in binary, which is useful because each of those switches can be interpreted as a 1 (switch open) or a 0 (switch closed or pressed) without converting from decimal or hexadecimal. Here I’m holding down the triangle and ex buttons simultaneously, so bits one and three are 0.
You can also see that the SPI Interpreter allows you to specify the SPI “mode” — clock phase and clock polarity. This can be useful for trying to figure out how an unknown part is actually operating. In my experience, this can be one of the two or three serious “gotchas” when debugging SPI.
Triggers are probably the first thing you’ll set up, but I guess the second thing I’m describing, partially because I haven’t had any complicated triggering scenarios. In the case of the SPI protocol, you want to trigger when the SS line goes low, or active. This is basically saying that the master is beginning to communicate with the slave, which is usually where your interest starts. And this is what this particular Trigger configuration specifies — Trigger when Edge A occurs once. In the main Logicport window, I specify Edge A as a falling signal on the SS line. Easy-peasy. More complicated triggers could be specified, including the variations you can see greyed out in the configuration window. If you had lots of parallel data from a data bus or something you could specify a specific data value, for example. (One thing that would be nice would be to trigger on a specific SPI MOSI value or a specific I2C device address but for reasons I don’t entirely understand, it was explained to me that this is the equivalent of time travel or something. The work-around is to create a debug trigger on an unused signal from your device to indicate that the thing you want to start watching is now happening and use that signal to trigger the Logicport. Fair enough.)
Finally, Measurements. Another very useful and very configurable-y feature. Measurements use either a set of six movable “cursors”, the trigger point or a specific channel to make time-based measurements. You use this Measurement window to specify what you’d like to measure and what you will use to make that measurement. Here I’m using all of them. First, Measurement A is a frequency measurement, using the built-in Hardware Counter (nice..). With this kind of measurement, I have to specify the source, but not in the Measurement Setup window, strangely enough. In the top of the main window, I specify the Measurement A Source as channel D6, which is the blue/white wire from the Logicport. In this case I have clipped that wire to the clock out (CLKO, PB1) of the Atmega324 that’s sitting on my STK500 break-out board. This simply routes the clock signal that the Atmega324 is using to that specific pin. I’ve got a 16MHz crystal connected to the XTAL pins, and so I see a roughly 16,000,000 Hz frequency measurement for Measurement A, as shown in the bottom part of the main window.
Measurement B is a time interval between Cursor A and Cursor B. That’s basically the clock period of the SCK, the SPI clock, which comes out to be 2uS. Measurement C is the same thing, only the frequency of the SPI clock, or 500KHz. Finally Measurement D is the time between Cursor C and Cursor A, which is the time between SS going low and the first bit of MOSI data, 20.1uS. (I could have also specified “Trigger” instead of Cursor C, which might’ve been more accurate.)
These are the main Logicport features I’ve used to get a basic understanding of how it works. It’s pretty straightforward, particularly for simple set ups like this. The other configurations I’ve had to tweak in order to get good analysis has been the sample rate and the logic levels. I’ve had to vary the sample rate, especially when putting a microcontroller on here that’s faster than the sample rate. With the PS2 on its own, and if I’m not measuring signals from a faster microcontroller, I can slow the sample rate down to 1 or 5 MHz. (Not that it matters a whole lot, unless I want to acquire more total samples.) The logic level specifies what counts as logic high (1) and logic low (0) for the logic analyzer. If you specify it too high, your data will go away, or appear flakey, mostly because the logic analyzer is starting to interpret noise or other spurious signals. And, speaking of noise, the Logicport has four wires that are grey wires with black heat shrink. These are for grounding the device to other things, which is crucial to avoid noise. In the case of my setup, I have one grounding the PS2 and another grounding the STK500 breakout board. This creates a common ground across all three boxes and basically eliminates spurious data and other signaling weirdness.
