Issue with Vista 64-bit recognizing Cypress CY7C68013A (FX2LP) VID 0x04B4 PID 0x8613

[John_F_Matsumoto]

Hello Everyone,
We use the Cypress FX2LP in our USB products. Currently all our USB products and our engineering proto-types get loaded with a blank EEPROM on the PCBs. We then use custom utilities and a custom driver (developed in-house and run only with XP 32-bit) which recognizes the Cypress’ VID and PID. These utilities then program the EEPROMs with our firmware and with our VID and PID (the same driver is used for both manufacturing and engineering). We try very hard to prevent this driver from ever leaving our facility. We have now made a decision move toward Vista 64-bit. One of the many reason to do this is that we will never sign this utility driver. We feel that this will add one more level “safety” on the use of this device driver.

So we ported our driver for Vista 64-bit and setup our test platform with Vista-Ultimate 64-bit (This system is running with dual Opterons). The machine was booted up but we did not invoke the F8 bypass for unsigned drivers. We then inserted our FX2LP product (which has a blank EEPROM) into our test platform’s USB port. We were then given three choices:

Locate and install driver software (recommended)

Ask me again later

Don’t show this message again for this device.

I selected the “Locate and install driver software (recommended)” option. To my surprise a dialog box popped up that stated “DVB-T USB 2.0 adapter loader”. No new hardware showed up in the device manager, but USBview kept bouncing around showing either “Thesys Microelectronics” or “DVB-T USB 2.0 Adapter Loader”. Looking at the USB trace, I can see a successful enumeration process with the Cypress VID (0x04B4) and PID (0x8613) as the target device. The next statements that follow are just a guess. It looks like there is a FX2LP firmware download. At the end of the download, the FX2LP is taken out of reset. For a momentary instant, some of the FX2LP I/O pins are toggled (this is a drag because some of the I/O driven from the FX2LP collides with the outputs of other devices we have attached to the FX2LP’s PIO). At this point, the FX2LP will disconnect from the USB port and then renumerates again as a Cypress device (VID 0x04B4, PID 0x8613). Then the whole cycle repeats forever. I THINK this is why I’m not able to find this hardware device because it is continuously connecting-disconnecting-connecting… Now, no matter which USB port I plug into, this infinite cycle occurs. My questions are:

1. How do I kill this loader? I’m thinking it must be a BDA thing, but I can’t seem to find where to disable it.

2. How do I guarantee that my unsigned driver is the one chosen when someone pushes the “Locate and install driver software” button?

3. Will I have this problem with Vista 32-bit?

The rhetorical question I have is how did DVB-T get a signed driver using a Cypress vendor and product ID? My guess is that the loader happens once in the beginning and they come back as a different device when they renumerate, but I still think it’s not a good idea to use someone else’s ID.

Thanks,
Motz

John Matsumoto
Surface Optics Corporation

[Chris_Aseltine]

This is the only match for 04B4/8613 on Vista x64 RTM that I can see:

[AngelUsb.Device.NTamd64…1]
%AngelUsb.DeviceDesc%=AngelUsb.Install.NTamd64,USB\VID_1009&PID_0013

;;;;;;;;;; Cypress FX2 NO ROM
;%AngelUsb.DeviceDesc%=AngelUsb.Install.NTamd64,USB\VID_04B4&PID_8613
;;;;;;;;;; Cypress FX2 empty ROM
;%AngelUsb.DeviceDesc%=AngelUsb.Install.NTamd64,USB\VID_FFFF&PID_FFFF

Note that the 04B4 and FFFF PIDs are commented out. Are you running RTM or an earlier version?

[John_F_Matsumoto]

Hi Chris,
Thanks for getting back to me. I’m fairly sure I’m using the RTM. When I look at what edition I’m running it states only Windows Vista Ultimate. Ths system files are tagged with a version 6.0.6000.16386. The MSDN DVD I used to load the OS onto this test platform is Windows Vista (x64), English, Disc 3708, January 2007.

Where did you find the above instance of the 0x04B4 VID?

Thanks,
Motz

[John_F_Matsumoto]

Hi All,
I’ve tracked down the driver that recognizes the Cypress VID, PID and I prevented it from loading. I’m now able to force Vista (x64) to load my driver. Just for completeness sake, the properties of the driver that I disabled are:

modload2.inf
modload2.sys

Driver Provider: KWorld
Driver Date: 2/5/2007

DiBGcom S.A
File version: 6.0.0.5
Digital Signer: Microsoft Windows Hardware Compatibility

In the inf that ID’s the Cypress IDs’ are the lines:

.
.
[KWorld.NTx86]
%MODLOAD2.DeviceDesc%=LOADER.Device, USB\VID_04B4&PID_8613 ; FX2 hardware, virgin EEPROM
.
.
[KWorld.NTAMD64]
%MODLOAD2.DeviceDesc%=LOADER.Device, USB\VID_04B4&PID_8613 ; FX2 hardware, virgin EEPROM
.
.

Also, this was a clean install of Vista (x64) and all critical and non-critical updates were applied. Our device was the very first device ever plugged into this machine.

Thanks,
Motz

[Tim_Roberts]

xxxxx@surfaceoptics.com wrote:

I’ve tracked down the driver that recognizes the Cypress VID, PID and I prevented it from loading. I’m now able to force Vista (x64) to load my driver. Just for completeness sake, the properties of the driver that I disabled are:

modload2.inf
modload2.sys

Driver Provider: KWorld
Driver Date: 2/5/2007

DiBGcom S.A
File version: 6.0.0.5
Digital Signer: Microsoft Windows Hardware Compatibility

In the inf that ID’s the Cypress IDs’ are the lines:

.
.
[KWorld.NTx86]
%MODLOAD2.DeviceDesc%=LOADER.Device, USB\VID_04B4&PID_8613 ; FX2 hardware, virgin EEPROM
.
.
[KWorld.NTAMD64]
%MODLOAD2.DeviceDesc%=LOADER.Device, USB\VID_04B4&PID_8613 ; FX2 hardware, virgin EEPROM
.
.

Also, this was a clean install of Vista (x64) and all critical and non-critical updates were applied. Our device was the very first device ever plugged into this machine.

The folks at WHQL must have had rocks in their head the day they allowed
this to slip through. This will match every out-of-the-box unconfigured
FX2 chip in the world, and since it is signed and in the driver library,
it’s going to be darn near impossible for anyone to load their own
custom firmware loader.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Chris_Aseltine]

Tim Roberts wrote:

The folks at WHQL must have had rocks in their head the day
they allowed this to slip through. This will match every
out-of-the-box unconfigured FX2 chip in the world, and
since it is signed and in the driver library, it’s going to be
darn near impossible for anyone to load their own
custom firmware loader.

Our Vista x64 machine doesn’t have modload2.inf. It’s been installed from the MSDN image and had nothing but our drivers loaded on it. So I don’t see how modload2.inf is an inbox driver, if that’s what you’re implying.

[OSR_Community_User]

This is a naive and not totally detailed explanation (because I’m not intimately familiar with this aspect of device installation on Vista), but there is a driver compatibility list maintained for Vista, and as long as a machine has internet connectivity, it will load WHQL’d drivers from Windows Update or such directly to the machine [if the user selects the “recommended” method from the initial popup].

So no, it is not an inbox driver. But [obviously enough] it having received a logo and being on the compatibility list under these circumstances certainly presents a problem.

[Tim_Roberts]

xxxxx@gmail.com wrote:

Tim Roberts wrote:

> The folks at WHQL must have had rocks in their head the day
> they allowed this to slip through. This will match every
> out-of-the-box unconfigured FX2 chip in the world, and
> since it is signed and in the driver library, it’s going to be
> darn near impossible for anyone to load their own
> custom firmware loader.
>

Our Vista x64 machine doesn’t have modload2.inf. It’s been installed from the MSDN image and had nothing but our drivers loaded on it. So I don’t see how modload2.inf is an inbox driver, if that’s what you’re implying.

The OP said they had done all required and optional updates. As I
understand it, the Windows update process will go search the central
driver library for matches on PnP ids, and any such matches will be
pushed as an optional update. It’s not “inbox” in the sense of “on the
Vista CD”, but it’s “inbox” in the sense of “in the WHQL-approved and
update-pushed driver library.”

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[John_F_Matsumoto]

I believe Tim and Bob are correct. The folder date for this driver (in the DriverStore) is the date of my installation.

Motz

[Michal_Vodicka-2]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
Reply To: Windows System Software Devs Interest List
Sent: Monday, March 19, 2007 6:12 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A (FX2LP) VID 0x04B4 PID 0x8613

The folks at WHQL must have had rocks in their head the day they allowed
this to slip through. This will match every out-of-the-box unconfigured
FX2 chip in the world, and since it is signed and in the driver library,
it’s going to be darn near impossible for anyone to load their own
custom firmware loader.

It is possible but it is necessary to have some knowledge which usually only people reading lists like this have Recently, coworker who is working with Cypress board asked me for help with exactly this problem. It was at XP and the fw loader driver was installed using oemNN.inf; coworker had no idea which piece of software installed it. It was a bit challenging to find what really occurs there but finally we found the “fw loader” driver and disabled it manually in the registry (I changed Start from 3 to 4). Next time when the board was plugged it, the device was marked as problem in the device manager and it was possible to manually update driver to the desired one.

I found whole firmware loader idea quite funny (especially the part which changes device VID&&PID) and even funnier that such a driver is WHQL signed. But I didn’t even imagine MS would make such a driver automatically installed.

Seriously, I’m not sure if the automatic download for matching IDs work for XP, too. If so, it’d explain how the rogue fw loader installed on coworker’s machine and several others he tried.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

[David_J_Craig]

Having read a little in the newsgroups about the Cypress chips where the
smaller companies release the board with the Cypress VID/PID unchanged, I am
wondering if that driver might be the same Cypress driver that anyone can
use to install updated firmware and VID/PID. If there is a generic driver,
then it may make sense for Microsoft to sign it. If it is really a
specialized driver for one implementation of a board that is unique or not
standard, then Microsoft blew it big time.

I still think that all vendors should have the correct VID/PID and base
firmware installed during manufacturing, but I guess it might be a little
pricey for small volume devices. Maybe I should get the OSR kit just for
fun.

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Monday, March 19, 2007 6:12 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Issue with Vista 64-bit recognizing Cypress
> CY7C68013A (FX2LP) VID 0x04B4 PID 0x8613
>
> The folks at WHQL must have had rocks in their head the day they allowed
> this to slip through. This will match every out-of-the-box unconfigured
> FX2 chip in the world, and since it is signed and in the driver library,
> it’s going to be darn near impossible for anyone to load their own
> custom firmware loader.
>
It is possible but it is necessary to have some knowledge which usually only
people reading lists like this have Recently, coworker who is working
with Cypress board asked me for help with exactly this problem. It was at XP
and the fw loader driver was installed using oemNN.inf; coworker had no idea
which piece of software installed it. It was a bit challenging to find what
really occurs there but finally we found the “fw loader” driver and disabled
it manually in the registry (I changed Start from 3 to 4). Next time when
the board was plugged it, the device was marked as problem in the device
manager and it was possible to manually update driver to the desired one.

I found whole firmware loader idea quite funny (especially the part which
changes device VID&&PID) and even funnier that such a driver is WHQL signed.
But I didn’t even imagine MS would make such a driver automatically
installed.

Seriously, I’m not sure if the automatic download for matching IDs work for
XP, too. If so, it’d explain how the rogue fw loader installed on coworker’s
machine and several others he tried.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

[Michal_Vodicka-2]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David Craig[SMTP:xxxxx@yoshimuni.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, March 20, 2007 1:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A (FX2LP) VID 0x04B4 PID 0x8613

Having read a little in the newsgroups about the Cypress chips where the
smaller companies release the board with the Cypress VID/PID unchanged, I am
wondering if that driver might be the same Cypress driver that anyone can
use to install updated firmware and VID/PID.

I don’t think so because my coworker needed to replace the driver with Cypress one so he can load own firmware. But I haven’t examined all details. I just remember there was “DVB-T something” driver involved which OP mentioned.

If there is a generic driver,
then it may make sense for Microsoft to sign it.

Maybe but how would the generic driver find the correct firmware to upload? The signed package should be self-contained.

If it is really a
specialized driver for one implementation of a board that is unique or not
standard, then Microsoft blew it big time.

I wouldn’t be so surprised; it seems WHQL process is mostly automatic now (and fast which is great). But maybe we’re missing something.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

[David_J_Craig]

I would hope that Cypress would have documented an interface for a boot or
system start driver to use that Cypress driver to update the firmware. If
the hardware interface to the firmware varies according to the hardware
design, then Cypress probably cannot create such a driver. They may specify
a design that should be used to provide updatable flash ROM for the board
and their chip, but I don’t know.

I would design it so that anyone implementing a valid flash or volatile ROM
using their design would be able to have a root enumerated driver that would
detect the standard PnP firmware upload driver and pass it the code to load.
Then when the device gets the code loaded it would cause a enumeration of
the stack. This would make the standard driver unload and the correct one
to load.

I have wondered if several devices, all based upon the Cypress chip, are
installed and use the firmware load trick, how each can know which device is
theirs. Looks like two trains on the same track going in the opposite
direction to me. How do you tell the user that they can’t use your device
with other devices based upon the Cypress chip that have not modified the
VID/PID during manufacturing? If you have a high volume manufacturing
situation wouldn’t it be cheaper to have the chip logic combined with your
own in a single ASIC?

Having been in a company that had Atmel do a low power ASIC with CPU for the
Smarty Smartcard reader and the Flashpath line, I know it became a lot
cheaper in high volumes. The NRE was significant, but when spread across
production runs exceeding 100k per month, it becomes a minor expense. Our
ASIC engineer did the design, but it was verified by Atmel as part of their
production process.

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of David Craig[SMTP:xxxxx@yoshimuni.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, March 20, 2007 1:56 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A
> (FX2LP) VID 0x04B4 PID 0x8613
>
> Having read a little in the newsgroups about the Cypress chips where the
> smaller companies release the board with the Cypress VID/PID unchanged, I
> am
> wondering if that driver might be the same Cypress driver that anyone can
> use to install updated firmware and VID/PID.
>
I don’t think so because my coworker needed to replace the driver with
Cypress one so he can load own firmware. But I haven’t examined all details.
I just remember there was “DVB-T something” driver involved which OP
mentioned.

> If there is a generic driver,
> then it may make sense for Microsoft to sign it.
>
Maybe but how would the generic driver find the correct firmware to upload?
The signed package should be self-contained.

> If it is really a
> specialized driver for one implementation of a board that is unique or not
> standard, then Microsoft blew it big time.
>
I wouldn’t be so surprised; it seems WHQL process is mostly automatic now
(and fast which is great). But maybe we’re missing something.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

[John_F_Matsumoto]

One of the Cypress FX2LP’s mechanism is it can do a firmware
download using your companies VID and PID. The desired VID and PID are
programmed into a serial EEPROM before your product leaves the door. That
way you can download your firmware to your device using your driver (FYI,
the firmware does not have to be in the device driver). If this brand new
signed loader is the universal solution, it sure didn’t find my firmware,
but it sure downloaded something into my device. Additionally, in the FX2
technical reference manual it specifically states to not use the Cypress
ID’s.

Also, another self-inflicted problem I’ve ran into was that when I
was trying to figure out what was going on, I plugged our blank device into
all six (6) of my USB ports. The side effect of this is that this loader, as
Michal pointed out, now has multiple entries in the registry. So I had to
disable modload2 port by port.

1. If this is truly a Microsoft signed driver (and not a virus) that is in
   their driver compatibility list, where do I send a request to ask if
   Microsoft would please consider removing this driver from its update site?

Our product developers and manufacturing engineers, who know nothing
about system files or registry entries, will push the “recommended” button
and I can’t seem to come up with a really easy way to load our driver once
the “recommended” path is taken. Any suggestions would be greatly
appreciated.

Thanks,
Motz

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Monday, March 19, 2007 7:22 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A
(FX2LP) VID 0x04B4 PID 0x8613

I would hope that Cypress would have documented an interface for a boot or
system start driver to use that Cypress driver to update the firmware. If
the hardware interface to the firmware varies according to the hardware
design, then Cypress probably cannot create such a driver. They may specify

a design that should be used to provide updatable flash ROM for the board
and their chip, but I don’t know.

I would design it so that anyone implementing a valid flash or volatile ROM
using their design would be able to have a root enumerated driver that would

detect the standard PnP firmware upload driver and pass it the code to load.

Then when the device gets the code loaded it would cause a enumeration of
the stack. This would make the standard driver unload and the correct one
to load.

I have wondered if several devices, all based upon the Cypress chip, are
installed and use the firmware load trick, how each can know which device is

theirs. Looks like two trains on the same track going in the opposite
direction to me. How do you tell the user that they can’t use your device
with other devices based upon the Cypress chip that have not modified the
VID/PID during manufacturing? If you have a high volume manufacturing
situation wouldn’t it be cheaper to have the chip logic combined with your
own in a single ASIC?

Having been in a company that had Atmel do a low power ASIC with CPU for the

Smarty Smartcard reader and the Flashpath line, I know it became a lot
cheaper in high volumes. The NRE was significant, but when spread across
production runs exceeding 100k per month, it becomes a minor expense. Our
ASIC engineer did the design, but it was verified by Atmel as part of their
production process.

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of David Craig[SMTP:xxxxx@yoshimuni.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, March 20, 2007 1:56 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A

> (FX2LP) VID 0x04B4 PID 0x8613
>
> Having read a little in the newsgroups about the Cypress chips where the
> smaller companies release the board with the Cypress VID/PID unchanged, I
> am
> wondering if that driver might be the same Cypress driver that anyone can
> use to install updated firmware and VID/PID.
>
I don’t think so because my coworker needed to replace the driver with
Cypress one so he can load own firmware. But I haven’t examined all details.

I just remember there was “DVB-T something” driver involved which OP
mentioned.

> If there is a generic driver,
> then it may make sense for Microsoft to sign it.
>
Maybe but how would the generic driver find the correct firmware to upload?
The signed package should be self-contained.

> If it is really a
> specialized driver for one implementation of a board that is unique or not
> standard, then Microsoft blew it big time.
>
I wouldn’t be so surprised; it seems WHQL process is mostly automatic now
(and fast which is great). But maybe we’re missing something.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Rob_Linegar]

>> I would hope that Cypress would have documented an interface for a
boot or

> system start driver to use that Cypress driver to update the
firmware.

Yes they do more than that. They give out full source for a firmware
upload driver.
The method has barely changed between the old and newer generation
chips.

> I have wondered if several devices, all based upon the Cypress chip,
are
> installed and use the firmware load trick, how each can know which
device is
> theirs.

Uh!? We’ve used several generations of the ez-usb product in this state.
Upto and including FX2 with no problem.
I have also successfully all generations of these devices throught WHQL.

The answer is… To use TWO vid/pid’s… Unconfigured, and configured.

As a previous poster stated. The Unconfigured VID/PID is also allocated
from your companies range and preprogrammed in an eeprom. When your
device is inserted this “default” empty state is what is seen… And the
USB device driver (your firmware loader driver) associated with that
VID/PID is loaded. You then get this driver to upload the ‘real
firmware’ (which can be stored on disk OR in the driver itself… Doesn’t
matter). You then use a couple command’s to reset the device and it will
unload. And the final VID/PID will be seen by windows, and the final
driver will load.

BR,

Rob Linegar
Software Engineer
Data Encryption Systems Limited
www.des.co.uk | www.deslock.com

[Tim_Roberts]

Michal Vodicka wrote:

I found whole firmware loader idea quite funny (especially the part which changes device VID&&PID)…

Really? It is by far the simplest solution to this problem. It’s
certainly possible to use the same VID/PID for unconfigured and
configured devices, by having the driver test for the presence of a
custom vendor command, but you still need to re-enumerate because the
descriptors have to change. Might as well let PnP do some of the work.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Tim_Roberts]

David Craig wrote:

I would hope that Cypress would have documented an interface for a boot or
system start driver to use that Cypress driver to update the firmware.

Cypress provides a sample driver to load firmware into an unconfigured
FX2. The firmware is usually compiled in to that driver. The Cypress
sample drivers all support a “reload the firmware” ioctl, although we
usually remove that in our production drivers.

If the hardware interface to the firmware varies according to the hardware
design, then Cypress probably cannot create such a driver. They may specify
a design that should be used to provide updatable flash ROM for the board
and their chip, but I don’t know.

The FX2 has very basic firmware built in. At boot time, that firmware
goes out to look for an EEPROM to supply its initial USB descriptors.
If no EEPROM is found, it falls back to the 04B4/8613 that caused the
trouble to begin with. Any designer who plans to release his device
into the wild will supplies a small EEPROM with descriptors that have a
custom VID/PID that identifies their specific unconfigured device. This
triggers the customized firmware loader, which loads the real firmware
and the real descriptors.

Not including that boot EEPROM is a negligent act. Cypress warns
against it. Even QuickUSB, who makes a simple FX2 development board,
puts in an EEPROM with their own VID/PID.

I have wondered if several devices, all based upon the Cypress chip, are
installed and use the firmware load trick, how each can know which device is
theirs.

The small boot EEPROM holds the answer here. Every unconfigured device
should have one.

How do you tell the user that they can’t use your device
with other devices based upon the Cypress chip that have not modified the
VID/PID during manufacturing? If you have a high volume manufacturing
situation wouldn’t it be cheaper to have the chip logic combined with your
own in a single ASIC?

You are absolutely correct. No one planning to produce millions of
units would ever pay the price for an FX2 in each unit. However, the
fun of the FX2 is that you can make a nice living with sales in the
hundreds or thousands.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[David_J_Craig]

I see someone did it correct, but it seems someone didn’t. Maybe Microsoft
has that driver just to make it hard for the bad designs to work. It sounds
like something I would want to do if I had the power and worked at
Microsoft. No one has said what version information is available for the
‘problem’ driver. Is it Cypress or Microsoft or another company with a bad
design who happened to get it signed?

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> David Craig wrote:
>> I would hope that Cypress would have documented an interface for a boot
>> or
>> system start driver to use that Cypress driver to update the firmware.
>
> Cypress provides a sample driver to load firmware into an unconfigured
> FX2. The firmware is usually compiled in to that driver. The Cypress
> sample drivers all support a “reload the firmware” ioctl, although we
> usually remove that in our production drivers.
>
>> If the hardware interface to the firmware varies according to the
>> hardware
>> design, then Cypress probably cannot create such a driver. They may
>> specify
>> a design that should be used to provide updatable flash ROM for the board
>> and their chip, but I don’t know.
>>
>
> The FX2 has very basic firmware built in. At boot time, that firmware
> goes out to look for an EEPROM to supply its initial USB descriptors.
> If no EEPROM is found, it falls back to the 04B4/8613 that caused the
> trouble to begin with. Any designer who plans to release his device
> into the wild will supplies a small EEPROM with descriptors that have a
> custom VID/PID that identifies their specific unconfigured device. This
> triggers the customized firmware loader, which loads the real firmware
> and the real descriptors.
>
> Not including that boot EEPROM is a negligent act. Cypress warns
> against it. Even QuickUSB, who makes a simple FX2 development board,
> puts in an EEPROM with their own VID/PID.
>
>> I have wondered if several devices, all based upon the Cypress chip, are
>> installed and use the firmware load trick, how each can know which device
>> is
>> theirs.
>
> The small boot EEPROM holds the answer here. Every unconfigured device
> should have one.
>
>> How do you tell the user that they can’t use your device
>> with other devices based upon the Cypress chip that have not modified the
>> VID/PID during manufacturing? If you have a high volume manufacturing
>> situation wouldn’t it be cheaper to have the chip logic combined with
>> your
>> own in a single ASIC?
>>
>
> You are absolutely correct. No one planning to produce millions of
> units would ever pay the price for an FX2 in each unit. However, the
> fun of the FX2 is that you can make a nice living with sales in the
> hundreds or thousands.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

[Michal_Vodicka-2]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of John Matsumoto[SMTP:xxxxx@surfaceoptics.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, March 20, 2007 10:04 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A (FX2LP) VID 0x04B4 PID 0x8613

1. If this is truly a Microsoft signed driver (and not a virus) that is in
   their driver compatibility list, where do I send a request to ask if
   Microsoft would please consider removing this driver from its update site?

I hope the WHQL signature was really coming from MS. Which, of course, doesn’t necessarily mean it isn’t a virus

Our product developers and manufacturing engineers, who know nothing
about system files or registry entries, will push the “recommended” button
and I can’t seem to come up with a really easy way to load our driver once
the “recommended” path is taken. Any suggestions would be greatly
appreciated.

We did it following way:

• identify the firmware loader driver entry in the registry (HKLM\System\CCS\Services<fw_loader_name>
  - unplug Cypress board(s)
  - change fw loader Start value from 3 to 4
  - plug the board back
  - in the Device Manager, board is marked with question mark because OS has problem loading driver
  - right click, Update driver and now it is possible to manually select something else than rogue fw loader
  - it is necessary to repeat process for every port where it was plugged
  
  You can make whole process a bit easier by creating .reg file which changes the Start value but beware about systems where rogue fw loader was never installed. For product developers above description should be enough, for manufacturing engineers add screenshots and for marketing persons (if involved) create Power Point presentation
  
  HTH
  
  Best regards,
  
  Michal Vodicka
  UPEK, Inc.
  [xxxxx@upek.com, http://www.upek.com]</fw_loader_name>

[Michal_Vodicka-2]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Rob Linegar[SMTP:xxxxx@des.co.uk]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, March 20, 2007 10:47 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Issue with Vista 64-bit recognizing Cypress CY7C68013A (FX2LP) VID 0x04B4 PID 0x8613

>> I have wondered if several devices, all based upon the Cypress chip,
are
>> installed and use the firmware load trick, how each can know which
device is
>> theirs.

Uh!? We’ve used several generations of the ez-usb product in this state.
Upto and including FX2 with no problem.
I have also successfully all generations of these devices throught WHQL.

The answer is… To use TWO vid/pid’s… Unconfigured, and configured.

As a previous poster stated. The Unconfigured VID/PID is also allocated
from your companies range and preprogrammed in an eeprom. When your
device is inserted this “default” empty state is what is seen… And the
USB device driver (your firmware loader driver) associated with that
VID/PID is loaded. You then get this driver to upload the ‘real
firmware’ (which can be stored on disk OR in the driver itself… Doesn’t
matter). You then use a couple command’s to reset the device and it will
unload. And the final VID/PID will be seen by windows, and the final
driver will load.

This way it makes sense. The problem is the firmware loader which is apparently loaded automatically from MS uses original Cypress VID/PID. For us, who aren’t familiar with Cypress boards, the above question is obvious. If you plug-in several boards with original VID/PID, they will all receive the same firmware from rogue loader driver.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]