If anybody out there has done any work with the Cypress EZ-USB FX2 device, specifically in getting it to continue to talk after the PC goes into standby mode (and comes out again). The Cypress sample code doesn't work and their technical support seem unwilling/unable to help. It also appears to do different things on different platforms and different versions of windows. For the most part, the FX2 goes into sleep mode but does not come back out again aftewards even though Windows still shows it in the device list, you can't communicate with it. Any help would be appreciated.
My software started off as one of the Cypress sample programs for bulk transfers. The sleep function is untouched (although I have tried a number of things to make it work, initially it was unchanged) Windows software is a C program that uses the ezusb.sys and makes bulk usb calls. After the computer comes back from standby the firmware won't come out of the sleep function on some computers, comes out and reenters and stays there on other computers and on one computer (laptop) it keeps the computer from going into sleep mode. Let me know if this answers your questions. M
while you're being so helpful, you don't happen to have an inf file that does the firmware download and then runs the cyusb.sys, do you? Looking at the cypress inf examples, there doesn't seem to be a complete one, Thanks, M
With a AN2131 project, my firmware gets compiled into a system file and the inf file first loads my firmware and then re-enumerates using the ezusb.sys file. Are you telling me this is different for the FX? One of the sample inf files talks about a scripting feature to download firmware. It is not clear to me whether you only load the cyusb.sys and then use it to download firmware (scripting?) or are you suggesting that my application downloads the firmware when it starts? What does the device enumerate as until the app loads the firmware? Thank you for your continued help... M
That's how I do it. You can also load your firmware into the EEProm and have the FX load it from there on power up. I don't know anything about scripting or loading firmware from the inf..
What does the device enumerate as until the app loads the
You will have to go over the FX docs to get a complete description as to how this works as I have little time to lay it all out. The device will enumerate as a Cypress device unless you have your own VID/PID in the EEProm.. once your app identifies it you download the firmware and re-enum..
Let me explain this behaviour to you from a Windows driver developer point-of-view.
What happens, is that you plug in the FX chip without any EEPROMs attached to the circuitry. This causes the FX to use it's in-built bootloader firmware, which identifies the chip with the factory PID/VID. At some point when installing the application development environment to your computer, you've undoubtly installed what we call a 'firmware loader driver'. This driver is a Windows system file that is registered to support an USB device with the factory PID/VID of the FX device. The driver also carries with it an INF file, that identifies the driver, and contains some relevant data that the driver needs. When you install the driver, the INF file is used to make the registry entries. One of the entries written to the registry is the name of the firmware file that you wish to upload to the device.
So, FX is plugged in, boots with the default firmware, and identifies as such. Windows detects this and uses the registry information to load the Cypress-provided 'firmware loader driver'. The firmware loader uses the registry information to find and upload in the firmware file to the FX device. The bootcode of FX, when the upload is complete, resets the device, efficiently setting the program counter to point at the start of your firmware code, which was just uploaded to the RAM or EEPROM memory, case-dependant. Your firmware then proceeds to re-identify the device with new PID/VID codes and a new driver on Windows end is loaded to support this different device.
If your firmware was loaded into the RAM, the firmware is lost from the device when it is powered off. In this case, when you power it up again, it identifies with the default PID/VID first, loading the 'firmware loader driver', uploading the firmware to the device and then re-enumerating.
This bootloader process can be by-passed by loading your firmware to the EEPROM. In such case, FX only enumerates once to Windows, with the PID/VID you've specified in the firmware.
From CY7C64713 technical document, page 3, chapter 4.6, it's stated:
"When first plugged in into USB, the FX1 enumerates automatically and downloads firmware and USB descriptor tables over the USB cable. Next, the FX1 enumerates again, this time as a device defined by the downloaded information."
This functionality requires a driver in the Windows end, with a registry entry that specifies the name of the firmware file. Efficiently just like I explained in my previous post. It's a common behaviour model that many USB chip manufacturers use.
Furthermore, in chapter 4.5:
"... EEPROM whose first byte is either 0xC0 or 0xC2. If found, it uses the VID/PID/DID values in the EEPROM in place of the internally stored values (0xC0) or it boot-loads the EEPROM contents into internal RAM (0xC2)."
And here you can either load the entire replacement firmware (0xC2) or just the VID/PID/DID values (0xC0) upon power-up. The VID/PID/DID option was new to me, haven't seen it before.
I don't know, honestly. I wrote my post based on the experience I have from Texas Instrument's devices and others. Many developers use this technique, and I'm sure Cypress does as well. If not in their public development kit, then at least in their internal one. Developing a complete firmware from scratch without any type of quick debugging method is rather cumbersome.
I'd suggest contacting Cypress Tech Support about obtaining such a driver. If they say no such driver is available, then it's pretty much though luck. The development kit does provide all necessary documentation for writing such a driver, though. Writing one and putting it for public distribution would be a blessing for many FX users, I'm sure.
I was curious if there was already an existing dll model available to do that as I saw no mention in the development docs I have. ( working with the FX2). I built that functionality into my app.
I've converted my app over to use cyAPI.sys (and therefore CyUSB.sys) and everything is working good. My inf has two sections, the first part loads my firmware (compiled into a sys file) and the second part calls the CyUSB.sys file. My standby mode is now working, Yippee! Thanks for the discussion. M
Open the INF file itself, and browse through it. You should find an entry there that says the actual filename of the firmware. Just search for *.sys inside the file. Then rename your compiled firmware file to this name, and move it to C:\Windows\Win32 (or wherever your Win32 directory is). It should now load itself into the device when it's connected to the USB bus.
It might also be that the CyUSB.sys is the 'firmware loader driver'. I would have to check the INF and SYS files myself to be sure of this, and see what they do.
check out the Cypress App note AN041 "EZ loader custom USB Firmware Loader Driver" Basically, you
1) compile to hex
2) use hex2bin to create a text file
3) cut and paste into the firmware.c file that is part of the system files that you will compile
4) use the Windows DDK to compile to a system file
5) Define the inf to load the system file
You do need the Windows DDK but if you don't have it, don't buy it. You can actually download it as part of another (free) Windows package. I can't recall off the top of my head but I could search for it if you need to know. M
Apparently there is a way that you can load CyUSB.sys and then define a script (that is called from within the inf) that loads your firmware. I haven't tried it but it is mentioned in the CyUSB.chm help files. M
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.