weird transfer blocking happened between CYUSB3014 and Android tablet

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
GlWa_4148656
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

Hi all, we try to create a BULK IN&OUT path between FPGA - CYUSB3014 and Android tablet(samsung),  the firmware used in FX3 is "slave fifo example image" which support stream in & out function.  IN data is generated  by FPGA and transferred to FX3 buffer via GPIF-II, then Android host read data from FX3 buffer via USB 3.0. OUT data is a inverted way compared to IN data path. Android usb test program is based on "libusb" which has been intergreated in android system, when android receive a 16384-byte packet from FX3, it just drop it and ready to receive another one(for usb bandwidth test).

Before the Android test, we have successfully verified our FX3 slave fifo image by Cypress offical test tools (Streamer and Control Center), make sure the FPGA logic and FX3 image are OK.

In Android BULK IN test, we found a weird phenomenon, after several successfull packet receiving, the android program always blocked at "bulkTransfer()", this system function call a BULK IN transfer from host to FX3.

I have no idea if the host does not generate a right BULK IN request or the FX3 dose not response, because the "bulkTransfer()" is a system function and we have no way to debug inside it, but one thing can be sure that the data buffer in FX3 is full and FX3 reject data transferring from FPGA via GPIF-II.

any one help me to handle this problem?

0 Likes
1 Solution

Hello,

The main difference between AUTO channel and MANUAL channel is the CPU intervention , which makes the MANUAL DMA channel slower as compared to AUTO DMA channel.

As the firmware is working with Control center and Streamer on Windows, the problem seems from the Android host application side. May be the problem is in sync between the FX3's USB endpoints and Android host.

the most strange thing is that it does not affect communication between FX3 and windows, if you have answer,pls let me know.

>> To comment on this, we would need to get the USB traces or the UART traces for both the cases. You can also verify the flow of android host application with the streamer/control center host appliction.

You can also try using the asynchronous USB transfer APIs as used in the streamer application

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
13 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

we try to create a BULK IN&OUT path between FPGA - CYUSB3014 and Android tablet(samsung),  the firmware used in FX3 is "slave fifo example image" which support stream in & out function

>> I understand the description. Please confirm if you are using the default AN65974 https://www.cypress.com/file/136056/download  firmware on CYUSB3014 

IN data is generated by FPGA and transferred to FX3 buffer via GPIF-II, then Android host read data from FX3 buffer via USB 3.0. OUT data is an inverted way compared to IN data path

>> If the data flow is from FPGA > FX3 >USB Host, the host should send the USB requests on the USB IN endpoint. USB OUT endpoint is used for transferring the data from USB Host to FX3

In Android BULK IN test, we found a weird phenomenon, after several successful packets receiving, the android program always blocked at "bulkTransfer()", this system function calls a BULK IN transfer from host to FX3.

>> Please let me know approx how many transfers were successful before the failure. Also, let me know the return value of bulkTransfer() API

one thing can be sure that the data buffer in FX3 is full and FX3 rejects data transferring from FPGA via GPIF-II.

>> Please let me know if this is confirmed from the DMA flags or using the UART debug prints

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi, thanks for reply.

we do use the slave fifo FW in FX3, and this FW initialize two BULK endpoints(EP1 IN and EP1 OUT) as figure below, the weird blocking happened in BULK IN transfer.

1.JPG

1.Please let me know approx how many transfers were successful before the failure. Also, let me know the return value of bulkTransfer() API

I said the blocking was werid ,  because the successful receiving pakcket nunmber is random at each test,  the least number is 2, and the most number is about 30000,   when we modified any unimportant android code,such as log print, sleep(x).... , successful receiving pakcket nunmber of next test would be changed(i have no idea why).

the last parameter of bulkTransfer() is timout, we normally set it 0, as the description of this function, "0" means the function keep blocking until it receive a packet of data, this caused android program blocking. when we pulled the USB plug out of tablet, the bulkTransfer() blocking suddenly released and returned -1.

of course we tried to set a vaild timeout value to it(bigger than 1), when weird phenomenon happened, it always returned -1, the FX3 was still be blocked.

2. Please let me know if this is confirmed from the DMA flags or using the UART debug prints

it`s based on DMA flags, i obtained them from FPGA debug tool(xilinx vivado), it seems that the UART port of FX3 is not available on PCB of our product, so i can not debug it by UART.

0 Likes

Hello,

Can you please let me know the flow of the code implemented on the host application? what all steps are done before starting the bulk transfer

Please share the host application code snippet where the bulktransfer API is called.

There is a similar thread Steps to write to and read from cypress device using libcyusb functions where customer is using cyusb_linux (which uses libusb APIs). Please let me know if the interface is claimed successfully before starting the bulk transfers. Also confirm if the direction of the endpoint and the length (datasize) should be equal to the exact number of bytes that is being requested from the device to transfer (in this case 16KB)  is mentioned when bulkTransfer API is called

Regards,

Rashi

Regards,
Rashi
0 Likes

we use java for developing.

1.USB connect code :

the "mReceivingThread" ,which is just under the red breakpoint, call the data receiving thread.

2.jpg

2.Data receiving thread code :

3.jpg

as code in two pictures above, transfer direction is obtained automatically from "end.getDirection()" and we set a constant macro(MAX_INT_ONCE_USB = 16384) to length parameter of "bulkTransfer()" (FPGA sends 16384 bytes each time)

0 Likes

additionally, we find the "getMaxPacketSize()" of object "usbEndpooint" always return 1024, this is different from MaxPktSize showed in Control Center tool on windows, which is 16384(the right size).

but in our actual test, in each successfull receiving, Android tablet did received the right 16384 packet from FX3, it seems that the "1024" does not affect the size of receiving, but i don`t know if it would block the subsequent BULK transfer request.

0 Likes

Hello,

From the snippet shared the second parameter of bulkTransfer is "bytes" but I don't see a buffer defined with the variable name " bytes".

Please confirm if the buffer size is enough to store 16384 bytes.

Instead of dropping the data, please try reading the data into a buffer. Also, try keeping the timeout value to 1500 ms (as done in the streamer application). Please let me know if any other (IN/OUT) transfers are done while reading the data on IN endpoint. If yes, can you please try just IN transfer on this particular endpoint for testing purposes?

Please let me know if you have a USB hardware analyzer (eg: lecroy or ellisys) so that we can check if the USB request (for USB IN transfer) is received by FX3 

but in our actual test, in each successfull receiving, Android tablet did received the right 16384 packet from FX3, it seems that the "1024" does not affect the size of receiving, but i don`t know if it would block the subsequent BULK transfer request.

>> Can you try reading 1024 bytes at a time. If the endpoint maxpktsize is read as 16384 in the control center, the same is expected to be read on the android host also

Regards,

Rashi

Regards,
Rashi
0 Likes

thank for reply, but, today i just found the reason that caused the weird transfer blocking.... guess what ?

4.JPG

as figure above,to improve the DMA speed, i modified the code to "AUTO" mode(above the red line),  in this mode, weird blocking happened and Android function "bulkTransfer()" could not get a valid retrun value no matter if we set timeout or not,  i tried to change the "AUTO" back to original "MANUAL" , then no blocking problem happen and system runs very well.

now question is, how does this macro affect the usb communication ? in my understanding, it`s just an inner DMA scheme that affect the tranferring efficiency, or it would generate some kind of factor that affect the communication rhythm between FX3 and Android tablet? 

the most strange thing is that it does not affect communication between FX3 and windows, if you have answer,pls let me know.

0 Likes

Hello,

The main difference between AUTO channel and MANUAL channel is the CPU intervention , which makes the MANUAL DMA channel slower as compared to AUTO DMA channel.

As the firmware is working with Control center and Streamer on Windows, the problem seems from the Android host application side. May be the problem is in sync between the FX3's USB endpoints and Android host.

the most strange thing is that it does not affect communication between FX3 and windows, if you have answer,pls let me know.

>> To comment on this, we would need to get the USB traces or the UART traces for both the cases. You can also verify the flow of android host application with the streamer/control center host appliction.

You can also try using the asynchronous USB transfer APIs as used in the streamer application

Regards,

Rashi

Regards,
Rashi
0 Likes

thanks for your explaining, Rashi

although i still don`t figure out the final reason about the problem because i`m new in usb application,  the "sync" you metioned may give me a way to continue.

as your words, the key problem is may in android program, the AUTO mode is faster than MANUAL mode, so it depend on some kind of "sync stability" ?   in other words,the FX3 runing rate of MAUNAL mode is slower compared to that in AUTO mode, so the unstable "sync"  problem is just avoided ?

could you pls simply explain what`s the difference between sync and async bulk transfer ?   that may make me more clear.

based on your advice, i`m going to try async transfer from android to FX3, do you know which API in android libusb (java) is used as aync bulk transfer ?

0 Likes

Hello,

as your words, the key problem is may in android program, the AUTO mode is faster than MANUAL mode, so it depend on some kind of "sync stability" ?   in other words,the FX3 runing rate of MAUNAL mode is slower compared to that in AUTO mode, so the unstable "sync"  problem is just avoided ?

>> It is difficult to comment on this as we would need to check the USB traces to know the exact reason of the problem. But from the description that you had shared, it seems that the problem is on the USB host application (Android application). The problem seems to be in sequence of calling the bulkTransfer API or handling the threads.

Please confirm if sendingDataThread is being called simultaneously with receivingDataThread . Can you only use one thread in the application for receiving the data from the FPGA through FX3?

could you pls simply explain what`s the difference between sync and async bulk transfer ?   that may make me more clear.

>> You can refer to this page for the difference and libusb APIs https://www.cs.unm.edu/~hjelmn/libusb_hotplug_api/io.html#:~:text=libusb%20offers%20both%20a%20synch...

based on your advice, i`m going to try async transfer from android to FX3, do you know which API in android libusb (java) is used as aync bulk transfer ?

>> You can first try using only one thread i.e. receivingDataThread with AUTO channel and let me know the results

in this mode, weird blocking happened and Android function "bulkTransfer()" could not get a valid retrun value no matter if we set timeout or not,  i tried to change the "AUTO" back to original "MANUAL" , then no blocking problem happen and system runs very well.

>> From your previous response, Can you confirm if only the DMA channel type was changed and no other changes were done.

Can you share the firmware files and host application code where the implementation of the RecivingDataThread and sendingDataThread is done?

Regards,

Rashi

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

hi Rashi

before i posted this problem here, we have tried that only the receiving thread runing  and the DMA mode in FX3 was AUTO, weird communication failure still happened.

i have shared the my firmware and colleague`s android main code here, thanks for checking, you`re very kindness for following my problem !

btw, in firmware, i changed DMA mode back to MANUAL, besides the usb product id was modified, i don`t think the product id would affect usb communication.

0 Likes

Hello,

Thank you for the details.

Can you try to detect the device using the vendor ID and Product Id and then claim the interface.

As I do not have much experience on the Android host application. Please help me with this information

Also, please let me know the steps you follow while testing the application. Is the host application opened prior to programming FX3 and connecting to host or is it opened after FX3 is connected to the host?

How are the IN transfers initiated? Is it through some button press ? If no, can we try to initiate the IN transfers only when triggered by user (like Transfer IN button on Control center) and send only one IN request for each button press?

As per the libusb page, the -1 error code refers to  LIBUSB_ERROR_IO enum libusb_error — LibUSB Documentation

Please confirm, if timeout is set to 1500 ms even then the bulktransfer API doesn't return after 1500ms timeout expires?

Also, confirm if with Manual DMA channel the problem is never seen

Regards,

Rashi

Regards,
Rashi
0 Likes

hi Rashi

our firmware has been programed into SPI flash of FX3 before each test, thus firmware start to work after system power on.

when jobs above done, i connect the usb cable with host tablet and turn on the test app. click "find usb" then do the transfer test.

the IN transfer data source are generated by FPGA and controlled by VIO core, VIO is a kind of virtual I/O as your "button" conception, once i press the "button", one kind of IN data are transferred to FX3.

i designed two kinds of FPGA data for testing, single packet with any 4-byte size(smaller than 16384 bytes) and continuous 16384-byte packet stream.   single packet is generate by single "button" pressing, stream are generated by pull up the dedicated "button" and cancelled by pull down the same one.

for single packet test with "AUTO mode", after several packets receiving(in other words, after several manual "pressing action"), weird block happened, the same situation happened in stream test.

as your steps above, we changed DMA mode back to "AUTO" and checked the VID and PID before claim interface,all them were right. given that no other usb device is connected with our tablet, the device with these IDs is FX3, 

we also set 1500 to timeout parameter of bulkTransfer(), when weird blocking hanppened, this API timeout and always return -1, it meant nothing received. i don`t know whether the host sent IN request and did not receive the response from FX3 or the host sent no/wrong request.

same conditions for "MANUAL mode" test, systems runs very well, no blocking happen.

this problem beset us for serval days, at least we have found a way, which set DMA mode to "MANUAL", to "solve" it, and this method have been verified by long time IN transfer test.

thanks for supporting us for these days, i will choose one of your reply as right answer.   we need to move on now, many other jobs belong to this project are waiting for us to do. so we decided to pause the problem tracking, if i restart to reaserch this problem some day, i`ll let you know problem i meet.

Best Regards

Glace Wang

0 Likes