I'm trying to implement a timer on FX3 to measure the length of time for which an input pin (button) stays low. I want to configure the GPIO pin of the button as a Complex Gpio.
I tought that the best option for me would be to configure the pin mode as:
gpioComplexConfig.pinMode = CY_U3P_GPIO_MODE_MEASURE_LOW;
However, this way I am not able to understand where could I see the time measured, as "CyU3PGpioComplexSampleNow" can be used ONLY with CY_U3P_GPIO_MODE_STATIC.
Does anyone have any suggestion? ThanksShow Less
The Cypress Semiconductor CYUSB3ACC-007 CPLD Accessory Board is designed to work with the General Programmable Interface (GPIF™ II) of the EZ-USB FX3 SuperSpeed Explorer Kit. It is meant to be used for with the USB 3.0 application examples in the book "SuperSpeed Device Design By Example", by John Hyde.
Now this accessory board contains a Xilinx CPLD. This is some very old and tiny device containing just 128 Macrocells.
I have never used Xilinx devices. I use Intel FPGAs and Microsemi FPGAs. I want to connect Intel FPGA to the EZ-USB FX3 SuperSpeed Explorer Kit. What can I do to achieve this task now? Or must I find whatever method exists to work the accessory board containing the tiny Xilinx FPGA?
Why have Cypress not provided a newer accessory board with a newer larger FPGA?Show Less
The latest Cypress USBSuite Release notes that I can find is on the Cypress website and it is the "Cypress USBSuite Release Notes, Doc. No: 002-23611 Rev. *".
Here are the things that I want to clarify:
USB3.0 Bulk streaming is not supported.
CyUSB libraries do not support more than one device configuration.
Following features are not supported in Control Center application.
The USB Mass Storage and HID class devices no longer supported.
The Insert 100 ms wait and Script parameter functionality is not supported.
The Load monitor and select monitor functionality is not supported.
My questions are:
1. Why has nothing been updated for so many years? Is FX3 not important to Cypress anymore?
2. Why do these limitations exist in the first place? e.g I thought Bulk streaming was a shiny new feature in the USB 3.0 but it is not supported. How come?Show Less
My investigation so far into windows drivers is that, it is a highly arcane field with little information available on the internet. Writing drivers was a punishing concept when Windows Driver Model (WDM) was used to write them. The Windows Driver Foundation (WDF) is supposed to have simplified this process. However, it is still a considerably difficult task to become good at.
The FX3 can be used to create superspeed USB peripherals. A USB peripheral is useless if it can't work with a host. Cypress have created CyAPI.lib for use with C++ applications. I have a few questions about this specifically.
1. How exactly does CyAPI.lib insulate a user from knowing how USB drivers are written and in doing so how does it save a person from a necessity to learn WDF?
2. Is CyAPI.lib also compatible with Linux? If not, what options exist to make an FX3 peripheral work in Linux?
3. What are limitations of CyAPI.lib which will require that a person write their own custom drivers using WDF?
4. Are CyUSB.dll used with .NET applications, and the CyAPI.lib fundamentally the same or were written differently from scratch while providing identical API?
5. Why can't CyAPI.lib take place of WDF drivers for all USB peripherals?Show Less
This is my first post in the forum, so please bear with me. I am working on a project which uses a CYUSB3065 CX3 chip to get images from a MIPI interface to USB Superspeed, and am having problems getting it working reliably. It will sometimes work intermittently, and when it does, the results are fine, but frequently it will just refuse to receive MIPI data.
The first thing that puzzles me are the PCLK_test, HSYNC_test and VSYNC_test outputs from the chip. Where is the documentation that describes how they are generated? When MIPI data is being received, I get sensible signals on HSYNC_test and VSYNC_test pins. When the MIPI data is not being received successfully, I get nothing on those pins.
However, PCLK_test is more confusing. What governs the frequency I should be seeing on there? According to the configuration tool in EZ-USB the pixel clock should be 96MHz (which is correct for my camera). However, I actually measure 76.8MHz on PCLK_test.
This is suspicious because I'm using an external REFCLK of 24MHz rather than the internal 19.2MHz one. However, if the chip had somehow decided to use its 19.2MHz reference clock, the pixel clock would be wrong in exactly that way. I've checked and my 24MHz clock is present and working.
Is there something I've missed? What determines the frequency of PCLK_test?
I've connected the FX3 ExplorerKit to an Altera Cyclone V Dev Board (using HMSC breakout). The FX3 is programmed as "sync slave fifo" (2bit address). We're using it in 32bit data mode, and we only perform (write) transfers from FPGA to FX3. Currently the FPGA is running some test code to continuously send data to the FX3 (burst writing). On the host side we're using the ControlCenter app to read + display the data send from the FPGA. We're using the "standard" version of the sync slave fifo where flag-a = "current dma thread ready" and flag-b = "current dma thread watermark". The problem is that with our current implementation after a (short) while both flag-a and flag-b go from '1' to '0'. Even after reading all data on the host (using ControlCenter), the flags don't reset to '1'. For now we can only make this work (sort of) by ignoring both flags and simply sending data every clock cycle but this obviously not suitable for our final design.
This is basically what our FPGA does:
- Set address to "00", slcs# = '0', sloe# = '1', slrd# = '1' (these values are fixed and never changed)
- In a (simple) statemachine we do:
1) Check flag-a and wait until it is '1';
2) Check flag-b and wait until it is '1';
3) Setup data on dq[31:0] + assert slwr# (='1')
4) Continue doing 3) until flag-b (partial full) becomes '0' after which we make slwr# = '0'
5) Finally we wait until flag-b becomes '1' again and return to 1) and start all over
What are we doing wrong here? We closely inspected the documentation that comes with the "sync slave fifo" but we have the feeling we're missing something crucial, specifically concerning the use of the (partial) flag.
Any help would be much appreciated.
I have a question about config SPI
io_cfg.useSpi = CyFalse; <- use this setting , the CX3 can work well
io_cfg.useSpi = CyTrue; <- use this setting , the CX3 can not work, the E-CAM can not recognized CX3
it seems the PC host not get the CX3 descriptor.
My setting as below:
#define DUMMY_COMPLEX_GPIO 56
/* Configure the IO matrix for the device.*/
io_cfg.isDQ32Bit = CyFalse;
io_cfg.useUart = CyTrue;
io_cfg.useI2C = CyTrue;
io_cfg.useI2S = CyFalse;
io_cfg.useSpi = CyFalse;
io_cfg.lppMode = CY_U3P_IO_MATRIX_LPP_DEFAULT;
/* No GPIOs are enabled. */
io_cfg.gpioSimpleEn = 0;
io_cfg.gpioSimpleEn = 0;
io_cfg.gpioComplexEn = 0x0;
io_cfg.gpioComplexEn = 0x1<<(DUMMY_COMPLEX_GPIO-32);
status = CyU3PDeviceConfigureIOMatrix (&io_cfg);
We have a firmware based on AN75779 (UVC Bulk streaming). There are some adjustments to the actual image sensor.
What we notice is, that sometimes (not consistent) with the same binary firmware image, it works very well and sometimes we just get no GPIF payload at all, but just one 12 Byte UVC Header packet per frame.
Investigations have shown, that the GPIF waveform is working perfectly fine (confirmed by toggling CTL outputs and watching them with a logic analyzer). There is a clear ping ponging done between the 2 GPIF threads 0 and 1 and IN_DATA called the expected the expected amount of times.
When logging the 2 GPIF producer Sockets and 1 USB consumer socket register values over time from a second thread, we do see, that when in an operational state:
- The SCK_COUNT data is incrementing for PIB Socket 0 and PIB Socket 1 + UIB as expected
- The STATE of the socket is always active
When we are in a non operational state we see:
- SCK_COUNT of the 2 PIB sockets is constantly ZERO
- The PIB state is sometimes STALL and sometimes ACTIVE
- The UIB is incrementing only once per frame with the expected 12 Bytes of the UVC header (Triggered by Interrupt from GPIF PARTIAL State, calling wrapup, calling indirectly the producer callback
We checked in exactly this situation the GPIF state machine by generating pulses in the 2 data transfer states and they are coming as expected.
The Sensor is clocking the PCLK with 75 MHz.
Could this be an issue of the THREAD controller, that resides between GPIF and DMA socket?
ANY help is appreciated in hints how to debug further.
We checked for return error codes everywhere possible, e.g. the multi DMA setup, but don't get API errors in the non working situation.
The sourcecode can be shared with Cypress, but I don't want to put it in this public forum.
- APPThread_logfunction.c - The function that creates debug prints. Called every 100ms from within APPThread
The log prints 3 Socket register and THREAD controller configuration
- Logfile_good_state.txt - A Logfile when "everything works fine" All 3 SCK_COUNT registers are incrementing
- Logfile_nonWorking_state.txt - A logfile from the state where the 2 GPIF socket2 don't receive data, allthough IN_DATA state is confirmed to be called in GPIF statemachine
I am considering the CYUSB302x, CYUSB303x, CYUSB202x, for my project, but I would like to know the serial write performance when these devices are in MMC-DDR52 mode. So it is a High Speed mode , with Dual Data Rate in 52MHz. I would like to use 1 pin to transfert my data so the transfert will be serial.
Could you tell me what is this serial write performance ?