Hardware design overview

From DP

Jump to: navigation , search

Ols-cover.jpg

Openbench Logic Sniffer is an open source logic analyzer. It's designed to support the SUMP logic analyzer software at the lowest possible cost. Download the source and design files from the Gadget Factory project page.

This project started in the comments on a post. Initial circuit design, PCB layout, development, and testingcontinued in the forum under the code name Project SUMP PUMP. Many, many people contributed ideas and advice, the Gadget Factory and Dangerous Prototypes coordinated circuit development and routed the PCB. We borrowed heavily from the Gadget Factory's Butterfly Platform.

The Open Logic Sniffer is a purpose-built logic analyzer board designed to be low cost but high speed. It sacrifices a lot of the features you'd look for in a full-scale development board to achieve our primary goals:

  • 70MHz+ sample speeds
  • 32 channels
  • 16 buffered, 5volt tolerant channels
  • USB interface, USB powered
  • USB upgradable everything
  • Make it as DIY as possible
  • Make it as open source as possible
  • $30-$40 price range

We didn't quite hit our initial price range, but we got really close.

You can get your own assembled Open Logic Sniffer at Seeed Studio for $45, including worldwide shipping. Continue reading about the design and collaboration below.

Contents

Concept Overview

SUMP

Sump-dataii.png

SUMP is an open source Java logic analyzer client by Michael Poppitz. It consists of two parts, a VHDL logic capture engine for FPGAs, and a Java logic analyzer client. The latest development version of the SUMP client is available from SourceForge.net.

SUMP is a sampling logic analyzer. It reads the state of the input pins and stores the samples in internal ram. It then dumps the samples back to the computer client for analysis. The number of samples possible is limited by the RAM in the FPGA.

We like SUMP because it's the best developed open source logic analyzer toolchain currently available. It has lots of professional features like multi-stage triggers, configurable pre-roll, external trigger and clock sync, and a few protocol analyzers (I2C, UART). It's open source, so the potential to add cool new features is limited only by your imagination and coding skills.

SUMP is typically ported to a general-purpose FPGA development board. We took a different approach and designed hardware specifically for SUMP, while constraining costs wherever possible.

Other logic analyzers

Professional logic analyzers have tons of channels and super high speeds. We're not trying to make a low cost DIY version of these tools, the OLS isn't an alternative to these types of tools if you need to sniff 100MHz+ signals and have huge sample sizes.

Being an engineer's tool, there are plenty of DIY logic analyzer designs. Parallel port based logic analyzers used to be all the rage, but with parallel ports and direct interrupt access disappearing from systems, these are just historical curiosities.

Another type of DIY logic analyzer is a microcontroller-based device. There are several with custom interfaces like the PIC Logix, Scanalogic, and AVR Logic Analyzer. The Bus Pirate works with SUMP. Microcontroller analyzers all have one thing in common: they're really slow, usually sub-megahertz.

USB IO chip-based hobby logic analyzers are currently popular. We've always been fans of the Saleae Logic, the USBee is similar. These devices are just a USB IO chip like a CY7C68013A-56PVXC, with all trigger and processing logic done in software on a computer. The hardware part is just a datalogger. The top sampling speed is usually around 24Msps (24MHz), if the conditions on your USB bus are just right. They can take 'unlimited' samples because everything is stored on the computer. Current models tend to be 8 channels, more channels would reduce the maximum speed proportionately. These are commercial products with highly polished user interfaces, we don't know of any that are open source.

The Open Logic Sniffer sits somewhere between hobby analyzers and professional analyzers. The OLS samples up to 200Msps, regardless of the USB bus traffic, and has true hardware triggers. The OLS has twice as many buffered channels as most hobby USB analyzers, and four times more channels overall. The major difference is that the OLS has a limited number of samples, while the hobby USB analyzers can theoretically take infinite samples. Most of our debugging is done with the first few hundred samples, so this feature isn't usually important to our work, your situation may be different. Future versions of the OLS will definitely have more sample storage, and we can work an infinite sampling mode into a future firmware update too.

Our Design

La block diagram ver1-490.png

Click for a full size circuit diagram [PNG]. This circuit diagram, maintained by Uwe Bannow, shows the basic elements of the Open Logic Sniffer hardware. The FPGA captures logic samples from 32 input pins into internal RAM. The samples are dumped out a serial port for analysis on a computer. The open source SUMP logic analyzer client is used to capture and visualize the samples.

The FPGA only communicates over a serial port, so we used a USB microcontroller to convert the serial IO to a USB virtual serial port. The entire chain is upgradable through the USB connection. The microcontroller can program updated logic analyzer designs into the SPI flash data chip, and the microcontroller can also be updated from its USB bootloader.

We chose a USB microcontroller over a dedicated USB interface chip. A low pincount PIC was cheaper than most other USB bridge options. It's USB 2.0 compliant, and can transfer data at up to 12Mbps. We're using it with the completely open virtual serial port CDC interface, so it will work on almost any platform without proprietary drivers. The PIC can also implement other USB transfer protocols with a firmware update, faster connection methods can be supported when someone adds support for them to the SUMP client software.

Currently the SUMP FPGA design only transfers data over a 115200bps serial UART, the speed between the USB PIC and the computer isn't a bottleneck. We routed several extra connections between the PIC and FPGA to implement a high-speed SPI interface in the future. The speed increase of an SPI interface can be supported in the SUMP client just by adding higher serial port speed settings.

An FTDI2232 chip was strongly considered as an alternative to the PIC. Here's how we looked at it:

Benefits of the FTDI2232 with MSSP:

  • JTAG interface to debug the FPGA
  • SPI interface to program the ROM
  • SPI and UART interface to the FPGA

Cons:

  • Difficult to route
  • Expensive to place
  • Huge software development burden
  • Needs special drivers
  • USB interface not already supported by SUMP

With so much to accomplish already, major modifications to the client to work with untested hardware and custom drivers didn't seem appealing. Not if the project were ever going to get finished. The PIC seemed like the best route for the first version.

Hardware

Cct-fpga-490.png

Click for a large image of the schematic [PNG]. The schematic is divided into a microcontroller part [PNG] and a FPGA part [PNG]. These sections are where Ian and Jack initially split the design work. We used the freeware version of Cadsoft Eagle to make the circuit and PCB. Download the latest files from the Gadget Factory project page.

FPGA

Fpga-highlight.jpg

A Xilinx Spartan 3E field programmable gate array (FPGA) is the central component of the logic analyzer. The FPGA samples data from 16 buffered and 16 unbuffered IO pins, and stores the samples in internal RAM. The samples are later dumped out a serial UART to the PIC, and from the PIC to a computer via USB.

The basic FPGA schematic and PCB layout is taken directly from the Gadget Factory's Butterfly Platform main board. The OLS shows how versatile the Butterfly Platform is as a development tool. The initial designs where first tested on the Butterfly Platform, and then we used the base design to create a unique, purpose-build hardware based on the prototype. You can get a Butterfly platform to build your own prototypes at the Gadget Factory for $99.

Fpga-detailii.jpg

The FPGA (IC3) requires three different power supplies. The core requires 1.2volts and 2.5volts, and the IO pins run at 3.3volts. Each supply pin gets a 0.1uF decoupling capacitor (C11-26). We brought the JTAG programming and debugging connection to a header in the interior of the PCB. The JTAG header provides 2.5V to external JTAG programmers to satisfy the Spartan 3E's requirements for 2.5V on the dedicated JTAG pins.

Fpga-statusii.png

Several control and indication signals require special attention. INIT_B enables the FPGA when high, it's held to 3.3volts with a 4.7K pull-up resistor (R6). The DONE signal goes high to indicate that the FPGA is configured and ready to use after a reset. It's held to 2.5volts by a 300 ohm resistor (R1).

PROG_B, held at 2.5volts by a 4.7K pull-up resistor (R5), can be pulled low to put the FPGA in programming mode. The HSWAP pin (not shown) determines if all pins have pull-up resistors in programming mode. We grounded HSWAP so that all pins have weak pull-ups when PROG_B is low.

FPGAs are volatile programmable chips, they lose their configuration without power. The FPGA configuration, called a bitstream, has to be loaded into the chip each time it starts. We configured the FPGA to automatically load a bitstream from an SPI ROM chip by wiring the mode select pins as follows: M0(3.3volts), M1(0volts), M2(3.3volts).

Fpga-osc-detail.jpg

The FPGA runs from a 50Mhz oscillator(Q2). This is a complete clock generation module, no external capacitors are required. The 50Mhz clock is doubled to 100Mhz by an internal Digital Clock Manager (DCM) to provide the 100Mhz clock required by the VHDL core.

Fpga-led-detail.jpg

Two LEDs indicate the FPGA status. The ARM LED indicates when a trigger is set and the device is actively waiting for the trigger. The TRIG LED indicates when a trigger has been activated. We used 390R current limiting resistors (R8, R9) on the prototype, but the assembled board should ship with 1K1 resistors to make the LEDs dimmer.

Buffered inputs

Buffer-dia.jpg

The FPGA IO pins are powered by 3.3volts, and can tolerate no more than a 3.3volt signal. The M74LCX16245DTR2G buffer (IC4) allows 16 buffered pins to sniff 5volt logic and can tolerate voltages from -0.5 to +7V. This chip is also powered by the 3.3volt supply, and it gets a 0.1uF decoupling capacitor (C9) on the supply pin.

Clock/trigger headers

Middle-headers-detail.jpg

The logic analyzer can sync with other test equipment and should allow OLS's to be daisy chained together for more channels. It can be driven by an external clock and trigger, and it also outputs its internal clock and trigger. You can tap these signals from the some-what awkwardly placed pin block in the middle of the PCB. The external clock input had to be on an FPGA global clock pin, this was the best possible location to access it because no sensitive high-speed signals were routed across other traces.

Wing header

Wing.jpg

A wing is an accessory for the Gadget Factory Butterfly Platform development board. It uses a standardized header and pinout. The header has 16bits of 3.3volt IO, and 2.5, 3.3, and 5volt power supplies.

We added a wing header to the OLS so it can use accessories developed on the Butterfly Platform, like a digital sampling oscilloscope. This has the added benefit of making the OLS compatible with a bunch of existing Butterfly Platform accessories.

ROM

Rom-dia.jpg

The FPGA programs itself with a bitstream stored in a 4Mbit AT45DB041D SPI flash storage chip (IC2), we refer to it as a ROM. We previously demonstrated this chip with the Bus Pirate. It's powered by the 3.3volt supply, and requires a 0.1uF capacitor (C10) on the supply pin. The XC3S250E bitstream will fit into a 2Mbit flash chip, but only 4Mbit chips were available when we sourced parts.

The ROM chip has an SPI interface that connects to the FPGA, the PIC microcontroller, and an external programming header.

  • The FPGA mode select pin configuration causes the FPGA to load a bitstream from the ROM chip. When the bitstream is finished loading, the DONE signal goes high, and the FPGA is programmed and active.
  • The PIC can (re)program the ROM with updated bitstreams. The PIC holds the FPGA PROG_B line low in this mode so the FPGA releases control of the ROM chip.
  • The external header can be used to program the ROM from a programmer. Place a jumper between the PGM and EN pins to manually place the FPGA in programming mode.

Microcontroller

Uc-highlight1.jpg

A PIC 18F24J50 microcontroller (IC1) is the interface glue. It has these functions:

  1. Provides a USB->serial connection from the SUMP Java client to the SUMP hardware in the FPGA
  2. Puts the FPGA in programming mode and updates the ROM with a new bitstream
  3. A USB bootloader can be used to update the PIC firmware

The 18xxJxx chips are really interesting, and seem like a hybrid of the 24F and 18F families. This PIC has the instruction set and 8bit core of the 18F family, but many enhanced features of the 16bit PICs. Half of the UARTs and SPI modules are assigned with peripheral pin select, it has flash configuration words, and it runs on 3.3volts, like a 16bit PIC.

The PPS features are really handy and make the clean layout of the PCB possible. The ROM SPI connection and FPGA UART connection are both assigned to custom pins with PPS. PPS can be used to implement a high-speed (10Mbit+) SPI connection between the PIC and FPGA in a future firmware upgrade.

Uc-detail.jpg

The PIC is powered by 3.3volts, the supply pin gets a 0.1uF capacitor (C7). The USB peripheral has a separate 3.3volt supply pin that also needs a 0.1uF decoupling capacitor (C8). A 10uF capacitor (C4) is required for the internal 2.5volt core supply regulator.

Ucxtal-detail.jpg

An external oscillator provides an accurate USB clock, we used a 20MHz crystal (Q1) and two 27pF capacitors (C5, C6).

Buttons-detail.jpg

A 10K resistor (R3) holds the PIC reset pin high for normal operation, the RESET button (S1) grounds it to cause a hard reset. A second button (S2, R4) is available for simple user input.

Led-detail.jpg

The LED ACT is a general purpose indicator LED controlled by the PIC through current limiting resistor R7. The PWR (power) LED is connected to the USB supply though current limiting resistor R2, it illuminates whenever the board is powered.

We also brought the one of the hardware UARTs to a header. The pins are 5volt tolerant, and can be interfaced at up to 5volts without damaging the PIC. This header can be used for a 'classic' serial port connection. The board can also be powered through the UART header supply pins.

Power supply

Vreg-dia.jpg

The board is intended to be powered by the 5volt supply from a USB port. Three regulators provide the three supply rails required by the circuit. All the chips require a 3.3volt supply (VR1), the FPGA also requires a 1.2volt (VR3) and 2.5volt (VR2) supply. As recommended by the datasheet, there's a 10uF capacitor (C27) on the supply line, and each regulator has a 1.0uF capacitor (C1-3) on the output pin.

Numbering

The OLS has two different numbering schemes, one on the inside of the board and one on the outside of the board. The inside numbering scheme starts with zero on the buffered header. The outside numbering scheme starts with zero on the Wing header. Currently the numbering scheme can be selected by loading a bitstream that implements either numbering scheme. Future updates will support selecting the numbering scheme through the Java Logic Analyzer client.

PCB

Logicsniffer-v1rev1.jpg

We used the freeware version of Cadsoft Eagle to make the schematic and PCB. Download the latest files at the Gadget Factory project page.

The PCB is nearly the maximum allowable size in Eagle. All the components are surface mount, but we stuck with traditional through-hole headers. It took us an hour or two to solder each prototype board by hand.

We had boards made with the $50 Seeed Studio Fusion board service. This design probably would have been ready a bit sooner, but the PCBs were delayed about a month by the major Hong Kong Post Christmas mail rush.

Partlist

Logic-Sniffer-brd.png

Click for a full size placement image [PNG]. Uwe Bannow generously provided parts for the OLS prototypes. An extra special thanks to Uwe, his help was key to making this project what you see today.

Part
Quantity
Value
Package
C1-C3
3
0805
C4,C27
2
SMC_A
C5,C6
2
0805
C7-C26
20
0603
IC1
1
SO-28W
IC2
1
SO-08W
IC3
1
VQ100
IC4
1
TSSOP48
J1
1
SMD
LEDs
4
0805
Q1
1
HC49UP
Q2
1
OSC1
R1
1
0805
R2
1
0805
R3,R4
2
0805
R5,R6
2
0805
R7-R9
3
0805
S1,S2
2
DTSM-6
VR1
1
SOT23-5
VR2
1
SOT23-5
VR3
1
MIC5205-1v2 (MCP1801T-1202)
SOT23-5
JP7,JP8
2
1X09

SUMP FPGA design

Top Level Schematic

Olsfpga-top-schematic.png

Click for a large image of the Top Level schematic [PNG].

Core Schematic

Ols fpga core schematic 490.png

Click for a large image of the core schematic [PNG]. [1]

Click for a large image of the top half of the core schematic [PNG]. [2]

Click for a large image of the bottom half of the core schematic [PNG].

Get the latest project files from the Gadget Factory project page. The original SUMP project is licensed under the GPL, you can get it at SUMP.org.

OLS Design Changes

The OLS uses the open source (GPL) SUMP logic analyzer VHDL design. It's synthesized with the free Xilinx ISE Web Pack tool suite. Our design is based on Jonas Diemer's Spartan 3E SUMP port [ZIP]. The following modifications were made for the OLS hardware:

  • A new ucf (User Constraint File) was generated to map the pins of the FPGA to the layout of the OLS board and to support multiple numbering schemes.
  • Support for outputting the sample clock to an external pin was added.
  • Support for adding an external pin as a trigger was added.
  • Added support for Trigger and ARM LED's.
  • Files for multiple BRAM memory configurations were added. The files were generated with the Xilinx Core generator and are Xilinx specific.

Memory

The OLS utilizes BRAM (Block Ram) that is embedded inside the Spartan 3E FPGA, the included XC3S250E chip has 216K of BRAM available. There are six bitstreams that allocate the available memory into different combinations of memory depth and sampling channels. Currently the following memory/channel configurations are available:

  • 32 channels with 4k sample depth.
  • 16 channels with 8k sample depth.
  • 8 channels with 16k sample depth.

You may have noticed that the above numbers don't add up to the 216K of BRAM that is available. With 8 channels we should be able to get 216k/8 = 27k samples. The first issue is that the published size of 216K of BRAM includes parity bits, without parity bits we actually have 192K of BRAM available. The second issue is that the Sump design is setup to require a power of 8 for its sample depth, so until the Sump design can be modified we are stuck with the above power of 8 sample depths. Once these two issues are resolved the possible memory/channel configurations will be:

  • 32 channels with 6k sample depth.
  • 16 channels with 13k sample depth.
  • 8 channels with 27k sample depth.

Our future design plans do include working on adding 32-64Mb of SDRAM memory.

Bitstreams

The output of the Xilinx Webpack synthesis tools is a bitstream file that is used to configure the FPGA. We convert the bitstream (*.bit) file to an Intel Hex format (*.mcs) using the Xilinx Impact application. The bitstream is then loaded, by the PIC, into the Atmel SPI Flash chip. When power is applied to the OLS the FPGA configures itself by loading the bitstream from the SPI Flash chip.

There are currently six different bitstreams that provide for 3 different memory configurations and 2 different numbering schemes. Currently, the bitstreams have to be loaded with the pump-loader executable. Future revisions will load the desired bitstream from the Java Logic Analyzer client. The current bitstream options are:

  • 32 channels with 4k sample depth, inside numbering scheme.
  • 16 channels with 8k sample depth, inside numbering scheme.
  • 8 channels with 16k sample depth, inside numbering scheme.
  • 32 channels with 4k sample depth, outside numbering scheme.
  • 16 channels with 8k sample depth, outside numbering scheme.
  • 8 channels with 16k sample depth, outside numbering scheme.

RLE

'Ols rle.png

Run Length Encoding (RLE) helps make the most efficient use of available memory. With RLE enabled memory is only filled when there is activity. If there is a period of inactivity it is represented in memory with a value instead of a large block of empty space. A practical example would be with capturing UART data. In many cases there is a burst of continuous activity while an 8 bit character is sent across the channel, but then there will be a very long period of inactivity before the next character is sent across the channel. Without RLE the available memory would quickly be filled up with empty space and you would only be able to capture one or two characters. With RLE only the activity is captured and the long pauses in between characters is represented with a value that indicates how long the pause is instead. This allows many more characters to be captured. RLE was added to the SUMP VHDL design by Jonas Diemer when he released a BRAM based design. RLE has worked very well with simple waveforms but needs further testing with more complex signals like the UART example outlined above.

Sampling

OLS supports sampling rates from 10Hz (10sps) to 200Mhz (200Msps) and has been able to capture perfect, generated waveforms up to 100Mhz. As a general rule of thumb you need at least twice the sampling rate of the waveform you are capturing. If you are trying to capture a 100Mhz waveform then you need a 200Mhz sampling rate, if you are trying to capture a 50Mhz waveform then you need a 100Mhz sampling rate. In practice this rule of thumb does not always hold up, some sources advise having at least 5 times the sampling rate of a captured waveform. In our tests with repeating, simple, perfect waveforms we have been able to use the twice the sampling rate rule of thumb.

We have seen that the results with the unbuffered 3.3V pins are better at higher speeds than the 5V buffered pins.

Triggering

Ols trigger ratio.png

The Sump VHDL core supports simple and complex triggering on all available channels. Complex triggering supports 4 stages of parallel or serial triggering. Triggers can be configured with how much of the waveform is captured before and after the trigger. A trigger ratio of 50/50 puts the trigger in the center of the captured waveform.

Ols simple trigger1.png

Simple triggering supports a Mask to indicate which channels to trigger on and a Value to indicate whether to trigger on a '1' or '0'. Click on the image above to see how a trigger can be configured to trigger on a value of '1' on channel 0.

For a deeper explanation about triggers take a look at the excellent Oak Micros Logic Analyzer Guide.

Clocks

Clock options.png

The Sump VHDL core is driven by the external 50Mhz oscillator or an external clock connected to the CKI pin, the desired clock can be selected in the Java client. The default is to use the 50Mhz clock which is doubled internally to 100Mhz by one of four Digital Clock Managers (DCM). This 100Mhz clock is labeled as Internal in the Sump client options dialog. The external clock is connected without modification to the sampling section and the Sampling Rate option will be disabled.

Ols sampling rate.png

When the Internal clock is used the sampling rate can be set from 10Hz up to 200Mhz. When 200Mhz is selected a Double Data Rate technique is used and the signal is sampled on both the rising and falling edge of the 100Mhz clock. In this mode the amount of available channels is cut in half to free up memory for the additional samples. For example, if the bitstream is configured to support 32 channels with 4k samples of memory then there is a 4k block of memory that is 32 bits wide allocated within the FPGA. Each channel corresponds to one of the 32 memory bits and is 4k deep. When 200Mhz is selected twice the amount of memory is required to store the samples, so in order to keep the 4k deep sampling space the available channels would be reduced to 16. The bottom 16 bits of memory store the samples at the rising edge and the top 16 bits of memory store the samples at the falling edge.

Proposed Changes

  • Changing the design to support all available BRAM memory.
  • There is a SRAM and a BRAM memory interface available, integrating a SDRAM controller is desirable since SRAM is much more expensive than SDRAM.
  • Replace the UART controller with a SPI controller to enable USB speeds up to 12Mb/s.
  • Add a register to indicate the memory depth, amount of supported channels, and numbering scheme of a bitstream. The Java client could then query the register and give a visual indication of what numbering scheme, how many channels, and amount of memory that the bitstream currently running on the FPGA supports.

PIC Firmware

The latest PIC firmware and source is available from the Gadget Factory project page. The code is written in C, and is compiled with the Microchip C18 demonstration compiler. The bootloader is written in ASM and compiled with the PIC 18 assembler.

We used Microchip's free, but non-distributable, USB stack source code to provide USB support in this project. To compile the firmware you need to download the USB stack source directly from Microchip, then follow the directions at the top of main.c in the OLS source code. A major goal of this project is to create an open source virtual serial port code base to replace the non-distributable Microchip USB stack.

The PIC is the interface glue for the circuit. It has three operating modes:

  1. Normal - a serial port to USB bridge for the SUMP logic analyzer
  2. ROM Updater - upload a new FPGA bitstream to the ROM chip
  3. Bootloader - update the main firmware in the PIC

Normal mode

The PIC usually operates in a transparent USB-> serial bridge that connects the SUMP build in the FPGA with the SUMP client on a computer. This is the default startup mode after a reset or power-up. Press the reset button to enter normal operating mode from any other mode.

After a reset, the ACT LED will blink while the FPGA loads the bitstream contained in the ROM chip. If the FPGA doesn't load after a few seconds, because of an error or blank ROM chip, the PIC will automatically enter ROM update mode and the ACT LED will illuminate (see ROM updater below).

The ACT LED will turn off when the FPGA is configured and ready. The OLS then enumerates as a USB virtual serial port device. The first time you plug it in, you may need to feed Windows the .inf file in the project archive to assign driver to the device.

Once enumerated, the ACT LED blinks to indicate any USB activity.

ROM Updater

ROM updater mode is used to program a new FPGA bitstream into the flash storage chip.This feature lets us release FPGA design updates that can be loaded over the USB interface.

To enter ROM update mode, press the reset button while holding the update button. The PIC will also automatically enter ROM update mode if the FPGA doesn't load correctly because of an error or blank ROM chip. The ACT LED will light in this mode.

The OLS enumerates as a USB virtual serial port in ROM update mode, this is the same connection type as the normal operating mode. The first time you plug it in, give Windows the .inf file from the project folder to assign the correct drivers to the device.

Use the pump-loader console utility for Windows, Linux, or Mac to load the updated FPGA bitstream. There's also a pump-loader.pl Perl utility that we used during initial development.

ROM update procedure

  • Press the reset button while holding the update button.
  • The ACT LED will light and the OLS will enumerate as a USB virtual serial port.

ROM-update-procedure .png

  • Run pump-loader with the -status option to verify that the firmware is listening.

ROM-update-procedure2 .png

  • Use pump-loader to write a SUMP FPGA bitstream to the ROM chip. If you use the -run flag it will exit to normal operating mode when the upload is complete.

Look for more detailed upgrade guides in the Open Logic Sniffer links page. Special thanks to Michal Demin, Piotr Pawluczuk, and Uwe Bannow for working on the pump-loader utility. Michal won our developer's challenge with his lightning-quick coding skills.

Bootloader

We used the Diolan open source (GPL) USB bootloader in this project. The bootloader appears as a USB HID device, and a small utility uploads a new firmware to the PIC. We started with the bootloader source from the Dangerous Prototypes' USB Infrared Toy and ported it to the 18F24J50.

The Diolan bootloader is intended for the PIC18F2550 family of USB PICs. We had to make several modifications to get it working on the 18F24J50:

  • Changed the configuration fuses
  • Added clock switching and PLL startup delay
  • Added register bank switches, where required.
  • Changed sleep mode to idle for 18fx4J50 PLL system
  • Changed page write (64bytes) to word write (2bytes)

One of the big issues we encountered with the port was a difference in flash page write size between the regular and 'j' PICs. The Diolan bootloader supports PICs that write flash memory in 32byte chunks (pages). The 'j' chip writes flash in 2byte or 64byte chunks. The bootloader is designed to send an entire page worth of data in a single USB HID packet. HID packets are 64bytes long, once you include a few bytes of header there's not enough room in a single HID packet to transfer 64bytes of data to write to the flash memory.

Our quick solution was to take advantage of the 2byte word write mode and make a custom compile of the Diolan utility that sends only 2 bytes in each HID packet. This slows down the update because most of the USB HID packet is wasted. It would be far faster to use the 64byte write mode and send 64bytes of data over two HID packets with a flush flag in the second. We hope to improve this with a new upgrade utility, the functionality is already supported in the bootloader firmware.

If you're working with a fresh chip, program the bootloader into the PIC using the 5pin ICSP header. You'll need a PICKIT or ICD programmer to load the bootloader the first time.

Enter bootloader mode by placing a jumper between PGC and PGD pins and press the reset button, or run the pump-loader utility with the -b flag. The ACT LED will light when the bootloader is active. Use the fw_update.exe utility to load new PIC firmware with the bootloader.

Firmware update procedure

  • Place a jumper between the PGC and PGD pins of the ICSP header.
  • Plug in USB. ACT LED lights. Bootloader enumerates as an HID device.
  • Remove the jumper. If you remove it now the bootloader will reset into user mode automatically, if not it will just return to the bootloader.

Firmware-update-procedure.png

  • Run the firmware loader, or just use pump-program.bat.
  • The chip is erased and then (slowly) programmed. Slowly is 30 seconds-ish. If we fix the app it will program in 1-2 seconds.
  • Remove the jumper (if you didn't earlier).

Look for more detailed upgrade guides in the Open Logic Sniffer links page. Special thanks to Piotr Pawluczuk for getting the firmware update utility to compile for us.

Using it

Install Java, the rxtx serial port library, and the SUMP client. The Gadget Factory has a version compiled from the latest source code. There is also a Windows compile of SUMP that doesn’t require you to install Java.

We'll give you a brief overview of the SUMP client below, but be sure to download Oak Micros' detailed SUMP manual.

Sump-config.png

Open SUMP. Press the rocket button. Configure SUMP as shown here.

  1. Change the serial port to match the OLS serial port on your system.
  2. Select channel groups to sample. Group 0 and 1 represent the 16 buffered channels. Group 2 and 3 are the 16 unbuffered channels on the wing header.
  3. The OLS can capture 16k samples with 8 channels, 8k samples with 16 channels, and 4k samples on 32 channels.
  4. All speed settings are valid.
  5. Click capture to start.

Sumptrigger.png

Sampling can also be triggered by a change on one or more pins.

  1. Enable the trigger by checking the enable box.
  2. Check the mask bits to set the state of the input pins that will trigger sampling. Optionally configure multiple trigger stages.
  3. Configure the number of samples to capture before and after the trigger event.
  4. Click capture. The ARM LED lights to indicate that the analyzer is active. A match to the selected pins triggers sampling.

Taking it further

The OLS has been a collaborative community effort. We designed the entire toolchain to be as flexible and upgradable as possible. Here's some of the ideas we have for upgrades and improvements:

  • Implement a high speed SPI connection between the PIC and FPGA to improve sample download speeds. SUMP client will need a minor modification to include higher serial port baud rates, up to 12MBPS.
  • Add more protocol analyzers to the SUMP Java logic analyzer client.
  • The PIC can be configured for other USB protocols for clients that support them.
  • Add bulk transfers for a continuous sampling mode.
  • We're already working on an open source digital sampling oscilloscope wing.
  • Improve the bootloader update speed. Cleanup the firmware update code.
  • Create an open source compatible USB virtual serial port firmware.
  • A future hardware revision may include SRAM or a bigger FPGA chip to store more samples.

Get one!

You can get the assembled Open Logic Sniffer hardware for $50, including worldwide shipping.

If you're interested in FPGA development and designing your own prototypes, check out the Butterfly Platform we used to develop the Open Logic Sniffer. You can get the Butterfly Platform at the Gadget Factory now for $99.

Your support made this open source project possible. Thanks to everyone who contributed to this project with suggestions, advise, or by making a purchase. We couldn't do it without you.

Ols-overviewiii.jpg