Tuesday, April 26, 2005

Multiple Conflicting FireWire Enclosures from the Same Manufacturers

I currently use a Titanium PowerBook as my primary computer. However, I’m also a power user and a laptop has a limited amount of upgradeability. That means I have a lot of external devices connected to my laptop using FireWire. FireWire supports 63 devices which is great for someone like me and I’m nowhere close to 63. I have three external hard drives (two 250GB 3.5” and one bus powered 30GB 2.5”), two external DVD burners (a Pioneer 109, and a Pioneer 104), one external CD-RW burner (a Plextor W4824A), and an iPod as well as a 6 port FireWire hub. That’s only 8 devices. Not very close to the limit of 63, however, when I added my latest DVD burner (the Pioneer 109), I had a lot of problems. I eventually solved them, and I’m writing down my experiences so hopefully someone can learn from my pain.


In short…
It turns out, that FireWire devices have unique IDs similar to the MAC address on Ethernet devices. Some manufacturers use the same ID on all of their devices, which causes problems if you connect two devices from the same manufacturer to your computer. My guess is the FireWire people told the manufacturers they needed to supply unique IDs, however, somewhere along the line, that information didn’t make it to the assembly line personnel.

I’ve seen this problem with enclosures from Plumax and Acomdata and I’m sure many other manufacturers out there are doing this as well. I can also say for certain that the Mercury Elite Pro 3.5” enclosures do not suffer from this problem, as I’ve been using two identical ones for a while without fail. In fact, these are my favorite FireWire 3.5” enclosures, and I highly recommend them. You can get them here:
Other World Computing


I’ll describe how I fixed the problem below by manually changing the FireWire ID. I spent most of the time trying to isolate the problem, and then reading detailed specifications about the Oxford FireWire bridge chipsets (thanks to Oxford making their information available for download in PDF format!). But I’m getting ahead of myself.

First of all, this applies to enclosures that use the Oxford FireWire chipsets. I believe it applies to 911, 911+, 912, and 922 chipsets. Although I specifically was working with 911+ and 912. If you have an enclosure that uses a different chipset, such as Prolific, I don’t know how to help you. I’ve worked with enough enclosures to know that when you are shopping, you want to make sure you get one that has an Oxford chipset in it. All other brands have received reports of bugs and data corruption issues, that I ignored, until I lost data that I was able to trace back to a problem with the Prolific chipset. Since then, I will only buy Oxford (I should write another entry just covering that experience!) There are probably ways to do this for the other chipsets, I just don’t know what it is. I believe Prolific, and Initio are the other FireWire chipsets. Not sure of any other brands.

Second, flashing or modifying firmware can toast your enclosure. For some reason while following the instructions that worked previously and using the same flash software, I erased a 911+ chipset, and was never able to upload a new firmware to it, rendering the enclosure unusable. If anyone knows how to revive a 911+ that claims it’s ready to be flashed, but just seems to ignore the flash, contact me. So standard disclaimer…you do this at your own risk.

This should apply to Windows as well as Mac or Linux and other supported Unix computers. The flash software I’m going to discuss is Java based, so it’s cross platform. How Oxford got a Java app to access FireWire hardware is beyond me, unless they are imbedding some OS specific binaries in there. If someone from Oxford Semiconductors wants to contact me, I’d love to chat!


Ok, so let’s assume, you’ve purchased two new identical model enclosures for those two new drives you just got. And you’ve found, like I did, that whenever both of them were connected and powered on, your computer had a terrible time talking to them. Some of the symptoms were:
Incomplete directory listings
Long pauses when accessing either drive
One drive never mounting/showing up on the desktop
And occasionally, when I told one drive (a DVD drive) to eject, it would eject the other drive. It was at that point I realized that the computer wasn’t able to tell the drives apart.

Basically there are two reasons to muck with your firmware. You can upgrade to the latest version (which was my goal at first, although that didn’t solve my problems) and you can also edit some of the “advanced settings” of the drives, which are stored in the flash memory as well. It’s worth noting, that you can update the settings in flash memory without actually flashing a new firmware, which makes changing the settings a bit less risky than uploading new firmware.

Now that you’ve identified the problematic enclosures, and verified that they are running Oxford chipsets, it’s time to start getting some software that lets us mess around with the internals. I found the software by searching in many places, and was able to verify the latest version, at this time 1.64, was here:
Cool Drives FireWire Info
Specifically, the 1.64 Java updater/uploader/cloner apps for Mac OS X:
uploader_164.zip
Since it’s Java you would think that would work on Windows too, however they list a separate Windows version here:
windows_uploader.zip

Ok, if you want to get some more recent firmware you can get it from links I supply below. When I download the flash apps, they didn’t usually include the firmware files, although they had directories where you could put your own.

Anyway, they recommend that you disconnect all other FireWire devices except the one you want to work with. I just powered them down, so the only things that were active were my FireWire hub and the drive I wanted to mess with.

Then I launched the uploadergui.jar file.


Right away this found my Oxford based drive, and brought up the firmware information on it. It looked like this:


I then clicked the Modify Configuration button. If that button is grayed out, make sure you launched uploadergui.jar and NOT updatergui.jar. You should see something like this after clicking the Modify Configuration button:


Note the all important Chip ID Hi and Chip ID Lo fields. The reason I even thought to start messing with them, is because the other app that came with the uploader is called the clonergui.jar. It’s designed to take the already flashed firmware from one device and propagate it to other identical devices. It stresses that every time it uploads a clone, that it will increment the chip id by 1 for every device it flashes. Unfortunately, it didn’t make it clear to me if it only changed the Chip ID Hi or Lo or both fields. I’m guessing it simply added 1 to the hex value in the Chip ID Lo field. To be safe, I modified the values in both fields, just changing a number in each position and incrementing it by a value of one. So for example, I think Chip ID Hi, was 02, so I changed it to 03. If someone wants to clarify the usage of the Hi and Lo values, feel free to contact me. Anyway, after changing both values, I simply clicked the Upload Changes button. After that, everything started working. Obviously I only had to change that value for one of the drives, and could keep the other drive at its factory default.

While this sounds pretty simple now, it took me a lot of research to find all this information. None of it was sitting in one place. Hopefully this entry will help someone else out in the same situation. And maybe more importantly, Plumax will start making their Chip IDs unique.

Links that helped me solve the puzzle:

Thank you for the latest 1.64 updater utility.
Cool Drives

Latest firmware files, and some good info.
FireWire Depot

Thanks for making the awesome Oxford FireWire chipsets.
Oxford Semiconductor

Detailed guide on using the flash uploaded app.
Uploader Guide in PDF

I think this is the same guide as I listed before with some other chipset documents.
More docs at Oxford

Firmware 1.02 for 912 chipset:
912_v1_02.bin

Firmware 4.00 for the 911 chipset (I believe this includes the 911+ chipset):
911_v4_00.bin

Firmware 1.07 for the 922 chipset:
922_v1_07.bin.zip

Monday, April 25, 2005

Borland Together Software Bugs and Fixes

Ok, I've ran into a lot of issues with Borland's Together Architect and Control Center 6.1 software. (Architect 6.2 is the successor of Control Center 6.1, however, I've been using both, as there are some incompatibilities between them.)

Did your model stop working?
I ended up with a model, that once it was open, hardly any menus in Together would work. The menus would appear, but selecting an item, had no affect. For example, selecting Project->Properties, never displayed the property dialog. The behavior occurred right after adding some Favorites. If you get into a situation where no menu or buttons actually have any affect (even selecting Exit doesn't close the application) try opening your .tws file in a text editor and removing the favorites entries. They should look something like this:

favorites.root.0 = <oiref:cpp#Class#ClassName1:cpp>
favorites.root.1 = <oiref:cpp#Class#ClassName2:cpp>


I simply deleted all the lines in that file with favorites entries, and reloaded the project, and now Together started working again. This was in version 6.1.

Incompatibilities Between Together
Architect 6.2, and Together Control Center 6.1
Together Architect defaults to using the old (non XML) model
format to maintain backwards compatibility with previous
versions.  That's great, in theory, however I've come across some
problems.  I'll try to list them here as I discover and verify
them:


  1. Sequence diagrams created in 6.2 are not seen/ignored by 6.1

  2. I've seen instances where Favorites added in 6.1 are not seen
    when loaded into 6.2 although this doesn't always occur.


That's it for now.  I'll keep coming back and updating this list
as I find issues.