USB superspeed peripherals Forum Discussions
This is a call out for help regarding an (easily reproducible) full speed problem that I am experiencing with the EZ-USB FX3 Superspeed Explorer Kits, using a USB2 cable.
Our project requires full speed. We found no existing full speed Isochronous example, so we modified the source of Isochronous example Cypress\EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxisolpmaninout to force it to be full speed (rather than high speed) when used with a USB2 cable. We also changed the producer and consumer endpoint descriptor Max packet size values from decimal 1024 to decimal 64.
I have attached the two source files (cyfxisolpmaninout.c and cyfxisolpdscr.c - renamed to *.txt to facilitate the upload) of SDK example cyfxisolpmaninout that we modified. (I have also summarised these file changes at the end of this post.)
I programmed the FX3 I3C EEPROM with this modified (to force full speed) Isochronous example (USBIsochLoopManualInOut.img).
Running a program that tests CCyUSBDevice object member nHighSpeed and bSuperSpeed reveal that neither is true, therefore it would appear that full speed has been achieved.
Running USB Control Center confirms that the Isoc in and out endpoints have ENDPOINT MaxPktSize values of “64”.
When I select the “Isoc out endpoint” descriptor, and navigate to the “Data Transfers” tab, the “Bytes to transfer” value has defaulted to 512 (which is 8*MaxPktSize). I change this to 64, which is the MaxPktSize. When I singularly press the “Transfer Data-OUT” button it successfully transfers out the 64 bytes – “ISOC OUT transfer completed”. All is well so far.
However, if I press the the “Transfer Data-OUT” button rapidly twice in succession (faster than approximately 0.2 seconds apart), the first write succeeds, but the second write always fails with “Zero-length data transfer completed”.
My questions are - why is this error occurring for full speed, and why can’t I perform two writes quickly with full speed? Is there anything wrong with the methods in which we went about forcing full speed?
P.S. The unmodified Isochronous example Cypress\EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxisolpmaninout, which runs at high speed using a USB2 cable, does not exhibit this problem.
P.P.S Details of this modification to force SDK example cyfxisolpmaninout to full speed were as follows:
Source file cyfxisolpmaninout.c had ‘Super speed configuration descriptor’ commented out, and was change to call CyU3PUsbForeceFullSpeed(CyTrue) and CyU3PConnectState(CyTrue, CyFalse).
Source file cyfxisolpdscr.c had ‘Standard device descriptor for USB 3.0’ ‘Standard super speed configuration descriptor’ and ‘SuperSpeed device capability’ commented out, and the length of the ‘Binary device object store descriptor’, ‘Endpoint descriptor for producer EP’ and ‘Endpoint descriptor for consumer EP’ were updated to be consistent with these changes.
In addition, the Max packet sizes of the Isoc in and out endpoints had been changed from decimal 1024 to decimal 64 in file cyfxisolpdscr.c.
Show LessHi,
I tried running the UAC example along with Cypress CX3 SDK (1.3).
I flashed a wav file (50Hz Sine wave) generated for 48kHz sampling, 16 bit stereo to CX3 SPI Flash using control center. Then I ran the CX3 UAC example (which streams audio from SPI flash onboard). I used Audacity to record the streaming audio in PC. The recorded wave was different from the audio file which I flashed on to the SPI flash. It was noisy and had no relation.
Am I doing it wrong? Or is there any other way to validate the audio streaming ?
Show LessHi all
we encounter bulk transfer problems with the FX3 when the DMA buffer.
Background:
We are working with the FX3 controller in master mode and are trying transfer data from the PC to FPGA in bulk transfers(8MB) using DMA.When the ready_to_transfer signal from FPGA is high the GPIF state machine DR_DATA from USB socket to the PIB socket.The DMA transfer Mode is CY_U3P_DMA_MODE_BYTE the transfer type is CY_U3P_DMA_TYPE_AUTO and the buffer is two 45kBytes.The burst length of pipeout endpoint is 15.The software works with the winusb dll and repeated WinUsb_WritePipe() on one bulk-out SS endpoint. The timeout time of Pipeout is setting to 5s.The Host Controller is Inter and ASMedia.
Problem:
When the ready_to_transfer signal from FPGA is setting to '1' the GPIF state machine works properly and the data to the fpga is correct.But when the ready_to_transfer signal is connecting to the FPGA FIFO's valid port (which may be low when FIFO is full) the transfer is timeout everytime on Inter Host Controller PC and the ASMedia PC is fine.
The transfer timeout is caused by DMA_RDY_TH2 is not available anymore when transfered 45kBytes integer times data already.
Reduce the PIB clock frequency will also cause this problem when the ready_to_transfer signal is setting to '1'.
Thougts & Questions:
It feels the speed of consuming DMA buffer reduced cause this problem.
Is there anyother setting when using winusb api to write the pipe?
Thank you in advance,
Ran Liang
Show LessI need the CYUSB3KIT-003 with the external SRAM onboard. I know, just 1 KB access-able (I had to design own PCB or use extension header,
512 KB is needed).
My questions are related to:
- how can I use the external SRAM as buffer (SW FIFO) between ARM9 and USB?
The ARM9 should be able to write data (e.g. from SPI) to external SRAM, via USB I want to read this SRAM (SRAM example works,
a good starting point, please see following questions).
a) Is my understanding correct? Using external SRAM needs GPIF interface. Even for the ARM, it must be used, configured.
Without a GPIF design - ARM9 would not be able to access external SRAM?
b) What is the address mapping? How could ARM9 access external SRAM (hoping it is just a memory region/window to see external SRAM
if GPIF is initialized)?
c) Is there an arbitration? How does it work if ARM9 tries to write, but USB wants to read?
As I understand the SRAM_FX3 example (it is actually called "cyfxsrammaster") - GPIF must be initialized via USB. And: in order to read
(after a write) - a special USB transaction on Endpoint 0 must be done, otherwise the Read/Write Endpoints are not available.
But, does it result in a "race condition"? ARM9 wants to write, but USB wants to read - the sequence to change from write to read via USB
could conflict with ARM9, concurrent access?
d) Can ARM9 initialize GPIF, so that it is not needed to use this special sequence to do via USB?
How can I use external SRAM (later on own board) as a buffer (like Dual Port) between ARM9 and USB?
What to bear in mind?
What to consider for FW design (memory map for ARM9, mutual access to handle race conditions, HW arbitration, e.g. ARM could put to wait
when USB access at the same time)?
Thank you for any guidance.
Torsten
Show LessHi all,
I have a CX3 project wich runs in windows10.
Now I need to work with EZ USB Suite in Ubuntu.
I have follow steps to install it, I've correct some bugs that I found in this forum and I have any problem in Problems folder
But now when I try to build the project I can not, and Console folder gives me this error:
"Cannot run program "arm-none-eabi-gcc" (in directory "/media/ .. /Debug"): error=2, No existe el archivo o el directorio"
I think that I add all the paths, do you know wich mor I need?
Thanks
Show LessHi everyone!
Trying to imitate the performance of the Open Control Center tool provided by Cypress EZ USB Suite, opening firmware image for RAM upload ans writing image has been successful by using libusb.
Here is the repository used:
libusb-1.0.20 > https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.20/libusb-1.0.20.7z/download
RAM
So basically, what I've done is running fxload.exe on Command Prompt app (Windows 10) executing the following command line:
> fxload project.img -d 04b4:00f3
Where project.img is the result of my application and 04b4:00f3 is the Vendor ID and the Product ID respectively.
As a result, the next message is showed:
> found device 'Cypress FX3' [04b4:00f3] (1,22)
> microcontroller type: fx3
> project.img: type Cypress IMG format
> open firmware image project.img for RAM upload
> normal FW binary executable image with checksum
> FX3 bootloader version: 0x000000A9
> writing image...
> transfer execution to Program Entry at 0x4000b71c
The result is exactly the same when you click on "Program" tab > "RAM" in Open Control Center tool, so I'm happy with that.
EEPROM
Now I want to load a image file to EEPROM, imitating the performance of the Open Control Center tool one more time but I couldn't find a solution to this.
Looking through libusb-1.0.20, I've assumed that EEPROM needs a Second Stage Loader to load the firmware properly:
"If you want a loader for development use, which can write to the I2C boot EEPROM using the 0xA2 request, see the "Vend_Ax" code provided with the developer kit for your microcontroller."
"Vend_Ax" code, provided by Cypress, is located in "<Installation_Path>\Cypress\EZ-USB" but only for FX and FX2 versions.
In EZ-USB FX3 SDK this file doesn't exist, so it's impossible for me to execute the following command line:
> fxload -i project.img -d 04b4:00f3 -s vendor_ax.hex
I've assumed two things:
- EEPROM needs a Second Stage Loader compulsorily, but I'm not sure about that.
In that case, where can I get a "Vendor_Ax.hex" file for FX3?
- fxload.exe has to provided me the specific functionalities to load a firmware to EEPROM, , but I'm not sure about that either.
Even if it were not, what is the properly way to load a firmware to EEPROM?
In libusb, "ezusb.c" file provides "fx3_load_ram" implementation but "fx3_load_eeprom" isn't, although this function is declared in "ezusb.h" including practically the same parameters that "fx3_load_ram". Where this function implementation is?
Could someone help me to load a firmware to EEPROM?
Regards,
Fran Martin
Show LessI am going through the examples from the "SuperSpeed Device Design by Example" and exercising the CDC_BulkLoop. It is mentioned in the "USB_Descriptors.c" file that: "this custom VID_PID needs an INF file for driver matching. Use "NEWcyusb3.inf""
When loading the application on ARM via JTAG, I get first 2 unknown devices enumerated; doing the "update driver" operation on the first, using the above .INF, I get the virtual COM23 port created, which is usable as Debug console via the Terminal.
However, when pointing the .INF to the 2nd unknown device, that is supposed to be a BulkLoop endpoint pair, I get a strange error: "Driver is not intended for this platform" !! (see attach). As such, the BulkLoop Endpoint is not enumerated and the Cypress' USB Bulkloop program is not seeing a device. To mention, I try this on a laptop with USB 3.0 ports running Win7 64bit O.S.
What is wrong here and what would be a solution ?
Thank you.
Show Less