UMC-1, USB, Firmware Update, Safe Mode

Hey, everyone, sorry for the delay on this little write up. Hopefully, it sheds some light on some of the decisions Emotiva has appeared to have made, and why. To start, I think we all really like the price of the UMC-1. To achieve that price, though, certain compromises have to be made.

I'm aware that there are a lot of places to cut costs on an electronics component, but two big ones are development costs and components costs. One bitter little irony is that often times, cutting the cost of one means you increase the cost or complexity of the other. In the case of the UMC-1, it appears Emotiva tried to minimize the cost of the components involved in accessing the system out of band (meaning, doing firmware updates, essentially). In order to do so, it appears there is no master controller of the system, but rather a generic USB solution that comes with a generic USB driver that sits on top of the Windows USB Device Driver stack.

Silicon Image's USBXpress Interaction Diagram

This solution is the USBXpress device driver from Silicon Labs that we've all been dealing with. It tremendously reduces the complexity of implementing a USB interface to a device from Windows. Its drawback is that it is essentially RS-232 commands wrapped in USB wrapped in a USB wrapper which is then presented to Windows for access.

Firmware updates are timing sensitive. When a chip or processor or controller are put into firmware update mode, they typically become quite 'stupid'. The chip sits there and waits to begin receiving data. Once the data starts arriving, the chip expects it to arrive at a certain pace as it writes it at a steady pace. If any of this pace is thrown off, the process has to start over again.

With so many convoluted layers for the firmware updates to traverse, it is easy for this timing to be thrown off. In the case of most Windows PC's, there is a lot going on to help throw it off. There is also the issue that the Emotiva upgrade program appears to be interfacing with this driver in User Mode, meaning, any process (antivirus, Windows Update, USB hard drives, etc.) accessed or run in Kernel Mode will supersede its priority.

This is why the Safe Mode approach works so well, most other processes that would interfere are not started. Even benign, background Windows processes could affect the update, and there's really nothing that can be done about it. Windows Vista/7 faired generally better as the processes on those platforms have been generally updated to be generally better behaved in these situations.

Why did Emotiva use this approach? Because the development cost is low. The cost of writing their own USB device drivers would have been much higher than using a prepackaged solution. In fact, the Silicon Labs solution is a great product for most uses, but in this instance (firmware upgrade interface), it's probably not the best platform. If we wanted a $999 (or more) UMC-1, this situation could likely have been remedied. Of course, other solutions come with their own issues.

I've had personal experience with ease-of-use software solutions. Typically, there's some portion of it that's out of your hands, written by others, and you, the customer (Emotiva being the customer here) fill in the gaps with the details of your particular implementation. This means, though, that certain portion of the updater are out of Emotiva's hands. They contract a program to be written to perform the update via the Silicon Labs USBXpress interface, someone writes it, and provides it. Essentially, this is where we are today.

To change any of this would require additional development costs. The question has to be asked, is it worth it? I would say no. Once the firmware is finally stable, the entire cost of developing this solution is essentially wasted money.

It is unfortunate that early owners of the UMC-1 have to endure this process 2 or 3 times, but at the same time, it certainly isn't the worst firmware update process I've ever experienced. At least we aren't using proprietary serial cables with swapped pins and non-standard ANSI encoding. For those that claim they have done thousands of firmware upgrades, I have to assume at some point you upgraded an old network switch or SAN controller? Did you really find that using proprietary cables and a telnet or SSH program with a locally executed TFTP daemon was simpler than this solution? My point is, it's not like we're going to upgrade the firmware on the UMC-1 a couple times a week for the next 6 months.

If all goes well, one to three more updates (I'd estimate, and probably not all updates will continue to be needed by all users) and we'll all be cruising right along. And for those that can't find a friend of a cousin of a brother's PC to successfully perform the update, you'll be the few that have to send in your UMC-1. I think, overall, it is not that high of a price to pay for the incredible value and sonic performance of the UMC-1.

As wordy as this was, there's actually a lot more to this than just what I've written here. Suffice it to say, for now, the solution is what it is. In the future, I have it on good authority that in the future, the more expensive products (probably not the XMC-1, but next platform) will use more extensive (read: easier to update) solutions. As it stands, I do not see a (quick, inexpensive) way to modify the update process. This includes a post-update checksumming. It wasn't written into the original firmware updater, and to go back and do it is, again, additional cost that is probably not warranted.

Let's all hold on to our hats and continue to help each other. I'll continue to update the Emonatics UMC-1 Firmware page. Anything we, as a community, can share with each other to make the update process more consistent, will benefit us all in the long run.

Very good read Bill, was easy to follow and understand.

Thanks Bill

klinemj, stripping would not necessarily improve things. You still have to contend with natural Windows processes that might interrupt. Though, some naughty programs still find a way to get themselves running in Safe Mode. So, if you wanted to be extra careful, you could take that system, strip off the extras, and boot into Safe Mode. That would probably offer a higher level of guaranteed success.

I'm going to be taking that hat off of a UMC-1 shortly. Hopefully I can see exactly which chips are used. Based on my preliminary research, it seems pretty certain that it would be nearly impossible to "brick" one of these units. Most of the modern, firmware-upgradeable controllers out there will return to "feed me" state if an update does not complete successfully. It might not be functional (i.e. only 27% loaded with new code), but the chip would be amenable to receiving the code again. A "brick" is when the update doesn't complete and the chip is left in a state in which it will no longer accept a code update. That's ship-it-back-to-the-factory territory, and no one wants that.

Wow....really?

Personally, I find getting insight into the process makes it a little easier to put up with the surprises along the way.

But then maybe that's because I'm a geek and this sort of stuff just kinda floats my boat.

Well done, Bill. Thank you

R

mlkmgr...if I get Bill's point, it would be that v6 could be better for some folks than it is AND even if v7 were "perfect" from Emo - a corrupted install would be an issue. So, finding a good install procedure is key no matter what.

Bill - thanks for your response to my question...makes perfect sense. I just happen to have 2 old computers laying around that could serve the very purpose I mentioned. Hopefully, by the time I get my UMC-1 (or XMC-1), I won't "ever" need to upgrade the FW (insert LOL here...), but...just in case.

Rsavage: geek #2 here - standing along side you in agreement re. loving this kind of stuff!

Mark

I answered your other questions in another post. I wanted to touch on this, though. I believe it does matter. When Emotiva does ship the next update, we're all going to be using this process, so I think it helps people to understand where we stand on trying to get that next update on to our UMC-1's. There may be those that were holding out some sort of hope that there would be a new update procedure, and I am saying with some 99%+ degree of certainty that there will not be. I am also saying that this procedure can be made to work, even if it isn't ideal, and the trade off for not being ideal is a very reasonably priced, high performing (when bugs are fixed), product.

You realize how ducked up that sounds, right? That's enough to make me swear off this thing forever.

No, I don't. I find it all very reasonable. Others find it completely intolerable.

Luckily, there are a lot of posts here about alternative pre/pros that you could check out. I'm using a very nice Onkyo 885 here, you might look into one of those, or something like it.

I wouldn't encourage anyone whom already harbors serious animosity toward any product to pursue it, keep it, or otherwise. For example, I don't like Apple products (that's an understatement), so I don't buy them. I tried one, I resold it. Despite that, Apple has somehow remained in business, much to my amazement. By this deductive reasoning, I have concluded that Emotiva will remain in business despite those that "swear off [the UMC-1] forever".

I'm saying that it would be an additional development effort. Nothing is impossible, but it all has to do with cost. I am going to do a little poking around to determine the scope of exactly this, as I'm an advocate of this sort of approach. Don't get your hopes up, it isn't as simple as open, write, close.