USB low-full-high speed peripherals Forum Discussions
text.format{('custom.tabs.no.results')}
I am using CY8CKIT-050 PSoC 5LP development kit, connected to a Windows 8 PC through Full Speed USB 2.0. Can somebody help me in understanding how the 'XferData(buf, bufLen, pktInfos)' API call works for Isochronous IN endpoints?
1. Cypress CyAPI Programmer's Reference manual (2011) mentions on page 8 that the XferData() call is overloaded to take an additional argument 'pktMode'. If pktMode is true, then the partial data transfer is enabled at an IN end point. However, when I used this call for an ISOC IN Endpoint with pktMode = true, then the compiler gives an error saying 'Too many arguments in function call'. Does this parameter valid for ISOC IN EPs? If yes, then how to use 'pktMode' argument in XferData() call for ISOC IN EP?
2. I have configured an ISOC IN EP with maximum packet size of 1023 bytes and DMA transfer with Automatic Memory Management. I have set the end point transfer size for this EP as 8184 bytes (8 times 1023) using SetXferSize() call. Now, while using 'XferData(buf, bufLen, pktInfos)' API call with this EP in host application:
(i) Should the buffer ('buf') size, and 'bufLen' value be always 8184 bytes (8 times 1023)? Or, should the 'bufLen' value must be equal to maximum packet size (1023)?
(ii) Can we use 'bufLen' value less than 8184, while keeping the buffer size still to be 8184 (For example, in cases when we want to receive less than 8184 bytes)?
(CyAPI manual says that bufLen should be 8 times the maximum packet size, but I suspect that I am receiving excess data in host application on doing so.)
Show LessMy USB component control Endpoint size in Encore 2 is only 8 Bytes . In my application I need to transfer 64 Bytes . How to do it?
The control Endpoint is a bidirectional endpoint that uses the same buffer (USB_INTERFACE_0_FEATURE_RPT_DATA) to Send and receive the data . This buffer size is only 8 bytes . So if the user is sending any data over the control endpoint there is a possiblility that data may be overwritten . Below is the solution to over come this problem in EnCore 2.
The USB component of allows the user to override the exisisting routines easily . The Feature report such as GET and SET Report Rountines can be easily over written by following the steps in the USB UM datasheet . Please refer the section "Creating vendor specific device request and overriding existing request "of the UM datatsheet
Attached is a simple project in which I have over ridden the exisisting routine for the GET and SET REPORT . I have made the buffer size uptp 64 bytes and tested the project . Also unlike the normal way where there is only one buffer for both IN and OUT in this project there are separate buffers for both GET and SET reports . The Files that has been modified are the USB_cls_hid.asm and USB.inc
Regards,
SRAM
Hi everybody!
Page 21 of AN56377 (Revision *J) mentions that PSoC supports a maximum packet size of 64 bytes using the Store-and-Forward mode and a maximum packet size of 1023 bytes using Cut-through mode. Table 18 in the same docuument (page 20-21) shows that Store-and-Forward mode is applicable to 'No DMA transfer / Manual DMA mode' and Cut-through mode is applicable only for Automatic DMA mode.
Does this mean that if we use Manual DMA mode for ISOC transfer from both Host to PSoC 5LP and from PSoC 5LP to Host, we need to configure the USBFS for Maximum packet size of 64 bytes? If we need to configure USBFS for Maximum packet size of 512 bytes, then should we only use the automatic DMA mode?
Thanks.
Show LessI am wiring up an embedded device to trasmit data via the FX3 to a PC. I'm using pretty much a stock SlaveFifoSync.img from the examples in the development kit, and the GPIF interface. I'm transmitting 16 bits per PCLK toggle.
My data comes from reading a 16-bit ADC. I end up with 2048 ADC reads per data packet, ie 4096 bytes of date per packet.
I figure I *should* be able to just put the data on the data lines, then toggle PCLK to load it, repeat that 2048 times, then terminate the transfer with a PKTEND toggle.
But I lose data. The content is obviously there, but it's not in the right place.
If I add some dummy PCLK toggles, and by some I mean 12 at the front and 88 at the back of each toggle, everything I get lines up nicely, but I end up missing some samples in there.
What I'm thinking is that even though I'm doing a 4096 byte transfer, what's actually happneing is about four 1024 transfers (size of the xmit buffer in the config I have), and that there are some expected header bytes, or possibly some delays that the extra PCLK toggles are making up for.
I have read the documentation, but I'm obviously missing something. Would greatly appreciate input.
Thank you,
-CL
Show LessPSoC 5LP ARchitecture TRM mentions about circular DMA mode in which multiple TDs are chanined together and used in a circular manner. Is there any way to use to use circular DMA mode during usb communication? The application note says that DMA is configured with the first call to USBFS ReadOutEP or LoadInEP. So how do we specify multiple buffers which can be filled up by DMA in circular manner? Application note AN56377 gives an example of Auto DMA transfer with only a single buffer. Is there any example of using multiple DMA buffers in circular manner for USB communication?
Regards,
Manuj
Show LessHi,
I'd like to use the slave FIFO to push some data from a device to my host. I configured my FX2 chip to use EP6 as IN endpoint. However if I try to read some data on my host, the data is completely mixed up (missing or occurs multiple times, however there is no random data i.e. all data was generated by my device).
My configuration:
REVCTL = 0x03; SYNCDELAY; PORTACFG = 0x00; SYNCDELAY; IOA = 0x00; OEA = 0b10000000; // Enable A7 output SYNCDELAY; CPUCS = 0x12; // 48MHz CPU clock, CLKOUT enable SYNCDELAY; // I/O mode + clock IFCONFIG = 0x03; // external clock, synchronous (slave FIFO) SYNCDELAY; EP2CFG = 0b10100000 // EP2: Valid, Out, Bulk, 512B, Double SYNCDELAY; EP4CFG = 0x00; // off SYNCDELAY; EP6CFG = (2 << 0) | (2 << 4) | (1 << 6) | (1 << 7); // EP6: Double, Bulk, In, Valid SYNCDELAY; EP8CFG = 0x00; // off SYNCDELAY; // do a fifo reset FIFORESET = 0x80; SYNCDELAY; FIFORESET = 0x02; SYNCDELAY; FIFORESET = 0x04; SYNCDELAY; FIFORESET = 0x06; SYNCDELAY; FIFORESET = 0x08; SYNCDELAY; FIFORESET = 0x00; SYNCDELAY; EP2FIFOCFG = (1 << 0); // EP2: 16-bit SYNCDELAY; EP4FIFOCFG = 0x00; // set 8bit to enable PORT D SYNCDELAY; EP6FIFOCFG = (1 << 0) | (1 << 2) | (1 << 3); // EP6: 16-bit, ZEROLENIN, Auto Commit In SYNCDELAY; EP8FIFOCFG = 0x00; // set 8bit to enable PORT D SYNCDELAY; // 'prime the pump' see REVCTL, OUTPKTEND OUTPKTEND = 0x82; SYNCDELAY; OUTPKTEND = 0x82; SYNCDELAY; PINFLAGSAB = 0x64; // flag B: EP6PF, flag A: EP2PF SYNCDELAY; PINFLAGSCD = 0x08; // flag C: EP2EF SYNCDELAY; EP2FIFOPFH = 0x80; // DECIS=1, PKTSTAT=0, PKTS=0, PFC=0 SYNCDELAY; EP2FIFOPFL = 0x04; // PFC += 4 SYNCDELAY; // EP6: flag high if >= 1p + (512-32)B in fifo // 512 - 32 = 480 = 0x01E0 = 256 + 224 EP6FIFOPFH = 0b10001001; // DECIS=1, PKTSTAT=0, PKTS=1, PFC=256 SYNCDELAY; EP6FIFOPFL = 0xe0; // PFC += 224 SYNCDELAY; // PA7 / FLAGD as port A 7, not fifo flag + chip select PORTACFG = 0x00; SYNCDELAY; // all fifo control pins lowactive FIFOPINPOLAR = 0x00; SYNCDELAY; // AUTOIN len limit EP6AUTOINLENH = 0x02; // 512 SYNCDELAY; EP6AUTOINLENL = 0x00; // + 0 SYNCDELAY; // PORT D as inputs: OED = 0x00; SYNCDELAY;
Pseudo-code on my device:
- Wait until FlagB = 0
- Send a 16-bit word
- Repeat
Is there any configuration issue? Or do I have to check my FIFO interface timing?
Thank you for your support!
Kind regards,
Peter
Show LessHi,ALL
The project needs to use the CY7C63813 endpoint 0 as the data sending and receiving, the realization of the host computer through the endpoint 0 issued an order, 63813 by endpoint 0 response data,
Hi,
I am using FX3 chip on my design board, when i use USB3.0 cable with lower frequencies(< 20M clock) not able to get data in control center. With USB2.0 cable the same Firmware & FPGA code are working.
Regards,
Venkatesh.
Show LessHello,
I'm using a fx2lp to acquire a stream of data coming from an image sensor. The transfer is bulk type.
This device has always performed well on several old pc with USB2.0 controllers but now some customers are buying brand new pc with USB3.0 port and the things are getting bad...
On the same pc the device works on USB2.0 ports but doesn't on USB3.0 ports. Apparently the problem is a limited throughput (!) that lead to an overflow on fx2lp fifo.
We notice this behaviour on Intel and Renesas controller but we haven't tried other... we believe that are all the same.
Any idea?
Thanks a lot for your support.
Dax