USB superspeed peripherals Forum Discussions
When the CYUSB3Kit-003 is plugged in with J4 installed, nothing appears in control center.
The kit does appear with the default demo streamer example when J4 is removed.
Control center is version 1.2.3
The PC is running Win7 home premium SP1. Are there known issues with this version?
Any assistance is greatly appreciated.
Show LessI intend to interface a camera with 16-bit grayscale video over USB UVC using the FX3. As per AN75779, the chip supports YUY2 where grayscale is only 8-bit. Can i use the FX3 to transfer 16-bit grayscale over UVC?
Show LessHello
Here is my understanding of which errata corresponds to the three "2.2 Unexpected Connection Failures" items of TroubleShooting Guide.
Please tell me if it is correct or not.
>o The USB driver in the FX3 SDK monitors the number of USB link errors that are
>detected by the hardware; and causes a re enumeration when the number of errors
>crosses a threshold value (about 64 errors) within a 1 second p eriod. This code is
>not expected to come into play on a functional link, because there will be not more
>than one or two errors per second happening. If the device is re enumerating, it is
>likely that there is a bad USB link due to bad interconnect cables o r traces.
>
➡ Not equivalent to any errata.
>o Another reason for USB 3.0 connection errors is link errors that happen around link
>power state transitions. The best option to avoid such problems is to prevent USB
>3.0 link state transitions, by having the FX3 device systematically reject any l ow
>power requests.
>o It is recommended to disable the low power mode transitions by calling
>CyU3PUsbLPMDisable() API when the data transfers are active because there may
>be cases where the host performs very fast U1 Entry/Exit (Entry to Exit duration < 5
>µs) and the firmware is not capable of responding to such fast low power mode
>transitions.
>The FX3 device can be placed in this mode by making use of the
>CyU3PUsbLPMDisable() API. Please note that using this API can also help
>improve the USB data transfer per formance because of increased link efficiency.
>
➡ The above two items correspond to errata No. 7.
Best Regards
Arai
Show LessHello
If the assignment of address A1, A0 is 32bit or 16bit so far, it will be configured as follows.
GPIO [28] / CTL [11] / A1
GPIO [29] / CTL [12] / A0
Q)
This time, the GPIF of FX3 will be configured with an 8-bit bus.
In that case, the pins are assigned as shown below.
Do I need to do anything manually to assign it to the same location as 16bit / 32bit?
GPIO [10] / DQ [8]
GPIO [11] / DQ [9]
Best Regards
Arai
Show LessHello,
What is the best way (Host and FX3 firmware routines) to program the FPGA via SPI interface for the FPGA configuration image (.bin) is more than 2.8MB ?
How to create the loop to alternate between DMA image data in the (64KB) page format via USB-CPU channel buffer and the FPGA programming sequence
in such away that it can download and program the FPGA successfully ? (Note that alternating between DMA function and programming function requires stopping the SPI_CLK (Low) at the end of current programming page and during the host DMA the next page).
This requires the modification of the current example of AN84868 which the host issues the vendor command 0xB2 for download the FPGA configuration file (216KB) completely into the buffer[] before issuing the 0xB1 for programming from SPI. Note that in the example the programming file size is only 216KB and CYFX3 image file size
is 110K and the total is far less than the available FX3 RAM capacity of 512KB. The modification from host for FPGA Configuration Utility as well FX3 Firmware are needed as the alternate between DMA and programming to take place interleaved.
Thanks,
Show LessHello
I get the following error while debugging a cx3 project based on EZUSB
ERROR: Bad JTAG communication: Write to IR: Expected 0x1, got 0x0 (TAP Command : 2) @ Off 0x5.
when
status = CyU3PSysEnterSuspendMode (CY_U3P_SYS_USB_BUS_ACTVTY_WAKEUP_SRC, 0, &wakeReason);
Show LessIn order to simplify and minimize the size of the board, I have to remove the pmode switch from the board now. But I still want to reserve the function of pmode switch(boot selection and firmware download selection). Can any guy provide a method to tell me how to achieve this?
Show LessHi,
I am using Cypress Fx3 DVK (CYUSB3KIT-003), In cypress errata I found about above mentioned subject.
So in firmware, In CyFxUSBEventCB function in CY_U3P_USB_EVENT_SETCONF function I am making LPM disable CyU3PUsbLPMDisable(), and I am not making enable anywhere. I sthis method of making LPM disable is correct or any other way I need to handle.
Here is the snippet of my CyFxUSBEventCB function:
void
CyFxUSBEventCB (
CyU3PUsbEventType_t evtype, /* Event type */
uint16_t evdata /* Event data */
)
{
switch (evtype)
{
case CY_U3P_USB_EVENT_CONNECT:
case CY_U3P_USB_EVENT_SETCONF:
/* Stop the application before restarting. */
if (glIsApplnActive)
{
CyFxIntrSrcSinkApplnStop ();
}
CyU3PConnectState(CyTrue, CyTrue);
CyU3PUsbLPMDisable();
CyFxIntrSrcSinkApplnStart ();
CyU3PUsbStart();
break;
case CY_U3P_USB_EVENT_RESET:
case CY_U3P_USB_EVENT_DISCONNECT:
/* Stop the loop back function. */
if (glIsApplnActive)
{
CyFxIntrSrcSinkApplnStop ();
}
break;
default:
break;
}
}
■Workaround
This problem can be worked around in the FW by disabling LPM (Link Power Management) during data transfer.
Since it is mentioned that during data transfer means where I need to disable LPM ?
Best Regards
Prasanna
Show LessThe FX3 documentation (SDK version 1.3.4) for CyU3POsTimerInit claims that the default timer tick interval is 1ms.
This does not match the implementation. The actual tick interval is around 0.976ms (250/256 ms). This means that all delays, timeouts, and so on are slightly too fast. It adds up to human-visible differences fairly quickly, I could easily verify the difference by hand with a stopwatch. You can also see this effect by comparing the values returned by CyU3PGetTime() to the values returned by CyU3PGpioComplexSampleNow() on a complex GPIO configured for a known frequency.
The underlying cause of this is that the timer interrupt handling in system/cyu3vic.c appears to assume that the watchdog clock runs at exactly 32.000kHz. But the hardware actually runs this clock at 32.768kHz per the TRM.
Workaround: scale all delays and timeouts passed to the firmware by 256/250. Scale the return value of CyU3PGetTime() by 250/256.
Any plans to fix this in the firmware library? It's possible to get the average tick interval much closer to 1ms (I prototyped a fix and with a little fixed-point math got the average error down to < 1ppm fairly easily). Failing that, the documentation needs to be updated to reflect that ticks are not 1ms.
Show Less