Skip to main content
Topic: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :) (Read 3419 times) previous topic - next topic

Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

X

Last year Sjaak and I (mostly Sjaak!) tried to build a modern STM32-based Bus Pirate. Once we got deep into peripherals it was obvious that they weren't suited to a Bus Pirate like interface. This is actually something that crops up a lot. There was the revision B2 silicon bug in the 24FJ64GA002 that forced us to use software I2C. The I2C peripheral in the STM32 needs to know one byte in advance when the transaction will end, something impossible to guess consistently based on human-speed user input. We keep running into situations where the hardware peripherals are limited or down-right standing in our way.

X

When the ICEstorm open source Lattice ICE40 stuff came out, Sjaak suggested we just build our own peripherals in an FPGA and access it through the 16 bit static ram interface on the biggest STM32F103. The Bus Pirate "Ultra" was born.

This summer we've been hacking on V1a. It's the same basic concept as previous Bus Pirates:
  • 5 IO pins, 1 analog pin, two power supplies, and pull-up voltage pin
  • 3.3volt and 5volt power supplies
  • 4 pullup resistors on MOSI, CLOCK, MISO, CS
But we also have some extra goodies:
  • ICE40 FPGA + STM32F103 MCU
  • Fully buffered interface with 1.2 to 5.0volts direct interfacing
  • 2 serial SRAMs for a live-capture logic analyzer
  • A 32Mbit flash chip to hold tons of different bitstreams that can be loaded into the FPGA

Currently everything is in one git repo, but I'll get the firmware, HDL, and hardware separated out today.

Firmware status
  • Basic UI
  • 2 USB CDC endpoints, one for dumping logic analyzer data (will be pure USB eventually)
  • File system for storing and loading the FPGA bitstreams
  • Access FPGA registers and FIFO through 16bit FSMC (static memory controller)
  • Basic interactions with the "Bus Pirate State Machine" in the FPGA
  • Configure SRAMs/logic analyzer. Control capture and dump samples
These things are all working to some extent. We're not to the point of actually talking to any chips with our SPI peripheral, but we can control it and capture the bus activity using the built in logic analyzer. It's so cool!

X

Check this out! This is Bus Terminal, a really crappy Qt program we hacked together. Type commands into the Bus Pirate terminal, and every time you hit <enter> the Bus Pirate runs the commands while capturing the signal. The logic graph updates instantly! No setting triggers, no arming, no trying to get a logic analyzer probe stuck in an odd little place. Boom! You type and then you see what happens! This will be even cooler when we get a driver written for SigRok and have live protocol decoding as well :)

Look at that timing in the logic graph. It is tight, and it is clocked exactly the same each time. That's because the FPGA unbinds us from the USB housekeeping constantly going on in the MCU.

HDL status
  • 16bit static ram interface
  • Control SRAMs for logic capture/dump
  • IO control (enable, tristate, open drain, direction) mapped to registers
  • IN and OUT FIFOs (512 words, but can be 2096 each?)
  • SPI peripheral, PWM
  • Bus Pirate State Machine that processes: read/write bus, delay, start/stop logic analyzer, pin state, and halt instructions

Getting the logic analyzer working was our first priority, and it probably took longer than anything else. Once it was done though, wow, what a delightful development experience. Not only can we see live what is happening with the pins, we can also point the logic analyzer to things inside the FPGA to debug the HDL.

X

This is the basic outline of how it all works. Between the MCU and FPGA there is a 16 bit bi-directional data bus and 6 (?) bits of address pins. The memory controller in the MCU reads and writes through this bus just like it's a local system register. The registers in the FPGA are attached to things like pin mode (enabled, in/out, open drain, etc), logic analyzer stuff, and speed settings.

One register, currently register 7 but eventually register 0, is connected to a 512 word FIFO buffer. The buffer feeds a state machine with commands like write xbits, read xbits, delay, halt, enable/disable logic analyzer. Our current development firmware loads up the FIFO with commands, then enables the state machine. Because this all happens inside the FPGA, everything is exactly the same each time a command is run, down to the clock tick! Sometimes we think the logic analyzer is stuck because nothing changes between runs.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #1
X

You may have noticed that most of the components on the bottom edge of the v1a are not populated. That's because when we started working the design it was obvious that we could push it a lot further with a few tweaks.

First, we dropped the ADC, Vpu, and 3.3V pins. We added 3 more IO pins, giving us 8 IO total. What do you know, that matches the 8 channels available from the logic analyzer :)

Instead of measuring voltage through a dedicated ADC pin, we used an 74xx4015 8:1 analog mux and a op-amp to add low impedance voltage measurement to ALL the IO pins. Woot!

Next, we used the DAC from the MCU to margin a Microchip voltage regulator to get a 0.8volt to 5.0volt adjustable output power supply. This new "Vout" pin replaces the 5volt pin. Bam!

Finally, we double up the 4066s to add optional pull-up resistors to all 8 IO pins. The pull-ups are now powered by the output of the adjustable power supply, or by an external voltage applied to Vout. All the outward-facing buffer logic is also powered in the same way using the Vout pin.

1. MOSI
2. CLOCK
3. MISO
4. CS
5. AUX
6. AUX2 (formerly ADC)
7. AUX3 (formerly Vpullup)
8. AUX4 (formerly 3.3Volts)
9. 0.8-5.0Vout/Vref (formerly 5.0Volts)
10. GND

This is our new pinout  8) Routing on this board is still in progress, but we hope to be stuffing it by early September.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #2
I divided the repo into separate repos so it's less annoying for everyone:

Firmware (old repo): https://github.com/DangerousPrototypes/Bus_Pirate_Ultra
Hardware: https://github.com/DangerousPrototypes/BusPirateUltraHardware
HDL (for FPGA): https://github.com/DangerousPrototypes/BusPirateUltraHDL
Bus Terminal: https://github.com/DangerousPrototypes/BusTerminal

Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #3
Hi Ian.
Really impressive device, it could have been called Bus Pirate v5!
I hope it will soon be developed and marketed.

Be seeing you.

U.Sb

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #4
I divided the repo into separate repos so it's less annoying for everyone:

Firmware (old repo): https://github.com/DangerousPrototypes/Bus_Pirate_Ultra
Hardware: https://github.com/DangerousPrototypes/BusPirateUltraHardware
HDL (for FPGA): https://github.com/DangerousPrototypes/BusPirateUltraHDL
Bus Terminal: https://github.com/DangerousPrototypes/BusTerminal

Real nice. As this is a single project, I would've arranged things a bit differently, kinda in a tree structure so that I just need to pull one repo to access everything. Sth like this:
Code: [Select]
Bus_Pirate_Ultra (repo)
├── firmware/
│      ├── firmware
│      ├── files
│      └── ...
├── fpga/ (or hdl/)
│      ├── HDL
│      ├── files
│      └── ...
├── hardware/
│      ├── hardware
│      ├── files
│      └── ...
└── terminal/
        ├── software
        ├── files
        └── ...

Also one questıon: Is it possible to increase the number of address lines? 6 lines gives us only 64 registers, we will probably hack the living bejeezus out of it real soon with additional stuff. If we have pins available, we can bump it up to 7 (128 registers) and use the 8th pin as R/W line?

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #5
Finally: Damn, that looks cool! Can't wait to get my hands on one!  :D

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #6
I agree with you on the single repo and structure. There were a couple motivations to separate the repos. The firmware includes the printf and libopencm3 submodules, so every push/pull needs a few extra click and switching branches results in lots of (ignorable) error messages. Another big one is that the automated build script is a bit dumb about when files change, so it makes the firmware and HDL every time there's any upload to the repo which is a bit obnoxious.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #7
X

V1b is off to the board house. Quite a few passives on the bottom layer. We're doing a basic test of the current schematic on a two layer board, then we'll move to four layers for the final/next board. We'll definitely add as many more address pins as possible when we move to 4 layers.
X
I've been playing with displays :) I feel like a small e-ink is the perfect pinout label, but the IPS LCDs are great too.
X
I'm leaning towards e-ink because I don't want to get bogged down writing a flashy display interface, but I can think of so many things that could be updated on an LCD in real time (state of each pin, voltage of each pin, bus contention, etc).
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #8
The next thing we probably need to think about is a daughterboard (pirate sail? ugh, kill me :P) for the IPS LCD and eInk displays.
X
This is the schematic for the eink demo board. We are using R2=3ohm, so we don't need the resistance select or R3.
X
The retaining clip holder of the connector seems to be 1.6mm.
X
My initial thought is a daughterboard that mounts to the two holes over the io connector. If we cut out the PCB around the connector retaining mechanism I believe the display will lay completely flat on a 1.6mm thick PCB. It seems the standard thing to do with the display flexpcb connector is to have a slot in the board and bend it under to the bottom side. all the components would be on the bottom and the display lays flat.

Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #9
X

We'll work up something like this for both types of displays.

X

I have IPS LCDs from two suppliers that seem reliable (able to get the display long term without driver changes). I like this one best, but I still don't have the full datasheet. This is from a rather large display factory.
X
This one I have full datasheets for, but the build quality seems a bit lower than the other one (haven't seen the display in action to judge though). This is from a distributor, not a factory, as far as I can tell.
X
The eInk uses a 24 pin 0.5mm connector. Both IPS LCDs use a 12 pin 1mm connector.

The LCDs have different pinouts, which is a pain, but at least the daughterboard only needs two connectors and a transistor or fet for switching the backlight from PWM.

Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #10
X

Great! The TJC8A-10WA lock mechanism is 1.55mm tall. A 1.6mm thick PCB daughterboard with a notch will let the display lay flat against the edge of the connector.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #11
I got datasheets (attached) from both of the 2inch LCD manufacturers. They actually have the same pinout, the text in one was just really messed up. So we'll only need a single carrier board to test both displays.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #12
X

The display datasheets are a mess. It's a long story that might make a good blog post some day. The displays connector is soldered to the PCB, it doesn't use a ZIF socket. Here's the display carrier board, we'll send this off soon.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #13
X

This is a little test board that plugs into the Bus Pirate header. The LEDs show if the pin is high or low to make debugging easier. We also brought out Vout to measure, or to use an external Vref with the buffer.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)

Reply #14
I uploaded basic UART to the HDL repo earlier this week: https://github.com/DangerousPrototypes/BusPirateUltraHDL/tree/master/components/uart

Currently it only accept n-8-1 (no parity, 8 bits, 1 stopbit). The baudrate is clk/4 in order to make it reliable work (I hope :D)

things to add (in random order):
- odd/even parity
- baudrate detection
- 5-9 bits (or 8 if parity is involved)
- 1, 1.5 or 2 stopbits