The ARM Chip I was using on the CNC board (NXP LPC2927) has two JTAG chains – one of them is a boundary scan / flash (and who knows what else) chain, and the other is for the ARM9 standard debug interface. I only really wanted to program the flash, so I started out with the flash chain – There was some documentation for the JTAG flash interface of a previous chip in the series so I was hopeful this one would be similar.

Unfortunately it was not meant to be. The enable bits / initial handshake sequence for the flash controller on this chip seems to be entirely different than the earlier one, sometime I may go back and find the right bits to make that work, but I shifted my focus to using the ARM debug interface. The first thing I noticed, is that it didn’t work :) As it turns out (after connecting the layers of deep indirection in the documentation), you must have a crystal in a specific range of frequencies for it to work; After fixing that though, I began to make progress on that front. the ARM debug interface for this chip is relatively well documented in the ARM9 documentation on ARM’s site. Documentation always seems to leave something to be desired, but this was at least relatively unambiguous – and worked!

Effectively, the ARM9 chips (also most other ARM chips), for a debug interface, simply intercept the processor’s instruction and data busses, and allow you to single step the processor. So you can perform operations by injecting the instruction you wish to execute, and single stepping. You can write a register to an arbitrary memory location, which causes it to be intercepted on the data bus (afterwards you can read the data bus) – Similarly you can read from memory and it will end up reading the value you insert onto the data bus into a register. It’s a rather minimal and effective debugging interface, it doesn’t consume much in the way of hardware resources, though the software to do anything useful with it has to be a bit complicated as a result.

Since the single step operations capture the data bus, it’s not possible to directly modify or read system memory through them, but there is another special provision for doing this, for executing individual instructions synchronized with the normal CPU clock that can interact with memory. So, I wrote a handful of wrappers that would allow me to manipulate the CPU’s registers and read from / write to memory, and around that built a small program that wrote the flash using the system’s internal flash controller.

With that literal pile of work behind me, I set off building software for the ARM chip itself. A short amount of time later, I had a blinking LED (Because this is naturally the most important thing to do with /any/ piece of hardware)

(Not visible: LEDs blinking)

(Continuity note: Note that the above board is not the same one as the board shown in part 1! At some point in messing with the JTAG chains I became sufficiently frustrated with the quality of connections on the first board, which had been reworked a few too many times perhaps, that I built a second board and took special care in making sure the JTAG chains and other important connections were in good shape. It’s a bit less than fully populated because… placing some 400-500 components is HARD!)

(More to come in part 4…)

I took the one CNC board I had assembled, such a long time back, and subjected it to an initial smoke test (connecting the power, that is). There was smoke. Not discouraged by the loss of a chip or two, I took a further look. I found that the assembly of the first board had hit a number of major snags; The board was 2oz copper in order to be capable of routing large current loads to the motors – but the groundplane was exceptionally difficult to solder to, even though the pads have thermals. I found that one of the chips broke because a resistor intended to keep an “enable” signal low was not connected to the groundplane, and the other one, a FPGA, was installed backwards (these FPGAs have two circles on the top which could indicate pin 1; Unfortunately the wrong one was chosen and I didn’t check.)

Undeterred, I pressed forwards with getting this board to work. I replaced the FPGA and rotated the other one, doublechecked a lot of signals (there were still some components on the back side of the board that were not properly connected to ground). All the poor connections were on the back side of the board, the top side had been reflowed and the connections seemed uniformly good there.

After those fixes and some cleanup, ran the smoke test again – The board powered up without smoke! A first small victory down this path – But many more things remained.

So, let me tell you about JTAG. I made a post on jtag a long time ago, when I was first starting to mess with it; but for this project I decided to build my own JTAG tools to program the chips involved & for other nefarious purposes.

I have made a few starts  towards my own jtag stack over time, first was an AVR-based board intended to program all manner of things – This project ultimately stagnated as the jtag level shifting interfered with actually programming the AVR chip itself. Despite a fix, building out the stack was a big project and never was completed.

While I was designing the CNC board though, I had the idea for a more specific debugging helper tool geared for it, and not too long after designing the CNC board, I did build such a device based on a chip I had come to know and love (and built a USB stack for…) – this was the ucHelper, PCBs shown below.

ucHelper is really just a minimal JTAG and serial interface board – Being exactly what I needed for programming and debugging here though, I got started on writing the code for it.

(more in part 3)

The CNC Controller in the last two posts was my first big move towards realizing the idea; Being  a stubborn sort, I’ve wanted to build the entire thing entirely myself – Historically this has been both a good and a bad decision; I like owning the entire stack in a project, but it comes at a price – Actually building and completing the project takes a lot longer. The upside is I get a lot of experience from such projects, and learn a lot about a wide variety of things – this is ultimately the reason I do it so much.

I did finally concede to use an existing 3D Printer hardware design, and near the end of last year built a Prusa Mendel from a kit of printed parts & hardware (pic below)

However I am still quite determined to own the electronics. Around the very end of 2011 I finally decided to put the effort into making this project happen, and started to bring up the CNC board I had designed.

(More in part 2)

Since I opted to stop posting on a fixed schedule, that seems to have eliminated any hope of regular updates – oh well.

So, I have been largely tied up in a (Very big) project that’s still secret, I’m not saying much about it. But there have been a few bits of progress in other areas – Most notably, I finally got a CNC controller board populated!

Isn’t it lovely?  I certainly think so, after all the work that went into getting this far :)

Sadly, I won’t really get much further at the moment (need to get back to an all-consuming secret project), but this has marked a pretty big milestone in a few of my projects (the reflow controller also works pretty nicely!)

I’ll be sure to take some time and write up these when I make some more progress (or just get sick of working on the more important stuff again)

Over the past month I have been designing a CNC controller for various small projects I’ve been kicking around (oh things like 3d printing, building a pick&place, and some other random thoughts)

Being the hopelessly stubborn sort that I am, I decided to build it from scratch. The design work for something like this is something I enjoy immensely, and while I don’t always get everything right the first time (There are a few inefficiencies, but nothing terrible), it’s been a lot of fun and a good learning experience.

Here’s an image of the final board design, and past the break is a very long thread of text and images showing the steps getting to this point:

(After weeks of looking at this really closely, it seems amazing to me how small the board actually is)

Let’s start with the big questions:

Why design a stepper motor controller when so many already exist?

Mainly because I hadn’t done so before, and it seemed like a fun idea. Also because I have the unhealthy tendency to reinvent the wheel, and I’m not about to do anything to fix that. ;) Additionally though, I wanted to make something better than just the standard off-the-shelf motor controller

What are the design goals for this project?

The core design goal is to be very flexible. This system is rather overkill as a result, it can drive 12V and 5V steppers, and also has a lower current variable voltage rail intended to drive voltages between 5V and 12V. There is an ARM microcontroller that handles all the interface and data management, and it’s attached to two FPGAs which will be able to drive the steppers with very precise timings. As it stands, the board is designed to drive 5 stepper motors and additionally a bank of 8 standard R/C servos for miscellaneous other stuff; And each of the stepper interfaces could be used to drive two normal motors too, or resistive elements for heating, or …

Being easy to repurpose and reuse with other systems was a priority too; This design uses motor connectors which should be compatible with the system makerbot is using. For everything else (end stops, etc) it’s using 2 and 4 pin 1mm pitch JST-SH connectors which are also pretty common. There are two I2C busses which are designed to accept arbitrary sensors or controllers to be added to the system

Will you sell them / release design files / etc?

Likely one or more of the above,  but I want to get it working first.

I’ll be happy to field other questions, let me know if you have any!

About design challenges:

This board started with  the basic stepper motor design, and in trying to make it as useful as possible – I wound up with a motor controller as a train of 4 H-Bridges, attached to a local per-motor power rail. Each h-bridge would get two control lines from the FPGA (drive up/down), and one sense line, which tells the FPGA whether the voltage is above about 1V or so. Not a lot of information but will probably come in handy.

Ultimately this area is where the design flaw in this first revision is – The output stage of the H-Bridge is driven by a pair of FETs, a P-Fet to pull up, and an N-Fet to pull down. Since the P-Fet’s gate needs to be near the high level (these P-fets will turn on when the voltage is less than the high voltage minus a volt or so), I’m using a second stage of fets to invert the FPGA signal and make sure it can fully be turned off. I am driving the N-Fet’s gate directly with the FPGA though, and while the 3.3V signal is high enough to turn on the FET, it’s not high enough to turn it “all the way” on, so it operates in a less efficient mode. This effectively limits the amount of current I can drive efficiently to about 1A instead of 2A or so which I was designing for – but that’s not a major loss for my application so I’m going ahead with this revision anyway. I’ve found some level shifter chips that will use in subsequent versions which will solve this problem for me though, and drive both P and N FETs fully.

Routing this board was also a fun challenge, I tried to keep as many of the signals as possible on the top layer to have good return paths to ground. Ultimately this didn’t work out to be perfect, but it’s pretty good. The motor area in particular is very clean on the back side, and only has the ground plane and local power traces.

In order to make the input section as dense as possible, there are actually two PCB levels. There’s a second PCB which will stack on top of the first one, attached with one rectangular board-board connector mating, and another one with ribbon cables; This makes it possible to also enclude end-stops, rotary encoder inputs (which may not be really interesting, but may be used for something else entirely) and LEDs per motor. It’s also used for the I2C connections.

As is my custom, I have taken screenshots of the board’s layout at various arbitrary points in the design process, and the result is that you can see how the board has evolved over time.

This project has been extremely long running, as far as projects go, so I have accumulated a massive 27 WIP images. They are here below with inline commentary for your amusement:

First things first – Settled on a core design and layout, and the set of parts to use. This greatly shaped what the rest of the board ended up looking like

Added some more important things: Power and interface. The line voltage footprint was added for spacing reasons, and because I am considering building a line voltage -> ATX module to fit on top at some point. But that’s a crazy project in its own right.

Duplicated the motor tile for all 5 motors… And ended up with a huge mess of components!

Mostly sorted out the motor tiles at this point, and added FPGAs

The power distribution traces have been added. These are >100 mil traces for high current capacity (And the PCB will be 2Oz copper); Oh also added an ARM

Added the switching power supply for the variable voltage rail, and started working on layout for the per-motor power distribution on the first two tiles. Added 4 R/C servo outputs (was planning on putting the other 4 on the stacked second layer board)

Decided how the motor tiles should connect to the FPGA, for the first 3 tiles. Started working on routing them, and further layout/routing on the motor3-4 tiles.

Further progress routing attachments to the FPGA

More traces!

Yet more traces! Started thinking about second FPGA placement, and R/C servo connector layout

Many things here! Decided on a scheme for  attaching I/O to the upper level I/O board, Also decided to put all 8 R/C servo interfaces on the bottom level to be consistent (after realizing that the top board would need to stick forward, so the JST connectors will be remotely close to the front of the other pins). And also designed the voltage/current measuring circuts, whose components were stuffed up in the top middle for now.

Started routing the power enable lines from the motor2-3 tiles, this was a bit tricky as there’s no good place to put the traces except on the back side. With the other constraints in place there really isn’t another good place to put them.

Starting to route the second FPGA, messed with a ground plane up by the switching power supply.

Routed almost all the rest of the second FPGA!

Added FPGA jtag connector, started to organize current measuring components, and attached the FPGA2 to the uC in a convenient location

Added serial level shifter, and finished organizing the current measuring components – Starting their layout.

Added a serial flash and a second JTAG connector for the ARM. This isn’t a standard ARM jtag connector, but I didn’t have space for one, this will work well enough though.

Added components for a “shutdown” switch. Decided to add a 3.3V serial connection broken out to a header, and continued stuffing the power measurement components into the space near the CPU.

Started routing power for the first FPGA. There are 3 voltage levels to manage; GND, 3.3V, and 1.2V. Routing strategy was to run 1.2V on the top layer, 3.3V in the middle on the bottom layer, and GND will fill everything else. ARM cpu is similar, except 1.8V rather than 1.2V

Finished placing and routing (most of) the power measurement components! Also finished layout of the shutdown / serial header components in the middle of the top.

Starting to route some other stuff around, and power for the ARM

Finished JTAG signals

Finished ARM chip power routing!

Now finished second FPGA power too! So very close now :)

Went back and enabled the Names layer and repositioned all of the uncooperative part labels :)

Added ground fill. Added lots of vias, started vetting design for bad features in the ground fill & vias too close to pads & etc.

Add pick&place markers, some silkscreen, further vetting, overall is pretty much done at this point!

That’s the last image I have – I have made a few tiny changes since that (found some more vias too close to pads on the back layer)

And after this board was done, I went on to build the I/O board that will sit on top of it. That was far less difficult and the images I have are below:

I’ve had fun building this board but I’m rather glad this phase is over. I’m now sending the design to be produced and will have to order a large pile of parts to populate some boards with :)

Wish me luck!

In the meantime however, I have received the reflow controller PCBs I mentioned a month ago! Some pictures are up on flickr, one is below – I don’t have it working yet but that will become a priority pretty soon.

Coming next:  I’m currently working pretty hard on a CNC controller for stepper motors and some other things; As usual my ideal is to build my own solution instead of using any existing one, so I’m desiging my own now. I will post a full writeup on it once I have it completed, but don’t want to share any details at the moment.

I’ve been busy working on a Windows Phone 7 game, writing VHDL for one hardware project, thinking through a second hardware project, and will be working on yet another hardware project soon ;) These I will probably post about eventually, but not until they’re further along…

Some of these projects are explicitly going to have the first revision done in 2 weeks though, so I should have plenty to talk about then!

I have started getting set up to compile code for the LPC134x chips that I’m using in everything recently, as I will need to be able to program them shortly – I’ve got the devkitARM toolchain installed and am modifying the GBA compilation toolchain to be able to compile for these devices. Just started that earlier today and not quite done yet.

I’ve also designed circuit boards for a toaster oven reflow controller (including images below) – This is a two-board solution, one deals primarily with switching the high voltage using optoisolated triacs (thanks eagan for pointing me in this direction, I was originally thinking of relays) – The other board is another LPC1342 with a flash chip to store configuration and run data. It has some buttons and an LCD for user interface.

These will be in Laen’s Jan. 3rd order, and I will be trying oven reflow very shortly after they come back :) I also have come up with a few other interesting things to control with this, and will have to report back on my success with that at a later time…

I still have some software work ahead of me, but here’s the (nearly) final circuit board:

(I say nearly final because I did go on to make some tweaks after taking this image)

Read on for a train of WIP images and more information…

Bitbox has been a bit of a long standing project for me, so I’m not sure why now seemed like a good idea to finish it – Perhaps it was because I ran into the NXP LPC1343 ARM microcontrollers, which are pretty incredible chips, and rather well suited to this task.

The architecture is pretty straightforward but there are some messy parts in the design; The DAC/Amplifier chip I’m using receives the I2S  protocol for audio data (and some variants), and the ARM doesn’t actually produce it nicely – but I have rigged up some timer outputs and can generate the signals that way (And I’ll even be able to use the SPI fifo buffer as a outgoing sample buffer!)

This will be my first project trying to manage a rechargable battery, so hopefully I didn’t make too many mistakes there :) I have some FETs and diodes making sure current won’t flow the wrong way when running off of either the battery or USB.

Overall this was a pretty complex design, and routing the board (within the space requirements I set out with) has been pretty challenging. It looks pretty good though, I’ll post more on this once I get some PCBs back and populated.

On with WIP images!

(Magic happens)

(At this point you can see the left side of the board shift left a tiny bit, as I work to make more space in the middle)

As I’m feeling a bit adventurous (and not really interested in soldering a bundle of wires to program these), I’m also building a test jig! Still working on the exact design, but I’m planning to use a lot of laser cut acrylic, and I’ve designed another PCB to sit on top and do the programming. Given the signals I’ve broken out to test points, it should be possible to do a more comprehensive test in the future by swapping out the test PCB (but still not a complete test – I’ll have to work on improving testability of my designs.)

Questions? Comments? Let me know!

This is the USB Jtag PCB I previously mentioned, and I had it produced in a group PCB order managed by Laen – They turned out nice and came back pretty quickly, I’ll definitely be sending him more PCBs

As I was on vacation though, I just recently ordered the parts to complete these boards, and haven’t got them yet. I’ve also been thinking about priorities and am working more heavily on some projects which I won’t blog about :)

Things are still developing though, keep watching and I should have more to talk about in 2 weeks.

I’ve been working out the concepts in software using the modified USB stick (as I mentioned previously) but just haven’t had enough time to allocate to it yet. Soon, though.

This design is pretty simple; I have the microcontroller (ATMega32U2), a RGB LED, switch, and crystal – Then around that I am building a set of voltage level translation circuits for the jtag signals, and for additional inputs, outputs, and “pump” signals (which can strongly connect to a target’s V+ level, and drive a significant amount of current)

I’m including the JTAG interfaces I use commonly  on the board, and I have another additional “expansion” slot which I’ll be building new boards for to connect to yet other interfaces

Schematic done, decided on a rough layout and started placing parts.

I got the core signals routed, and routed the level shifted jtag signals around the board, connecting to the side connectors as they go.

Added most of the other level shifting signals

And now the design is essentially complete!

Added ground planes, and vias to keep them well connected / allow plenty of return paths.

At this point I thought I was done…. Only, oops, I connected the top 3 headers backwards;  I had gone off of the pinout of the socket they plug into. Fortunately I noticed this before trying to produce the board :)

Ahh, now they’re correct.

So I’m having this board produced pretty soon and will write up more on JTAG once I have done some stuff with this.

In other news I’m taking a vacation in about 2 weeks! No, I’m not going anywhere interesting, just visiting family, but perhaps I’ll have something fun to write about by then :) I certainly have plenty of things I want to do!