I've submitted a service request on this about a week and a half ago, but haven't heard anything back, so I thought I'd try here. (Service request 1-707218642 )
We've implemented a TUSB9260 into a design here: The part is being used to interface to a SATA DVD drive from a HS USB port on a Windows XP based embedded system. (This replaces an IDE DVD drive that is going EOL.)
We have an issue with our manufacturing process that perhaps could be solved with custom firmware for the TUSB9260. We manufacture our systems using a "ghosting" process for the hard drives: A working system is essentially cloned and "ghosted" onto the hard drive for each new system, (with a subsequent step, of course to install license files and such) The way our applicaton software works, it expects the DVD drive to show up as Drive E: (there is no drive D: in the system). Now previously (with the old IDE drive) this worked fine, Windows PnP saw the "same" DVD drive in each new system that was produced, and kept the DVD drive at E:. Now, however with the TUSB926 + SATA drive, Windows PnP sees a "new" drive in almost every system that is produced, and installs that drive as drive D: in the system. We have a temporary work-around in production to manually move that drive to E:, but it adds several minutes to the production of each system. The reason Windows does this, apparently, is that the descriptor string returned by the TUSB9260 chip contains some sort of semi-unique serial number for each individual TUSB9260 chip. (I say semi-unique because occasionally a system will boot up with the drive at E:, indicating that it saw the same id string as the original system)
Here's a couple of examples of the device ID strings in Windows:
USB\VID_0451&PID_9260\4057D01520110720131015250DA2C38FA
USB\VID_0451&PID_9260\3FACE06C20110720132221687DA2C38FA
As you can see, some parts of the string stay the same ("2011072013" and "DA2C38FA"). and some don't.
So is it possible to get a version of the firmware that always returns the same idstring?
Thanks.