VultureProg: Meet the contenders

cable_salad

Wow! It’s the weekend already. Where was this last week? With the first week of the 12 weeks of GSoC already gone, I think the time to panic has arrived.  Looking back on my original proposal, I realized I have given anyone interested definitive proof I am indeed and indubitably insane. I have offered to design and build hardware, gift it with a fully functional and versatile firmware, write the software to control it, and integrate the functionality into flashrom. To the untrained eye, the last statement resembles a description of four separate GSoC projects. Here at coreboot, that’s all in a day’s work, with enough time for lunch.

Why I went out of the microcontroller arena

Back in the day, I used to mess with Parallax SX chips, and Microchip PICs. I really hated the $75 cost of an SX-Key programmer. What good is a development board if you cannot develop on it out-of-the-box? Sure, I’ll buy your overpriced board and your overpriced programmer. NOT!

Five years ago, the microcontroller arena had three major flaws. It’s these three flaws that made me leave the arena at the time:

  1. Offensively overpriced development boards
  2. Offensively overpriced programmer and debugger hardware
  3. Slow and difficult to debug

Maan, the prices of development boards at the time still amazes me — in a bad way. I don’t like spending $1000 on a pro-level board, and I definitely don’t want to throw out $100 on a hobby-level board so castrated of features that it’s useful for nothing other than turning an LED on or off — I can do that with a wire and a resistor. For hobbyists on a budget, this was not a warm welcoming place to be.

Between 2006-2007, I did some amazing things with PICs. I joined my high-school’s robotics team, and wrote one of the sleekest, sexiest, impeccable autonomous tracking algorithms ever. The brains was a dual-PIC board. I would not complain if our team did not have to spend over $1000 on the board. Don’t quote me on that number though. It’s what I was told by a mentor. I never saw the actual invoice with my eyes.

I’ll go back to my SX-Key for a bit. It connects to the PC via a freaking serial port with 19200 baud. Programming was slow. Debugging was slow. I would actually use a small (windows-only) program for debugging called SX-Sim — it was so much faster to emulate the code than to run and debug it.

Five years ago, the situation was a mess, but today it is time for a pit-stop. Let’s have a look at the new toys.

The Stellaris Launchpad

The Stellaris Launchpad is a beast in itself. It is the most hacker-friendly development board I have ever seen. And I mean it. It overcomes flaw #1 with a bang. The Stellaris costs only $13, and any respectable electronics distributor carries it, anywhere in the world. What about flaw #2? I looked around for ARM programmers and debuggers, but they are not very user-friendly price-wise  The Blackmagic probe is probably the only reasonably priced option, at $60 or a tad bit more.

stellaris

Let’s have a look at the Stellaris. No it is not a dual-CPU board, and no, it does not come with a USB to serial converter. The black chip at the top is indeed the same microcontroller as the main CPU in the center. It’s loaded with firmware that turns it into a very powerful programmer and debugger. We ARM geeks call it ICDI (In-Circuit Debug Interface). It serves its programmer and debugger purpose surprisingly well, and is well supported by free software tools, such as OpenOCD. STM has also been offering a built-in debugger on their Discovery boards for a while now.

The ICDI has a very nice feature: a built-in CDCACM interface. That’s just a fancy way do describe a standardized USB to serial class. Usually, you set up your console through a UART, hook up TX, RX, and GND, dig through a list of serial ports, open the right one, and hope you capture the output. The CDCACM is connected to UART0 on the main CPU. We can capture debug output with no additional hardware. But wait there’s more! Each ICDI chip has a unique serial number. What this means for you linux geeks is this: you can use udev to tell it to assign a unique device name to each ICDI board. No need to dig through a long list of serial ports, just:

$ picocom /dev/ttyEndeavour -b 921600

 

You will always hit the right Stellaris, provided the udev rules are properly set up.

OK, the Stellaris obsoletes flaws 1, 2, and 3. Sounds interesting? Let’s look at it in more detail. We get 35 GPIOs arranged in two 2×20 0.100″ pitch headers. USB and UART0 are separate pins, so we don’t lose any GPIOs for USB and debugging. On STM Discovery boards, the pins are arranged in monolithic blocks, suitable for connecting hanging wires. The Stellaris goes a bit farther: the pins are arranged in a standardized format, ready to accept standardized daughter-boards called Booster Packs. A Booster Pack is what I will be designing for VultureProg. It will have a PLCC socket, maybe a few components to change the voltage, and an SPI header. Once we forget about the 3 GPIOs connected to the on-board LEDs, we still have 32 GPIOs left. More than enough for parallel flash chips. I will discuss next time why sharing GPIOs between busses is not a concern with QiProg.

The flash chip and connections

flash_chip_in_cable_salad

I have a SST 49LF080A, and SST 49LF160C. The 160C is very ill-behaved in the emulated LPC bus, hence I am focusing on the 080A for the time being. I’m using a cheap PLCC to DIP adapter (plenty of those on eBay), on a solder-less breadboard. The hookup is a very ugly cable salad with ranch dressing. The salad is a huge pain to work with. At least it makes for a very artistic theme photo.

Don’t ask me for a schematic, because I can not remember what is connected how. I identified three different, incompatible pinouts for PLCC chips. I will need to settle on a flash-to-Stellaris pin routing that accommodates most of these pinouts. I can’t wait to get an actual booster pack assembled. Then I’ll have a schematic and one less mess (the cable salad) to worry about.

The invisible eye

I need to be able to peek inside the LPC bus, and see if what I think the Stellaris is doing is what the logic_probeStellaris is actually doing. I am using a little 8-channel 24MHz logic analyzer. Don’t let the name fool you. I did not spend a ton of money on a USBee AX PRO. The device is actually a clone of the insultingly overpriced USBee. I got it from DealExtreme for about $12. It is very well supported by sigrok, and just works. Joel, if you are reading this, thanks for making it happen man!

Those are my toys, and NO, you canNOT play with them! I hope I scared off some of you at the beginning when I said I am panicking about the deadlines. We are able to send a qiprog_read_chip_id() command to the Stellaris, do some LPC blackmagic, and identify the 49LF080A. That is already the end of week 4!!! The code is a bit of a mess, but more on that next time. I will also dig into the architecture of the QiProg protocol, what makes it tick, what makes it extendable and easy to implement, and why it is a really great choice for ROM programmer devices.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>