I bought an Atmel Raven development kit so that I can work with Zigbee.

The LR44 batteries that came with the board lasted 48hrs. So I needed a permanent power solution. The simplest way to power a Raven board is via a USB cable. Cut the end off from it to get at the wires inside. Solder red(+5)/black(GND) to the PCB. Note that you hook power up on pins 1/2 of J401 - not where the power jumper is located. +5 on pin 1, GND on pin 2. Use a powered hub as a power supply and you can move the boards away from your PC.

The demo firmware that comes with the boards, is for.. demos. I quickly figured out that I needed to write new firmware. Of course I don't have any way to load this new firmware into the device. I have to get a JTAG that works with Atmel products like the AVR JTAGICE mkII. Lucky for me Arrow is running a half price sale on the JTAG unit. $150 plus $8 shipping is cheaper than you can buy a clone unit from China.

Now I need to start learning about 802.15.4, 6LoWPAN, Zigbee profiles, etc...

Siemens has started an open source Zigbee implementation for Linux. But as soon as I started looking at it I discovered that the license from the Zigbee alliance for using the Zigbee spec is incompatible with the GPL. A request has been made to the Zigbee alliance to fix their license so that it is GPL compatible. We don't have an answer back from them yet.

We are primarily focused on using Insteon in our product, but we are hedging out bets. There is another set of licensing complications around Insteon that we haven't resolved with Smart Labs.

I looked a little at Z-wave. Like Insteon, Z-wave is controlled by a single vendor, Zensys. I haven't explored the licensing world of Z-wave yet.

As part of a deal with Phytec I wrote an AC97 driver for their mpc5200 development system. We use these Phytec boards as a prototype platform. They are reasonably priced and they work well.

The code for this driver has already been accept for the Linux kernel and it will appear in 2.6.31. AC97 and I2S are both implemented by the same PSC block on the SOC. This code will become the basis for the tri-amp Digispeaker I2S driver.

While I was at it I also implemented AC97 support for the Efika. The Efika is a $99 mpc5200 based development board available from Directron. The Efika was useful for driver development since it has USB and a PCI slot. The current version of the Phytec development system has now added these features making the Efika less useful. Note that it is hard to add custom hardware to an Efika since they didn't bring all of the pins out form the CPU.

There has been much progress since my last post. In fact, I am a little late with this posting. Prototype VI has been booting Linux for about three weeks now. The biggest breakthrough came when we were able to get ethernet working over the powerline modem (Intellon). This allowed us to boot Linux without having to spend hours downloading the kernel to flash via JTAG.

All the peripheral devices are now working except Insteon and the amplifier.
Here is a list of what is working:

1. CPU.

Of course, we have had the CPU working ever since we got UBoot to work. However, by getting Linux to boot we have been able to work the CPU like a real computer. We have convinced ourselves that it is up and running fine. We had a few problems keeping it running, however. The more stuff we turned on in the kernel, the more power the entire board required and it overwhelmed our little power regulators. This would cause the CPU to reset. See the Power section below for how we 'fixed' this (for now).

2. Flash.

Also, Flash memory has been working ever since we got UBoot to work. Linux doesn't really use it for much. Instead of making a file system in Flash, we mounted a root file system over the net on our lab computer.

3. RAM.

RAM worked pretty much the first time. There was some work getting it configured right when we made UBoot work. After that, Linux was able to fine RAM and use it.

4. Serial.

Again, this has been working since we got UBoot working. Now it displays the startup messages and boot prompt for Linux.

5. Intellon.

This was a big win. Initially, I wasn't supplying power to the INT1200. It can supply 2.5V for itself using an external switch. The layout was wrong for the switches I bought so the chip was not getting any power. I did a little surgery on the board and was able to get power to the chip. Once that was done, Jon provided a little program that I copied into Flash using JTAG that could download the Intellon firmware to the chip.

With that done, I used a 'cut-up' AC power cord to plug our board into a power strip (see the cord coming off the upper left of our board). That power strip was plugged into an 60Hz AC generator. That generator provides a pretty clean 120V 60Hz AC signal. I also plugged a NetGear XE103 into the power strip and then plugged that modem into my router. When this experiment was setup, we powered up the board and let it get to the UBoot prompt.

At the UBoot prompt, we run the program Jon provided to download the Intellon firmware into the Intellon chip. Once complete, I could see that the NetGear modem detected our modem on the powerline when its blue light turned on. That was a good sign. I then ran a boot command at the UBoot prompt that used tftp to get the kernel image and device tree from the lab computer. This worked! At the end of the download, the boot command instructed UBoot to boot the image that was copied into memory. This also worked!

6. USB, SDCard, IR.

Once Linux was up it was a pretty simple matter to get the other devices to work. Jon and I spent some time modifying the device tree definition and making a few lite changes to the kernel. The USB, SD Card and IR devices are now working.

7. Power.

Power was a problem throughout the process. The regulators I used were just too small. Even though they were rated for the current I needed for the board (about 1.3A at 5V), they would get too hot because they were just under their current limit (1.5A). So, I finally bought some bigger regulators (Linear LT1529-3.3) and did some more surgery on the board. They were bigger than the old parts but they just barely fit with a little push :). You can see the big regulator in the middle of the board near the top.

The control board will now boot up to a uboot prompt. I have the CPU, Flash and RAM working. I also have the serial port working. Here is a current picture of the board:

Here are some things I learned along the way:

1. BGA Soldering.

I was able to solder a BGA to the board using my IR Welder (Kada 862++). However, the quality was poor and I was never able to get a consistent solder. I got as far as being able to detect the CPU and Flash with Jtag, but in all cases, there was always some lines that were not functioning.

The reason for this was that the board was not being evenly heated. The preheat element and the IR beam had a tendency to just heat a small area. This would cause the board to warp. Just a little warping and the solder would 'squish out' from the stencil holes and create bridges. After wasting four of my CPUs (at $27 each) and one of my boards (some pads came off the board), I decided to have an assembly house mount the BGAs for me. I called Schippers & Crew and they were able to mount two of my BGAs for $100. They have temperature controlled ovens and an xray machine. I saw the xrays and the solder joints were perfect.

It occured to me (too late for this round) to use a piece of 1/4 inch aluminium to help spread out the heat. I went to a local sheet metal shop and got them to cut me a piece that is the exact size of my board. I then bought some small clamps from Home Depot to secure the board to the sheet metal. The idea here was to use the preheating element to heat up the entire board via the thick piece of metal. Then, I could use the IR beam to finish the weld under the BGA. I think this would have worked but I thought of it too late. I had already had Schippers & Crew weld my BGAs for me. Next time...

2. Soldering 0402s.

Needless to say, there is a bit of a trick to soldering these things. First of all, you need a lot of patience. It does not go quickly at first. The trick is to 'tack' down the component on both ends. To start, just put a little solder on one of the pads. Heat that pad and use your tweezers and magnifying lamp to place one end of the component on the pad. Then tack down the other end of the chip. Once this is done, I would then spread a little rosin on the component and re-solder each end. This would make a nice connection as you can see in the picture below.

This process is a little laborious but effective. The reason I don't immediately put down rosin is that it can be sticky and it gets on your tweezers. When your tweezers get sticky it is 'game over'. The components start to stick to your tweezers and you will have trouble placing them.

3. Linear Regulators.

I made a rookie mistake in my power design. The PCI connector needs +-12V. So, I decided to just make all the other voltage rails out of the +12V line. I put all my regulators in parallel (5V, 3.3V, 2.5V, 1.8V, and 1.5V) and fed them 12V. Unfortunately, the thing about linear regulators is that the current into the device is equal to the current out of the device. So, if you have a voltage drop of say... 7V (= 12V - 5V) across the device and you are trying to get 1A through it... you end up with 7W of heat! Ouch. I was using some voltage regulators from Linear Technologies (LT1963A) and they would simply shut down when I tried to pull any current through them because they got too hot. Lesson learned.

To fix this, I decided to feed the regulators just 5V (and ignore the PCI connector for now) and cascade the lower voltage regulators. This is what the 'red' wires in the picture is all about. The 5V source is fed to the 3.3V regulator. The output of the 3.3V regulator is fed to the 2.5V regulator... and so on. Of course, this works pretty good.

4. Power Stability.

The lower voltage rails to the MPC5200 have to be pretty stable. My bench supply is a switching power supply and it seems to be going bad. Right now, I am getting about 200mV of noise on the line and there doesn't seem to be anyplace to send the device for service (Mastech HY5005-2).

To fix this problem, I cut the cord to my Phytec power supply and used that as my 5V source. This works very well. The Phytec power supply is capable of delivering 1.5A at 5V. Right now, my board is taking about 750mA at 5V.

5. Using Jtag.

Jon's modifications to UrJtag are working well. I am able to use it to toggle lines on the MPC5200. I have also been able to use it to program flash.

In the beginning, I used its ability to toggle a line to verify that my address and data lines to the flash chip were working and not bridged. This was a slow and tedious task as I was fighting with the poor soldering job of the IR welder. However, after I got boards back with professionally mounted BGAs, the lines all toggled well and independent of one another. After that, it was easy to use it to program a flash chip.

6. Configuring Uboot.

Jon had already gotten a headstart on configuring Uboot for our board by experimenting with the Phytec board. Jon helped me setup my compile environment with his version of uboot (see his previous posts). We then went throught he pcm030.h file line by line changing things to match our configuration. We changed where flash was located and how big it was. We also changed the GPIO port register to match our board configuration.

I spent quite a bit of time tracing through the uboot startup code. After we got uboot partially configured via pcm030.h, I was able to verify that the CPU was seeking code from flash and executing it. I discovered that I could toggle one of the GPIO lines by writing to its register. I could see this toggle on my scope. So, I slowly traced the uboot startup code by placing toggles on the GPIO line and watching them on the scope. Along the way, I would fix things in the pcm030.h configuration file. Eventually, we got to the uboot command prompt and were able to command the system.

The software will be checked into the repository soon.

I bought a new USB microscope from Brando in Hong Kong. Cost $78 plus a $3 shipping fee. It comes with a simple capture program for Windows. It also is working under Ubuntu 9.0. I am still getting the hang of using it. You basically have to use two hands to get a clear shot. One hand to steady the mount and one hand to focus and push the capture button. Here is a picture of the corner of one of the RAM chips.

In my previous post I showed the process I used to solder the MPC5200 to the board. Of course, I couldn't wait to apply power to the board so I decided to build out the JTAG circuitry and give it a try.

Jon and I had previously decided that we would build the first board in sections, testing along the way. Prior to soldering the BGA, I had already built up the power section of the board and tested each power rail. So far, so good.

After soldering the BGA, I built up the JTAG connector and all of its supporting circuitry (pull up resistors, bypass capacitors, etc...). Jon had already figured out how to make UrJtag work on the Phytec. The idea was to get enough of the board working so I could use JTAG to toggle a pin on the MPC5200.

Short answer: It Worked!
Prototype VI drew it's first breath on March 30th, 2009.

Below is a picture of the prototype with a JTAG probe connected. Notice the two green lights near the top. Those lights indicate that the board has +30V and +12V. Also notice the scope probe on the pin near the bottom of the picture. That pin is IRQ0 of the MPC5200. Following Jon's instructions, I was able to get UrJtag to recognize the processor and then toggle the IRQ0 pin.