• Upload SDCC-generated HEX records directly to an FX2LP chip's RAM and EEPROM
• Backup & restore EEPROM (e.g firmware for Digilent's FX2-based FPGA development products)
• Send arbitrary commands to the chip's control endpoint
• Benchmark bulk writes to the FX2LP chip

I have successfully tested it with

• My home-made FX2 board
• The Digilent Nexys2 FPGA devkit

There is a custom PCB which plugs into the MegaDrive cartridge slot, and the Nexys2 FPGA board plugs into that, and draws its power from the MegaDrive. The custom PCB is pretty simple, it contains three 16-bit level converters for converting the MegaDrive's 5V signals to the 3.3V signals needed by the FPGA. Despite being simple, it was pretty difficult to make because it has 0.5mm-pitch chips placed over vias.

The game loads over Hi-Speed USB into the Nexys2's onboard CellularRAM whilst the MegaDrive is held in RESET. When the MegaDrive is released from RESET, the bus is taken from the USB controller and given to the MegaDrive, which begins executing the code.

One interesting problem I've noticed is that the sampled "Sega" song ditty at the start of Sonic the Hedgehog is corrupt - it comes out as white noise. My guess is that the samples are being read directly from the cartridge memory by the Z80 somehow, and during those cycles the 68000's !AS line (which my memory controller uses to time its state transitions) is not strobing, so the Z80 is reading garbage samples. This is just a guess though, I need to do further investigation.

Update: My theory was correct. The Z80 read cycles don't seem to strobe !AS like 68000 read cycles do. I eliminated !AS from the memory controller logic and now it works fine.

The VHDL needs a lot of tidying, and I need to implement the bus arbitration logic to allow USB and MegaDrive memory reads and writes to be interleaved seamlessly by the memory controller, and then I need to work on a DMA controller for doing efficient reads from an SD-card.

• Power the Nexys2 from the MegaDrive's 5V supply.
• Buffer the MegaDrive's 7.6MHz clock using this board.
• Verify that the MegaDrive's clock is actually running at the expected rate (0x73F9XX ~ 7.6004MHz).
• Use one of the Digital Clock Managers on the FPGA to multiply the 7.6MHz clock by 14 to give 106.4MHz.
• Use this 106.4MHz to clock a memory controller state machine, running the on-board CellularRAM at half that frequency.
• Fix up the host interface reference design to eliminate the need to force FSM encoding.
• Benchmark block writes using the Adept tool over USB to the CellularRAM at 3.94Mbyte/s.
• Use a transistor switch to give the FPGA control of the MegaDrive's RESET line.

This 0x73F9 is the top 16 bits of a 24-bit counter giving MegaDrive clocks per second: 0x73F9XX ~ 7.6004MHz

Still to do on this prototype:

• Build a MegaDrive cartridge PCB with an FX2-100S-1.27SV(71) edge connector for interfacing with the Nexys2.
• Implement the 68000 bus reads and writes in the VHDL.
• Build the SD-card interface PCB and write the VHDL for a DMA controller clocking the SD card in SPI mode at ~25MHz.
• Optimise the memory controller to use burst writes of data from the host - this should increase throughput to ~5Mbyte/s.

If you want to look at the VHDL for the host interface and the memory controller, you can download it under a GPLv3 licence from here.

• The layout of the pins usually requires vias to be placed under the chip to allow decoupling capacitors and power routing on the other side of the board, leaving the topside clear for signal fan-out. Unfortunately there is precious little clearance under SMD chips for the through-board conductor to make a good connection with the top-side tracks.
• The lead pitch is tiny, typically 0.5mm.

Today I was able to make my first PCB using a 0.5mm-pitch chip, with vias placed under it. The design was just an intelligent break-out board for the 48-pin SN74ALVC164245 level-shifter. It is available in the 0.635mm-pitch DL package and the 0.5mm-pitch DGG package, which is what I used. I chose this design because the chips are cheap (~£1.50) so it wouldn't have been the end of the world if I failed a few times. The techniques should generalise to bigger, more expensive components.

The following method worked for me; I hope it's useful to someone else.

Layout

If you want to fabricate your latest PCB design at home, you need to start thinking about the implications at the design stage - and that potentially includes modifications to the library components you use. For successful home-made PCBs you need to be very conservative with the pad & track sizes and spacing, particularly where drills are concerned. In Eagle CAD, I used 1.5mm octagons for the via pads, with 0.7mm drill-holes.

Note: In retrospect, it looks like the etchant has made holes uniformly bigger than the 0.7mm specified by the design, so next time I will reduce the CAD drill size to 0.5mm to compensate.

Making the PCB

I used an HP LaserJet P2014 to print the upper and lower layers on to LaserStar film (upper layer mirrored), aligned the two sides using four pieces of blu-tac to hold the film in place (the ink facing inwards), then slid an appropriately-sized piece of double-sided PCB laminate between the sheets and exposed for 150s in an AZ210 double-sided UV box (pre-heated for 120s). Next I developed the board using an SN110 applicator, and etched with ferric chloride solution in a PA210 bubble-tank. Then I used an SN120 applicator to strip off the remaining photoresist, scrubbed the board vigorously with steel wool and then used an SN130 applicator to remove any oxidisation from the copper.

Drilling and Inserting Through-Hole Rivets

To drill the vias I used a Dremel with a 0.7mm bit. In retrospect I think a 0.6mm drill bit would have been better. To make a conductive connection between the top and bottom layers I inserted one of these tiny rivets into each via hole using a Favorit rivet machine from MegaUK.

Next I very carefully soldered both ends of each rivet using lots of flux and trying to avoid large blobs (remember that the chip goes over these vias, and there is only 0.25mm clearance).

Drill the holes and insert the rivets, then solder both sides

Before placing the chip over the vias, I used a multimeter to check the connections between the upper and lower tracks.

Soldering the Chip

Soldering such fine-pitch components is difficult at the best of times, but on a home-made PCB it's harder still. For aligning the chip on the pads I used a USB microscope and a steady hand - no Relentless for me today! For the soldering itself, I used the drag soldering method using a Weller WD1 soldering station and an Cooper NTGW tip.

Align the chip carefully, solder two corners and then drag the iron down each row

Once I finished soldering I cleaned the flux-gunk off with methylated spirits.

The Finished Product

And here it is, the finished product:

You can download the Eagle CAD design files for the board if you're interested:

• testVC.sch
• testVC.brd

If you have a Windows PC, you can download it from here.

Currently it only supports the ATmega162 used in the S-AVR and the Xilinx XC9572 CPLD as target devices. I will add more devices incrementally. For programming the AVR it is extremely fast, programming and verifying the micro's 16 kbytes of flash in ~500ms. You can download the software from github, and build it on Windows or Linux according to this blog post. You can then query the JTAG chain like this:

> sudo host/nj
NanduinoJTAG Copyright (C) 2010 Chris McClelland
Found 2 devices in the JTAG chain:
  Device 0 (IDCODE=0x7940403F): ATMEL ATMEGA162 (rev H)
  Device 1 (IDCODE=0x29504093): XILINX XC9572 (rev C)

The nj program supports a bunch of options:

> sudo host/nj --help
NanduinoJTAG Copyright (C) 2010 Chris McClelland
Usage: nj [-eh] [-d <num>] [-f <fuses>] [-i <inFile>] [-o <outFile>]

Interact with NanduinoJTAG.

  -d, --device=<num>     target device
  -e, --erase            erase the flash, lock bits & maybe EEPROM
  -f, --fuses=<fuses>    set fuses (EX:HI:LO:LK)
  -i, --load=<inFile>    load flash from file
  -o, --save=<outFile>   save flash to file
  -h, --help             print this help and exit

Program an ATmega162

To load the example S-AVR firmware described here:

> mkdir simple
> cd simple
> wget http://www.swaton.ukfsn.org/uploads/2009/01/Makefile
> wget http://www.swaton.ukfsn.org/uploads/2009/01/main.c
> make
> cp firmware.hex ..
> cd ..
> sudo host/nj --device=0 --erase --load=firmware.hex
NanduinoJTAG Copyright (C) 2010 Chris McClelland
Found one device in the JTAG chain:
  Device 0 (IDCODE=0x7940403F): ATMEL ATMEGA162 (rev H)
Fuses = 0xFF99FFFF (EX:HI:LO:LK)
Erasing chip...
Programming Atmel chip using HEX file firmware.hex...
Load operation completed with returncode 0x00000000, numfails=0

Program an XC9572

Have a look at the VHDL in the test000 subproject of this git repo:

entity test is
    Port ( a : in  STD_LOGIC;
        b : in  STD_LOGIC;
        x : out  STD_LOGIC);
end test;

architecture test_arch of test is
begin
    x <= not a and not b;
end test_arch;

The pin assignments of a, b and x are defined in the corresponding ucf file:

NET a LOC=P1;
NET b LOC=P2;
NET x LOC=P3;

In the above pic, input pins 1 and 2 of the CPLD are connected to the least significant two bits of port A, the one driven by the counter program I loaded previously. The CPLD's output on pin 3 is connected to an LED. The result is that the LED lights when both PA0 and PA1 lines from the micro are low. This condition is true immediately after reset, for one second, followed by three seconds where it is no longer true, and so on, a square wave with a 25% duty cycle.

Install Xilinx ISE WebPack and build it as described in the README. The first time you build, it's important to do it from within the WebPack GUI. The XSVF file generated by the Makefile is intended specifically for the JTAG chain you see in the above picture. It's a chain of two devices, the first being an Atmel ATmega162 microcontroller and the second being a Xilinx XC9572 CPLD. If your chain is different, you will need to change either the design or the impact.batch file.

> make flash
impact -batch impact.batch
Release 11.4 - iMPACT L.68 (nt)
Copyright (c) 1995-2009 Xilinx, Inc.  All rights reserved.
:
..\..\apps\nanduinoJtag\host\Debug\nj --load=test.xsvf
NanduinoJTAG Copyright (C) 2010 Chris McClelland
Found 2 devices in the JTAG chain:
  Device 0 (IDCODE=0x7940403F): ATMEL ATMEGA162 (rev H)
  Device 1 (IDCODE=0x29504093): XILINX XC9572 (rev C)
Playing XSVF file test.xsvf...
Load operation completed with returncode 0x00000000, numfails=0

How Does It Work?

JTAG defines four signals:

The signals are named from the point of view of the target device. For example the TDO signal is an output on the target device; it drives the Nanduino's PB5 line, which must therefore be configured as an input:

Each JTAG target device incorporates a sixteen-state finite state machine called the TAP controller:

The state machine transitions according to the level of TMS at the rising edge of TCK. Some states allow data to be clocked into (and simultaneously out of) the target device using the TDO and TDI signals. There are a basic set of operations supported by all JTAG-capable devices, but to do any serious work you need to delve into the device-specific JTAG implementation documentation. For AVR microcontrollers this is described in the data sheets, and describes how to read & write the device's flash, fuses & EEPROM, and more advanced stuff like setting breakpoints and reading the device state.

This is all implemented in the NanduinoJTAG firmware. Each operation is triggered by a set of custom USB commands implemented by the NanduinoJTAG using LUFA. The host-side code interacts with the NanduinoJTAG using LibUSB.

Firstly the directory structure. Each project lives in a structure like this:

src
|
+-apps
| |
| +-nanduinoJtag
|
+-libs
| |
| +-argtypes
| +-buffer
| +-dump
| +-hexreader
| +-usbwrap
|
+-3rd
  |
  +-argtable2-12
  +-LUFA091223
  +-UnitTest++

The idea is to maintain a clear separation between 3rd-party ("3rd") code, my own library ("libs") code and my own application ("apps") code, and to automatically fetch any dependencies, downloading my own libs if necessary from github and building them, and downloading 3rd-party libs and tools from wherever and building them.

The build infrastructure itself is based on GNU make, and it supports Linux and Windows builds.

Windows Builds

The Windows platform introduces some unique challenges. Tooling on Windows is characterised by large-scale tools, usually relying heavily on IDE integration, rather than the more expressive Unix environment which is based on a large number of small-scale tools which cooperate with eachother. So to get off the ground on Windows you will need a couple of prerequisites:

• A functional GNU environment. I do a lot of stuff using Atmel AVR microcontrollers, so I have WinAVR installed, which comes with such an environment, but you will probably get away with a more minimal cygwin or mingw installation, so long as it has basic stuff like make, tar, mv, cp, wget, etc.
• An installation of Microsoft Visual C++ 2008 Express Edition which is available from Microsoft as a free download. The 2010 edition will not work because vcbuild.exe has been deprecated.

Once you have the prerequisites you can go ahead and build an application (this one really does need WinAVR since it contains AVR code)...

C:\temp>mkdir foo-src
C:\temp>cd foo-src
C:\temp\foo-src>mkdir apps
C:\temp\foo-src>cd apps
C:\temp\foo-src\apps>wget http://github.com/makestuff/nanduinoJtag/tarball/master
C:\temp\foo-src\apps>tar xvzf makestuff-nanduinoJtag-*.tar.gz
C:\temp\foo-src\apps>cd makestuff-nanduinoJtag-*
C:\temp\foo-src\apps\makestuff-nanduinoJtag-c9d3c67>make -f Makefile.win32
C:\temp\foo-src\apps\makestuff-nanduinoJtag-c9d3c67>cd ..\..
C:\temp\foo-src>find . -maxdepth 2 -type d
.
./3rd
./3rd/argtable2-12
./3rd/libusb-win32-device-bin-0.1.12.2
./3rd/LUFA091223
./3rd/UnitTest++
./3rd/unz600
./apps
./apps/makestuff-nanduinoJtag-c9d3c67
./libs
./libs/argtypes
./libs/buffer
./libs/dump
./libs/hexreader
./libs/usbwrap

After the build completes you will notice that the requisite dependencies for this particular project have been downloaded and built for you. Where possible I have used the vcbuild tool rather than invoking the compiler and linker directly, so you should be able to run the apps in the Visual Studio IDE without problems.

Linux Builds

Achieving the same thing on Linux is considerably simpler. The requisite tools are usually already installed, and if not can easily be installed using your favourite package manager.

> mkdir foo-src
> cd foo-src/
> mkdir apps
> cd apps/
> wget http://github.com/makestuff/nanduinoJtag/tarball/master
> tar xvzf makestuff-nanduinoJtag-*.tar.gz
> cd makestuff-nanduinoJtag-*
> make -f Makefile.linux
> cd ../..
> find . -maxdepth 2 -type d
.
./apps
./apps/makestuff-nanduinoJtag-c9d3c67
./libs
./libs/dump
./libs/usbwrap
./libs/hexreader
./libs/buffer
./libs/argtypes
./3rd
./3rd/UnitTest++
./3rd/argtable2-12
./3rd/LUFA091223

After the build completes you will notice that the requisite dependencies for this particular project have been downloaded and built for you.

In some cases it's possible to (ab)use some standard device class for what you want to do, but often it's better to just drop down to the more fundamental messaging layer. There are two great libraries out there to facilitate this approach:

• LUFA provides a nice framework for implementing USB device firmware on the AVR8 microcontrollers.
• LibUSB provides a similar framework for cross-platform host-side USB programming, crucially avoiding the need to learn the details of driver development on each platform.

My aim here was to put together a very simple example of a vendor firmware running on a Nanduino and a simple host-side application. And here it is:

avrcalc.tar.gz

There's a README with instructions on how to build on Windows and Linux. Pay particular attention to the directory structure, which follows the build infrastructure described in this blog post.

Code Walkthrough

If you have never done any USB programming before, it would be wise at this stage to familiarise yourself with its fundamental concepts. I learned all I needed from this great tutorial on BeyondLogic.

The firmware is about as simple as it can be. It accepts requests for IN transfers (from device to host) on EP0 having bRequest=0x80, and returns eight bytes or four words: the four arithmetic operations on the wValue and wIndex parameters:

void EVENT_USB_Device_UnhandledControlRequest(void) {
    switch ( USB_ControlRequest.bRequest ) {
        case 0x80:
            if ( USB_ControlRequest.bmRequestType == (REQDIR_DEVICETOHOST | REQTYPE_VENDOR) ) {
                uint16 arith[4];
                arith[0] = USB_ControlRequest.wValue + USB_ControlRequest.wIndex;
                arith[1] = USB_ControlRequest.wValue - USB_ControlRequest.wIndex;
                arith[2] = USB_ControlRequest.wValue * USB_ControlRequest.wIndex;
                arith[3] = USB_ControlRequest.wValue / USB_ControlRequest.wIndex;
                Endpoint_ClearSETUP();
                Endpoint_Write_Control_Stream_LE(arith, 8);
                Endpoint_ClearOUT();
            }
            break;
    }
}

The host side code is just a small utility called ucm ("USB Control Messager") that is bundled with fx2tools. It too is fairly straightforward - most of the code is for accepting command-line arguments. And as you probably guessed, it is generic too - it allows you to send and receive control data from any USB device. The core of the code makes use of this libusb function:

int usb_control_msg(
    usb_dev_handle *dev,  // the device we're talking to
    int bRequestType,     // whether IN or OUT (amongst other things)
    int bRequest,         // the request code, 0x80 in this example
    int wValue,           // the first parameter
    int wIndex,           // the second parameter
    char *buffer,         // a buffer with/for the data
    int size,             // the number of bytes to send/request
    int timeout           // the timeout in milliseconds
);

From the firmware code above you can see that this firmware only accepts IN requests (i.e data sent from the device to the host). Any attempt to initiate an OUT request results in an error.

Putting It All Together

Once the calculator firmware is loaded into the Nanduino, either with make flip on Windows or make dfu on Linux (and installed the supplied libusb driver on Windows), you can interrogate it with the ucm utility from fx2tools:

>../fx2tools/ucm/ucm -i -v 0x03EB -p 0x3002 0x80 0x0010 0x0002 0x0008 | ../fx2tools/hxd/hxd
00000000 12 00 0E 00 20 00 08 00                         .... ...

The Nanduino takes the two numbers passed to it 0x0010 (16) and 0x0002 (2) and returns four words:

• Their sum: 16 + 2 = 18 (0x0012)
• Their difference: 16 - 2 = 14 (0x000E)
• Their product: 16 * 2 = 32 (0x0020)
• Their quotient: 16 / 2 = 8 (0x0008)

OK, so I admit that a Nanduino makes a poor math coprocessor, but this simple calculator example demonstrates a number of important concepts, which will hopefully serve to get you off the ground quicker.