Cypress EZ-USB FX Firmware Download

I am designing a new USB device that contains the Cypress EZ-USB FX
chip.  I am trying to download some very simple/basic firmware code to
the EZ-USB FX chip through the Cypress USB Control Panel.  Before I get
too far, let me start this by saying that the device does enumerate as
a Cypress EZ-USB - EEPROM Missing device.

With that said, as soon as I select the .hex file to download firmware
to the device, the Control Panel freezes until I reset my USB device.
I have monitored the USB traffic via a CATC USB Chief Bus & Protocol
Analyzer.  The problem arises when a Control Write (vendor specific
firmware upload) is performed to CPUCS (0x7F92) with a value of 0x01.
Writing 0x01 to CPUCS holds the 8051 in a reset state until all the
firmware has been downloaded and the device has been renumerated.

So anyway, the Control Write to CPUCS with a value of 0x01 is initiated
by the host with a SETUP Packet (followed by a data packet) which is
ACKed by my device.  Then an OUT packet is sent (followed by a data
packet) with the value to be written to CPUCS (0x7F92).  This OUT
packet is NAKed by my device.  From this point on, any kind of OUT
packet sent in an attempt to send the Control Write value of 0x01 to
the device is NAKed by the device.

It seems as if the device just doesn't want the host taking the 8051
core into a reset state...  I can't find anything in the EZ-USB FX spec
to denote a similar behavior, so I'm hoping someone out in the digital
world may have a tip or two.

Thanks for any insight on any of the above discussion topics.

Larry

larry.kiss@gmail.com wrote:

> It seems as if the device just doesn't want the host taking the 8051 
> core into a reset state...  I can't find anything in the EZ-USB FX
> spec to denote a similar behavior, so I'm hoping someone out in the
> digital world may have a tip or two.

The EZUSB download does indeed hold the FX in reset via a write to 
0x7F92. So that is correct behaviour.

However, why your device is NAK'ing subsequent OUT packets, I can't say. 
Nor have I used the Cypress CP for a *long* time. I've been using the 
'ezloader' windows driver without (major) problems for 3 different 
designs now.

For one product, we built a few boards up by hand with a slightly 
under-sized footprint for the EZUSB. We also forgot to ground a few of 
the reserved pins (you have to), so there was a patch wire or two. Not 
surprisingly, a couple of the boards wouldn't come up properly. One 
board did enumerate as a vanilla Cypress EZUSB, but would refuse to 
download firmware! We don't have access to a USB protocol analyser, but 
no amount of inspection/rework revealed or corrected the problem.

The reason I bring this up is I'm wondering if you're suffering from a 
similar assembly problem? Are you able to try another PCBA?

Regards,
Mark

I know you say you are using the FX but the FX2 and FX2LP have the CPUCS at 
0xE600; might that be the problem?

<larry.kiss@gmail.com> wrote in message 
news:1123439528.782285.303600@f14g2000cwb.googlegroups.com...
>I am designing a new USB device that contains the Cypress EZ-USB FX

.....

> firmware upload) is performed to CPUCS (0x7F92) with a value of 0x01.
> Writing 0x01 to CPUCS holds the 8051 in a reset state until all the
> firmware has been downloaded and the device has been renumerated.
> 

I don't have a choice as to what register address CPUCS is being
accessed at.  When using the Cypress USB Control Panel to download
firmware, you specificy the .hex file, and it will does a number of
things before and after it sends the hex file.  One thing it does is
hold 8051 core in reset by sending a 0x01 to CPUCS register.  I don't
have control over which register is being written to.  But, to answer
your question, No it's probably not the problem.  I have a technical
reference manual for the FX chip and it is the correct register being
accessed.  

Thanks for taking the time to respond.

Larry

>The EZUSB download does indeed hold the FX in reset via a write to
>0x7F92. So that is correct behaviour.

This is correct behavior, but I can't assume that it is even happening
in my situation.  The data stage of the control write is never ACKed by
the device, to acknowledge that it has received the command to hold the
8051 in reset.

> We also forgot to ground a few of the reserved pins (you have to), so there was a patch wire or > two. Not surprisingly, a couple of the boards wouldn't come up properly.

This was the first thing I started looking at when having issues.  I
will triple check since it has affected your previous designs.

>  Are you able to try another PCBA?

This is for an independent study for graduate school and resources are
limited.  So, to try another PCB would not be a viable solution, yet!


Thanks,

Larry

<larry.kiss@gmail.com> wrote in message
news:1123439528.782285.303600@f14g2000cwb.googlegroups.com...
> I am designing a new USB device that contains the Cypress EZ-USB FX
> chip.  I am trying to download some very simple/basic firmware code to
> the EZ-USB FX chip through the Cypress USB Control Panel.  Before I get
> too far, let me start this by saying that the device does enumerate as
> a Cypress EZ-USB - EEPROM Missing device.
>
> With that said, as soon as I select the .hex file to download firmware
> to the device, the Control Panel freezes until I reset my USB device.

Not sure I understand.
As soon as you select it or download it?

I wrote my own downloader in my app but I don't recall having any problems
with functional code in the control panel as far as downloads go.

This happens with any code? Remember the hex files for the downloader have
to be prepared for the FX2. Regular hex files won't work.