Bus Blaster - universal fast bit-bang interface for patient enthusiasts

I have long wanted to have some kind of simple and universal hardware interface with several input and output signals, the functionality of which is determined exclusively by software, like the memorable PonyProg programmer . And so that it can be used not only as read / write firmware, but also for debugging programs through JTAG. At the same time, buying something industrial, with my occasional pampering with electronics, is redundant and unprofitable - it required something from a series of "semi-finished products" based on bit-bang .


As you know, modern computers, especially laptops, with hardware ports are not crowded, because most users do not need them. USB adapters for connecting devices with RS232 and Centronics interfaces (colloquially - COM / LPT) work well only within the framework of the main purpose, and it is problematic to do “jerking” on them for a number of reasons. Firstly, most of these adapters can only process data signals (the same Tx / Rx) with good speed, and it processes the control signals with large delays. Secondly, adapters of different manufacturers are hardware incompatible, and the possibilities of non-standard control through the manufacturer’s driver are very limited. Thirdly, almost all drivers use separate USB packets to send commands to the adapter, which limits the frequency of state changes to just a thousand times per second,

Fortunately, FTDI has long been offering a range of USB solutions that focus specifically on high-speed exchange of arbitrary signals. A quick study of the issue showed that the most popular in this regard are the interfaces on the FT232H / FT2232H microcircuits .

Simple solutions

Initially, FTDI implemented in its USB interfaces FT232BM, FT232R and the like two additional modes - asynchronous and synchronous bit-bang. For this, eight or more additional signal lines are added, each of which can be configured for input or output. The buffered data transmitted to the interface from the computer is set on the output lines by the clock signals, the input data is read from the lines, buffered and sent to the computer. Binding I / O to the clock provides good accuracy of intervals - the application no longer needs to take care of maintaining them programmatically.

Thus, instead of the traditional cycle of the type “set the active level on the output line; pause; read the status of the input line; set the passive level on the output line ”, the application generates a sequence of bytes, each of which sets the state of the output lines for one clock period. The sequence is sent to the interface, and from there the same sequence is read, reflecting the state of the input lines. In asynchronous mode, input and output occur independently of each other. In synchronous reading of the inputs is carried out immediately before setting the signals at the outputs, which allows more reliable work with rapidly changing signals.

MPSSE controller

In the H-version of FTDI chips, a multi-protocol synchronous serial controller ( MPSSE ) is added , which hardware implements various clock and data exchange modes. The formation of the signals of the desired protocol is carried out by transmitting to the controller a series of its internal commands that specify the timing methods, the timing of setting / reading signals (at the front or bottom of the clock pulse), the order of bit transmission (LSB / MSB). The controller sends back a sequence of “snapshots” of the input lines. The data transfer rate can reach 30 Mbps.

Through the MPSSE, the JTAG , I2C, and SPI protocols are most naturally implemented.However, almost any “jerkiness” can be easily implemented within the hardware capabilities of the controller.

FTDI offers a comprehensive documentation on the connection and the programming of its interfaces, libraries and code examples to work through MPSSE under Windows, Linux and MacOS , D2XX drivers to directly interact with the interface.

FTDI interfaces are supported by the popular programs OpenOCD , UrJTAG , flashrom , avrdude , HappyJTAG2 , zJTAG , etc.

Connectivity issues

Having found out all of the above in detail last year, I was inspired, but immediately found that the FT232H / FT2232H, with all its versatility, can not always be connected directly to the final device. Firstly, the external lines of the circuits are designed for the level of 3.3 V, and in many modern devices the levels of 2.5 / 1.8 / 1.5 V are used. Secondly, the output lines cannot switch to the high impedance state and vice versa with high frequency - this is possible only at the initial setting lines by selecting the “input” or “output” mode. That is, to connect a chip with MPSSE to the target device, a buffer circuit is needed that matches the signal levels and provides an operational shutdown of some output lines (for example, with a passive TMS signal level/ Cs ).

Googling on the options for buffer circuits, I found that an incredible number of adapters have been made in the world, differing only in this buffer. Some programs (but not all) allow the use of different types of buffers. So, choosing a specific adapter model, at the same time you limit the range of programs that will work with it. And in order to decide on the type in advance, it was necessary again to carefully google and read the discussions on the forums, which I did not want to do at all. Some adapters allowed to set the buffer configuration with jumpers, but this is fraught with errors, and they are not cheap.

Bus Blaster - claim to versatility

Male idea of Dangerous Prototypes was original twice: the first - as a buffer connected to FT2232H chip PLD (CPLD) Xilinx XC2C32A , which can be quickly reprogrammed under any configuration, and the second - to its use reprogramming FT2232H second channel. In addition to implementing the buffer logic, the FPGA performs level matching - its external lines operate in the range of 1.5-3.3 V.

As a result, the Bus Blaster board turned out. Since the advent of the project, four versions of the board have changed. Version 3 is considered to be the most stable and widespread. Version 4 contains a large FPGA that is not fully developed and is used much less frequently. The next versions, apparently, will no longer be, since the development of the project was stopped a couple of years ago. I got the impression that few people really tried the board - with its high potential, it is not too easy to use. A section of the forum has been created for the board , but since last year almost nothing has been written there.

Upon reflection, I ordered on version AliExpress 3c , as the most developed, for $ 34. Then they were sold there by a store from the manufacturer - Seeed , and now only dealers from $ 52 sell it.Directly at Seeed (along with shipping) it will cost somewhere in $ 37.

First impressions

The board looks exactly the same as in the picture - beautiful, neat, made with high quality. At the forum, someone complained about the lack of output of the microcircuit, so I carefully examined my under a magnifying glass - I did not find any defects. I already had

D2XX drivers installed earlier, so the board was recognized on the go. The first step was to deal with programming buffer logic in FPGAs. This is done using the UrJTAG program , but specially adjusted for Bus Blaster for proper access to the second FT2232H channel.

First you need to download and install the basic version of UrJTAG . Then you need to add a modified EXE-file and a description of the FPGA (BSDL) from this package. To program the embedded FPGA, you need to run a modified EXE, to work with external devices - the main one. FPGA programming procedure is described here . For convenience, you can create scripts for UrJTAG for each version of the buffer, and CMD files with command lines to run them.

A collection of FPGA firmware that describes buffers compatible with JTAGkey , KT-Link, and PicoTap adapters is available here , but for BBv3 there is only one file for JTAGkey with support for self-testing (BBV3-JTAGkey-selftest-v1.1.svf). Most of it is enough, but it didn’t work for me with flashrom , which will be discussed below.

Having written this firmware into the FPGA, I put jumpers in the connector for self-testing, as described in the documentation , closed the P28 line (IO09) to the ground - the LED on the board lit up. I downloaded and launched the testing program - it showed that everything is in order.

It is strange, by the way, that the self-test program is called "BusPiratev2Test", because Bus Pirate is a completely different project, not compatible with BB .

At first, I generally believed that this firmware was intended only for self-testing, and for “military” applications some other kind was needed, because the description says something inaudible. Then I found out that the firmware is universal, just the test mode in it is turned on by shorting P28 to the ground.

Attempted Targeting

Once you have downloaded from here (now there is, alas, 404) flashrom v0.9.6.1-r1704 / the Win32, and sealed-off with some kind of a dead motherboard chip MX25L8005 (the SPI), tried to read it on the command line " -p ft2232_spi: type = busblaster ". However, flashrom said it could not find the FT2232. Reading the documentation showed that it works only through libusb - a universal interface library, originally written under Linux, and then ported under Windows.

Through libusb, he found the interface, but stubbornly claimed that he did not see the microcircuit. Found in the box with the fruits of necrophilia some other SPI-chip - also does not see. Poked by an oscilloscope - TMSstirs, TCK is, TDO is on, and silence on TDI . In general, not a single surge. I connected the oscilloscope channels simultaneously to TCK and TDO - the signals change synchronously, clearly. There were no ideas about what could be verified yet.

Temporarily giving up experiments with flashrom, connected to the ATTiny13 interface . Downloading here a few different versions avrdude , with version 5.11-Patch7610 / Win32 and the type of programming 2232HIOfinally got a clear identification, reading and writing of the controller. After rejoicing, he reconnected the SPI chips, but flashrom stubbornly refused to recognize them.

Suspecting that both microcircuits are dead, he pulled out USBASP 2.0 , which was interchanged for AsProg - he read both of them without problems (albeit very slowly). By the way, I bought three USBASPs in general for the role of convenient prototyping boards on ATMega8, but the device turned out to be unexpectedly multifunctional.

I connected the microcircuits to BB again and started trying flashrom in different modes (Bus Blaster and JTAGKey), with different divider values ​​( -p ft2232_spi: type = busblaster, divisor = n) Suddenly, in one of the combinations, the microcircuit was recognized, but already refused to read. After a few more attempts, the identification also disappeared. Then several times it was possible to obtain several successful identifications in a row, but reading was never achieved.

Posted in the forum, but received nothing sensible in response. Having rummaged in the search, I found several people's complaints about the universal (with self-testing) FPGA firmware, I found three more firmware versions there, tried them in different combinations with other parameters, but did not succeed. Having exhausted all the options, he abandoned the experiments until the arrival of the logic analyzer ordered a little later BB.

Testing with an analyzer

Having received a clone of the popular Saleae Logic 16 logic analyzer , he connected it to all four SPI lines . The program, available for free on the Saleae website , can decrypt I2C, SPI, and several others, so it immediately showed the decryption of all packets - both sent and received. It immediately became clear that the packets are “floating” - the same sequence of bits is grouped by the program into packets at different boundaries over and over again.

Comparing the signal diagrams on the datasheets of the microcircuits with the recorded ones, at some point I noticed that the TMS signal (connected to the CS pin) at the beginning of each exchange session, it goes to a low (active level), in which it remains, although according to the protocol it should return to a high (passive) at the end of each operation. I changed the “official” firmware of the FPGA to one of the alternative ones - TMS started moving more actively, the borders of the packets aligned on it, and after selecting the clock frequency divider in the flashrom command line (stopped at 8), the microcircuit finally began to respond clearly to each request, read and overwrite .

Surprised that I did not immediately pay due attention to the behavior of TMS , I realized that I was confused by the successful work with AVR on the same FPGA firmware. Looking at the ATTiny13 datasheet, I found that the RESET signal , which TMS starts upmay be low during the entire exchange time; its rise for synchronization is not required. And SPI-chips need its rise for synchronization.

As a result of testing, I brought together information about three well-known FPGA firmware in one forum post .

FPGA rewrite limit

In one of the discussions I came across a warning that the guaranteed number of cycles for rewriting the firmware of this FPGA is only about a thousand. At first I was upset, because during the experiments I managed to change the firmware about a hundred times, and already imagined the imminent death of the chip. It costs just nothing, but I do not want to mess with the soldering. Then he realized that with an adequate approach, the remaining nine hundred cycles would be enough for many more years.

In-circuit flashing of ROM in the router

After a while, I formed a freshly baked mini-router on the RT5350F under the code name "ZLMNet H-G5 / P8201" (designations taken from the web interface). Around the same time, the clip for SOIC8 / SOP8 arrived too - I decided to try in-circuit work with the ROM.

At first, flashrom did not see the EPROM through BB at all. The oscilloscope showed that the processor invariably defeated the struggle between the FPGA and the processor of the router for signal levels of CS and CLK . What is not surprising - in BB between the FPGA terminals and the connector there are current-limiting resistors that save low-current FPGA keys from burnout.

I connected USBASP with AsProg - this one reads / writes normally, but again damn slowly (9 minutes to read, 25 minutes to the erase-write-check cycle). For a single revitalization of a brick, it is still acceptable, but for experiments with unstable firmware it is no longer there. Moreover, AsProg does not know how to work with individual pages - only with the entire microcircuit.

I soldered between the TMS / TCK outputs in BB and the CS / CLK inputs of the EPROM for the emitter follower - the signals immediately reduced to almost the correct levels, the flashrom chip recognized, began to read / write confidently. With a divisor of 8, a full read takes less than a minute, rewriting takes about two minutes.

It turned out that the communication of the programmer with the EPROM does not interfere with the processor at all - the router is working perfectly. Obviously, the CS / CLK lines are allocated only for the EPROM, which is read once at boot, after which the processor does not access it, unless you start flashing it with regular means.

Disadvantages of BB programs

The tested programs (zJTAG, flashrom, avrdude, UrJtag, OpenOCD) that can work with MPSSE made a very sad impression. First, in most of these programs, with all the variety of FTDI adapters, there is no explicit indication of VID / PID - identifiers of known adapters are hard-coded into the code. But for JTAGkey, which emulates BB, PID is set to CFF8, and for “clean” FT2232H it is set to 6010. Of course, you can change identifiers in BB using FT_Prog , or patch the table in the program, but both options are equally crooked. Well, it was possible to find a version with support flashrom BB, compiled under Windows (otherwise would have had to put CygWin), and avrdude normally works when you specify the type of programming 2232HIO .

Secondly, some programs work with the adapter only through the libusb library , which, in turn, works through its own driver, which is incompatible with FTDI drivers. It’s good that in Windows, to switch between drivers, you don’t need to completely remove one and install the other - you just need to “update” it by forcibly choosing the right driver for the given device (channel A or B).

conclusions

Now, recalling the cumulative amount of time and nerves spent on all the experiments described, I understand that the price of external elegance and the seeming universality of the solution turned out to be prohibitive. I spend this time additionally on the main work - I would earn some serious industrial programmers and debuggers. But the undoubted plus is that such exercises at least somehow allow you to refrain from the final slide into the net consumption of ready-made customized modules, which the Chinese offer in abundance. In this sense, it is possible to envy the ancient and medieval engineers - for decades they could enthusiastically solve problems long ago solved in some pair of thousands of kilometers in the neighborhood, just not knowing about it.

We should try OpenOCD and JTAG on some of the available routers, but everyone doesn’t get their hands on it.

Dangerous Prototypes also has an older Bus Pirate project . There is a PIC board and a simple interface FT232BL in the traditional serial mode. To communicate with the controller, a regular terminal and text commands are used, the answers are also displayed in text form. avrdude, flashrom and a number of other programs can also work through BP, however, for obvious reasons, the speed is several times lower. The low speed is compensated by the breadth of application - there are many options for using BP to emulate various protocols.

Thinking that in this life you need to try everything, I ordered BP v3.6with cable. Yes, yes, I remember about the mice on the cactus, and about "tomorrow I will go there again."