Cypress Perform

Home > Design Support > Cypress Developer CommunityTM > Cypress Forums > USB Controllers > Asynchronous fifo GPIF test

Bookmark and Share
Cypress Developer CommunityTM
Forums | Videos | Blogs | Training | Rewards Program | Community Components



Asynchronous fifo GPIF test
Moderator:
RSKV

Post Reply
Follow this topic



Asynchronous fifo GPIF test

clh23047 posted on 29 Jun 2012 9:36 AM PST
Top Contributor
65 Forum Posts

I am trying to test the slave Asynchronous fifo GPIF. The control pins were fixed as following:  

SLOE set to 1 (3.3V)  
SLCS set to 0  (0V)
SLWR set to 0
SLRD set to 1 
PKEND set to 1
ADRESS set 00
 
The PCLK, FLAGA and FLAGB were open. The 32 data pins were also open (floating). To use the Streamer, I set the PID from F2 to F1 in the firmware. No matter I set CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT set to 0 (16bit) or 1 (32bit), the FLAGA always showed 0 after I downloaded the firmware to the RAM (checked by oscilloscope, no pulse). The FLAGB was 1. When I ran the Streamer, of course, I got only Failures, no Throughput. The similar case was also discussed (http://www.cypress.com/?app=forum&id=167&rID=54520).
 
 Any suggestions to solve the problem?
 
Thanks,
Lehua Chen

Re: Asynchronous fifo GPIF test

RSKV posted on 29 Jun 2012 08:48 PM PST
Cypress Employee
655 Forum Posts

Hi Lehua Chen,

Have you tried debugging using UART to see what exactly is firmware is doing.

Also if you have a CATC/USB analyzer at your end, it is better to check the traffic on the USB bus to get a better idea on what exactly is happening. These things may help to identify the root cause of the problem.

Regards,

sai krishna.

Re: Asynchronous fifo GPIF test

RSKV posted on 30 Jun 2012 09:11 AM PST
Cypress Employee
655 Forum Posts

Meanwhile, I would recommend you to create a tech support case (MyAccount --> MyCases) regarding this.

One of our engineer will replicate this scenario and help you to come out of this issue.

Regards,

sai krishna.

Re: Asynchronous fifo GPIF test

clh23047 posted on 01 Jul 2012 03:37 AM PST
Top Contributor
65 Forum Posts

Hi, sai krishna, Thank you for your reply.

I still did not find the solution. I create a 'Mycase' today. Meanwhile, I am debugging it with UART.

Thanks again,

Lehua Chen



 

Re: Asynchronous fifo GPIF test

clh23047 posted on 01 Jul 2012 07:34 AM PST
Top Contributor
65 Forum Posts

I debugged the Asynchronous FIFO GPIF with UART. The hardware setting was as before.

When I downloaded the firmware to the RAM, “Data tracker: buffers received: 0, buffers sent: 0” was showed in the Hyper Terminal.
 
In the USB Control Center, when I chose the Bulk out endpoint (0x01) and transferred Data-OUT (1024 Bytes or 10Bytes), “BULK OUT transfer completed” appeared. In the Hyper Terminal, “Data tracker: buffers received: 1, buffers sent: 0” was got. With UART debugger, I found that the CyFxSlFifoUtoPDmaCallback( ) was called for one time. Then I clicked “Transfer Data-OUT” again in the USB Control Center, I got “Data tracker: buffers received: 2, buffers sent: 0” and the CyFxSlFifoUtoPDmaCallback( ) was called again. After that, I clicked “Transfer Data-OUT” for the third time or more, “BULK OUT transfer failed with Error Code:997” was in the USB Control Center.  The CyFxSlFifoUtoPDmaCallback( ) would be not called any more and the Hyper Terminal always showed got “Data tracker: buffers received: 2, buffers sent: 0”.
 
When I chose the Bulk in endpoint (0x81) and transferred Data-IN (1024 Bytes or 10Bytes), I only got “BULK IN transfer failed with Error Code:997” in the USB Control Center. No change happened in the Hyper Terminal (repeating “Data tracker: buffers received: X, buffers sent: 0”) and the CyFxSlFifoPtoUDmaCallback( ) was never called.
 
Look forward to explanation and solution.
Thanks,
Lehua Chen



 

Re: Asynchronous fifo GPIF test

RSKV posted on 01 Jul 2012 09:42 AM PST
Cypress Employee
655 Forum Posts

  Hi Lehua Chen,

Below are my answers to your questions.

If you look at the SlaveFifoAsync example source code, DMA buffer for USB to FX3 is configured for 2*1024 Bytes in case of super speed. That is the reason why you are able to do two BULK OUT transfers. If you change the 

dmaCfg.count = CY_FX_SLFIFO_DMA_BUF_COUNT; to 

dmaCfg.count = 16;

then you can do 16 BULK OUT transfers.

On the other hand if you look at the USBBulkSourceSink example, we are discarding the buffer as soon as we get some data from USB. CyU3PDmaChannelDiscardBuffer is called when there is CY_U3P_DMA_CB_PROD_EVENT. In this case you continuously send the data. But in SlaveFifoAsync example we are not doing this. So number of BULK OUT transfers are limited to dmaCfg.count.

Coming to your next question, regarding BULK IN, again we can correlate both these examples - SlaveFifoAsync  and USBBulkSourceSink. In case of SlaveFifoAsync  example we are committing the data only when there is a CY_U3P_DMA_CB_PROD_EVENT. That is when GPIF fills the DMA buffer.

Regards,

sai krishna. 

Re: Asynchronous fifo GPIF test

clh23047 posted on 02 Jul 2012 03:06 AM PST
Top Contributor
65 Forum Posts

Hi, sai krishna,

Thank you for your reply.
 
In my case, I have a large amount of data to be transferred continuously. I need to overcome the limit of dmaCfg.count. According to your explanation, I changed CY_FX_SLFIFO_DMA_BUF_COUNT to 16. In the USB Control Center, I can extend the Data-OUT to 16 times. But in Streamer, I mostly got Failures (sometimes with 1 or 2 Successes). In the USBBulkSourceSink, the Preload is used to fill the buffer with constant value (CY_FX_BULKSRCSINK_PATTERN). It is quite similar to getting data from P-port. So I inserted the “status = CyU3PDmaChannelDiscardBuffer (chHandle)” into CyFxSlFifoPtoUDmaCallback ().In the USB Control Center, I can send data as many times as I want. But in Streamer, I mostly got Failures (sometimes with 1 or 2 Successes). How could I send data in SlaveFifoAsync continuously?
 
For the BULK IN, you said the data would be committed only when there was CY_U3P_DMA_CB_PROD_EVENT filled from GPIF. I think this is the reason why CyFxSlFifoUtoPDmaCallback( ) was not called in my case.  In the source code declaration, it is said that “This event is generated when a buffer is generated by the producer socket when a transfer is queued with SetXfer”. With the hardware setting in my case, the GPIF is configured as continuous writing. So the CY_U3P_DMA_CB_PROD_EVENT should be automatically generated. Am I right? Could you point out what should I do to generate the riht CY_U3P_DMA_CB_PROD_EVENT?
 
Thank you so much.
Lehua Chen

Re: Asynchronous fifo GPIF test

RSKV posted on 02 Jul 2012 03:35 AM PST
Cypress Employee
655 Forum Posts

 Are you using the same GPIF II descriptors that comes with SlaveFifoAsync or have you done any changes.

Regards,

sai kirshna.

Re: Asynchronous fifo GPIF test

clh23047 posted on 02 Jul 2012 03:41 AM PST
Top Contributor
65 Forum Posts

Yes, I did not change the GPIF II descriptor.

Re: Asynchronous fifo GPIF test

clh23047 posted on 02 Jul 2012 09:42 AM PST
Top Contributor
65 Forum Posts

Is it possible that SLWR can not be set to constant value (0)? Is it necessary to supply pulse for the SLWR pin for writting?

Re: Asynchronous fifo GPIF test

clh23047 posted on 02 Jul 2012 10:50 AM PST
Top Contributor
65 Forum Posts

Oh. It is really necessary to supply the SLWR with pulses!!!

 
I connect the SLWR to 100Hz pulse (3.3V or 0V). The other settings are kept as before. I can receive data (FF, 1024Bytes) in the USB Control Center when I choose Transfer Data-IN (Bulk in endpoint 0x81). From the UART debugger, I check out that the CyFxSlFifoPtoUDmaCallback() is called now. And the FLAGB changes from 1 to 0 when the transfer is finished.  Then I increase the frequency to 3000Hz, the “buffers sent” in Hyper Terminal refreshed very fast and the FLAGB changes from 1 to 0 faster than before. So I think the U to P transfer is working now!
 
When I try to use the Streamer to check the throughput (PID changed from F2 to F1), I get only failures in the Streamer. Simultaneously, I monitor it with the UART debugger. The number (X and Y) of “buffers received: X, buffers sent: Y” are right. Maybe only to change the PID changed from F2 to F1 is not enough. Some other changes are necessary to use the Streamer for Slave FIFO example.
 
Any suggestions about this? It is important for me to detect the throughput.
 
Thanks,
Lehua Chen

Re: Asynchronous fifo GPIF test

RSKV posted on 02 Jul 2012 09:41 PM PST
Cypress Employee
655 Forum Posts

Actually, We don't need to change anything in the streamer application.

Streamer can be used with any application that can continuously stream data.

Are you sure that you are getting data continuously into PIB (GPIF) sockets. Are you able to read data continuously using Control Center.

Regards,

sai krishna.

Re: Asynchronous fifo GPIF test

clh23047 posted on 03 Jul 2012 12:14 AM PST
Top Contributor
65 Forum Posts

Hello, sai krishna,

My software is SDK 1.0. Without changing PID from F2 to F1 (recommended by you), the Streamer is not active after I download the firmware to the RAM. Now the Streamer is linked and I can choose the endpoints in the Streamer. The problem is that I always get Failures Number.
 
What is the meaning that the data is continuously transferred? In the Control Center, when I chose Bulk in endpoint (0x81), I can receive as many data as I want by clicking Transfer Data-In. In the Hyper Terminal, the “buffers sent” also increments correctly. On the other hand, when I use the Streamer instead to transfer data (Bulk in endpoint 0x81), after clicking Start, the “buffers sent” in the Hyper Terminal also correctly fast increments (but only Failures number in Streamer). Does it mean that the data is continuously transferred into PIB (GPIF) sockets and then to PC?

Thanks,

Lehua Chen

Re: Asynchronous fifo GPIF test

RSKV posted on 04 Jul 2012 02:33 AM PST
Cypress Employee
655 Forum Posts

http://www.cypress.com/?app=forum&id=167&rID=65061



ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.