FX3 partial data missing / XferData timeout

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

cross mob
LP1
Level 2
Level 2
5 likes given 10 replies posted 10 sign-ins

Hello,

I'm now debugging a system with a FX3 which is operating in slave FIFO mode and
transferring data from FX3 to PC.
The system is almost working  correctly but sometimes misses data partially.
It seems that sometimes  timeout is occurred with XferData() method.

-------
The size of data missing was multiple of 1024 (max packet size) ,
so some problem with USB communication was suspected.

I checked USB communication with Wireshark and got logs like the table below.

line time src dest pkt size  
46121 68.06554 1.22.1 host 16411 URB_BULK in
46122 68.06583 host 1.22.1 27 URB_BULK in
46130 68.26795 host 1.22.1 27 URB_FUNCTION_ABORT_PIPE
46131 68.26808 1.22.1 host 4123 URB_BULK in
46132 68.26812 1.22.1 host 27 URB_FUNCTION_ABORT_PIPE
46133 68.26826 host 1.22.1 27 URB_BULK in
46134 68.26833 1.22.1 host 16411 URB_BULK in

 

At this time, 16KB data transfer was done correctly several times.
But,  for the BULK IN request of the host at line 46122, response of FX3 was delayed 500ms
(this is the same value with CyUSBEndPoint.TimeOut)
It seems that USB host requested ABORT_PIPE at the line 46132,
and FX3 responded to the BULK IN request at the line "46122"
immediate after ABORT PIPE request at the line 46132.

The application couldn't get the data of line 46131, but it is checked that
the line 46131 contained 
complete missing data (actually, no data was missing)

In the condition of this test, PKTEND signal from FPGA was not asserted,
so, the committed data amount must have been 16KB (DMA buffer size).

But it seems that the 4KB of data was transferred to PC,
and the data was lost with timeout of XferData() method.
The remaining data was transferred in the next 16KB transfer.

The reason of this problem is not clear yet. Any suggestions?

 

------------------
The table below shows the USB communication log of wireshark when the DMA buffer was empty.

line time src dest pkt size  
1229 0.302426 host 1.8.1 27 URB_BULK in
1253 0.409002 host 1.8.1 27 URB_FUNCTION_ABORT_PIPE
1254 0.409134 1.8.1 host 27 URB_BULK in
1255 0.409153 1.8.1 host 27 URB_FUNCTION_ABORT_PIPE

 

Host requested BULK IN at the line 1229,  and,  requested ABORT PIPE in the line 1253.
(this time, timeout setting was 100ms)
Immediate after ABORT PIPE request, FX3 returned ZLP at the line 1254 in response for the request at the line 1229. 

This behavior is very similar to the behavior of the FX3 when data is missing.
Is this normal behavior, or,  is something wrong?

Any suggestions would be greatly appreciated. 

0 Likes
1 Solution
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Based on your state machine, you are sending a ZLP soon after a short packet. This is not a recommended approach. In the slave FIFO interface, FPGA is the master and it should initiate the transfer of the ZLP as done in the state machine of AN65974. You can initiate the transfer of a ZLP from the FPGA side if you feel that the last packet to be transferred is going to be a multiple of max packet size but less than the DMA buffer size or you can configure the FPGA to simply send a ZLP at the end of a short packet.

Based on our discussion, the issue is:

When the partial buffer (which is a multiple of  packet size) is sent by the FPGA, the FX3 commits the data to the USB side. But, as the data size is less than 16KB (the host requests for 16KB) and as the transfer is not terminated by ZLP, the host will wait for the transfer to end (ZLP to be received by FX3). Once the ZLP is received, the host will terminate the transfer and the application can get the data properly. If the ZLP is not received before the timeout, then the transfer will be aborted and the application will not get the data.

From the FX3 side, it is not possible to have different time differences for different packets. Also, as we have seen that the project works fine with streamer application (delay is less), we request you to go through the source code of streamer and make changes in your host application so that the transfer failures can be avoided.

Best Regards,
Jayakrishna

View solution in original post

0 Likes
11 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Based on our understanding, you are not seeing any loss of data. The data will be received completely even if it is missed in one transfer. Please correct me if my understanding is wrong.

We would like to check the complete Wireshark trace in order to understand the reason for the ABORT PIPE request seen in the traces. Also, please let us know the following information:

1. Was the FPGA configured to send 16KB (full buffers) only to the FX3 device or are there chances for the FPGA to send partial buffers or even ZLPs?

2. Please share the UART debug prints along with the wireshark traces. The UART debug prints should have the size of data received from the FPGA. This can be used to verify if FX3 always commits full buffers to the USB host.

3. Please let us know if a custom host application is used for capturing the data from the FX3 device. If yes, then please try using the default streamer application that comes along with FX3 SDK and let us know if you still face the same issue. 

4. Please try testing at a greater timeout value (1s) and let us know if there are any changes in the frequency of occurrence of the issue.

Best Regards,
Jayakrishna
0 Likes

Thank you for your reply.

Let me check things you mentioned in the last post.

 

--------

>The data will be received completely even if it is missed in one transfer.

The data is lost for the application because XferData() discards the data probably due to timeout.
(The system has no function to resend the lost data)
But I can still see complete data in discarded data packet on Wireshark log.

 

-------

>2. Please share the UART debug prints along with the wireshark traces. 

UART debug print is unavailable in my system. 
I may be able to check the data via another channel
if you specified the variable which contains the size of data received from FPGA. 
(and timing to check the variable value)

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

a. "I may be able to check the data via another channel
if you specified the variable which contains the size of data received from FPGA. "

>> As you might be knowing, a DMA channel is used for transferring data received from the FPGA to the USB host. This DMA channel is created between P Port (interfaced with FPGA) and USB socket (for communication with the host). When a buffer is received from FPGA (full/partial buffer), the DMA callback function will be invoked. This function should is CyFxSlFifoPtoUDmaCallback in the default Slave FIFO project that comes along with AN65974. If you have developed your project on top of the firmware that comes along with AN65974, then you will be using the same function. Inside this function, an API is used to commit the data to the USB side. The usage of this API is given below:

status = CyU3PDmaChannelCommitBuffer (chHandle, input->buffer_p.count, 0);

The parameter input->buffer_p.count needs to be tracked whenever a DMA callback is triggered so that we can understand the amount of data received by the FX3 device from the FPGA. Please note that it is not recommended to use any blocking calls inside the DMA callback function.

b. Also, regarding the following statement in your previous response:

"UART debug print is unavailable in my system."

>> Is this because the UART lines of FX3 are not physically routed on your PCB? If yes, then you can try adding a CDC interface to your project to obtain the debug prints. Please refer to the following blog post which describes the required steps that should be done:

https://community.infineon.com/t5/Resource-Library/SlaveFiFoSync-example-with-a-CDC-debug-console/ta...

UART debug logs are essential for us to understand all the events that occur within the firmware. So, it will be better if you can share the UART debug logs for us to debug the issue.

c. In addition to this, regarding the following statement in your previous post:

"The data is lost for the application because XferData() discards the data probably due to timeout. (The system has no function to resend the lost data)
But I can still see complete data in discarded data packet on Wireshark log."

>> Does this mean that the 4KB data shown as fragments of Wireshark trace in your problem description is actually not received by the host application? Is it the discarded data packet on Wireshark log?

Best Regards,
Jayakrishna
0 Likes

Thank you for your advices.

Please give me some time to check things you mentioned.
I'm now working for that.


----------------------------
>Does this mean that the 4KB data shown as fragments of
> Wireshark trace in your problem description is actually not
> received by the host application?
> Is it the discarded data packet on Wireshark log?

(1) The 4KB data is not received by the "host application".

(2) I can see the 4KB data in Wireshark trace.
(I'm not familiar with terms so I'm not clear it's "fragment" or not though)

(3) I checked the 4KB data in Wireshark trace and the contained data was
complete data.
The 4KB data was continuous from the previous data, and to the next data.

(4) The previous data and the next data was successfully received by the
"host application".

 

----------------------------
>Is this because the UART lines of FX3 are not physically routed on your PCB?
>If yes, then you can try adding a CDC interface to your project to obtain the debug prints.

My system is using the UART port for an another reason and
it's essential to operate the system.
So I'm using a USB endpoint as a debug print port.
I'm planning to check the status via that debug channel.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Based on your previous reply, we suspect that the FPGA would have sent a 4KB packet to the FX3 device in a FIFO write operation by asserting PKTEND signal. Please take your time and share the UART debug logs so that we can verify if this is correct or not.

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

 

You already advised me to check the FPGA, but I answer for each of your confirmation items.
(just for someone who read this topic tree later)

------

>1. Was the FPGA configured to send 16KB (full buffers) only to the
>FX3 device or are there chances for the FPGA to send partial buffers or even ZLPs?

The data amount that FPGA sends to FX3 is unknown, so partial buffers can be committed.

The FPGA sends a unique code and PKTEND signal at the end of the data.
I have never seen the unique code nor PKTEND signal so far when this issue occurred. 

GPIF II is configured to send a ZLP when PKTEND signal is asserted.
(There is a state which has COMMIT action, without IN_DATA action, to send a ZLP.)

 

>2. Please share the UART debug prints along with the Wireshark traces.
>The UART debug prints should have the size of data received from the FPGA.
>This can be used to verify if FX3 always commits full buffers to the USB host.


The UART port is unavailable (already used for another purpose) in my system but
I'm working to check FX3 API internal status via another channel.

 

>3. Please let us know if a custom host application is used for capturing the data from the FX3 device.
>If yes, then please try using the default streamer application that comes along with FX3 SDK and let us know
>if you still face the same issue.

I run streamer app on same hardware.
Data lacking has not been found with the streamer app.
Also, FX3 response delay to host's transfer request has not been found.

 

>4. Please try testing at a greater timeout value (1s) and let us know
>if there are any changes in the frequency of occurrence of the issue.

(1)
I changed the time out value to 1000ms and the issue has never been occurred.

(2)
I found that FX3 response time values for host's request were basically below 1ms,
however, occasionally it went over 100ms and sometimes reached almost 1000ms.
This is bit a problem for data throughput for my system.

I didn't see such behavior with streamer app.
I attach a Wireshark log pasted in an Excel file just for reference. 
It contains logs of both my app and streamer app
.

What factors may affect the response time?

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

It looks like when you have used Streamer Application, you are trying to send data from host to the device (OUT operation) and when you are using your custom application, you are reading data from the device (IN operation). Please let us know why there is a difference. Please test whether the IN operation is working fine with streamer application or not.

Regarding your following question:

"What factors may affect the response time?"

The difference or factor here could be the way in which the requests are queued by the host application. Please refer to the source code of streamer application to understand the way in which requests are queued by the Streamer application. You can try to use the same way to queue the requests from the USB host so that the time difference can be reduced. The source code of streamer application can be found in the following location:

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\application\c_sharp\streamer

Also, regarding the following line:

"The data amount that FPGA sends to FX3 is unknown, so partial buffers can be committed."

Please note that the partial buffers committed by FX3 should not be a multiple of max packet size. If the size of the partial buffer is a multiple of max packet size, then a ZLP should be issued at the end so that the host receives the data properly. Otherwise, the host will not be able to receive the data correctly.

We can confirm the exact size of data received by FX3 in each write from FPGA once you finish setting up the debug channel. Please share this information once it is available.

Also, it will be better if the Wireshark traces are shared as .pcap files (you can zip the file). 

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

Thank you for your detailed lectures.


>Please let us know why there is a difference. 

It's just my mistake. I tested streamer app with IN endpoint and it also worked fine.


>The difference or factor here could be ...
I'll study the code later to learn how to queue requests.


>Please note that the partial buffers committed by FX3 should not be a multiple of max packet size.

I understand this rule and it's solved by designs as follows.

(1)
The FPGA always tries to send data to FX3.
Buffer full flag, Partial flag is dealt correctly and FPGA's write operation is controlled.
The data write size from FPGA is basically same to the max buffer size
since FPGA tries to write data until Buffer full flag is asserted.

(2)
The requested transfer size from host is set same with the max buffer size (it's 16KB).
This is a multiple of max packet size, however, host can receive data since
requested transfer size is fulfilled.

(3)
The FPGA has its buffer to storage write data. Once FPGA's buffer becomes empty,
FPGA sends a unique code then stop sending data.
PKTEND signal is also asserted at the same clock with the last write data.
The write data size may or may not be a multiple of max packet size at this time.

(4)
GPIF II commits the buffer and generates ZLP after that, by receiving PKTEND signal.


My understanding is that (2) and (3) solve the multiple-of-max-packet-size problem.
Does this design principle work fine?
It seems this works fine with my system so far but the occasional issue of this topic tree.

I attach the GPIF II project file for reference.
("PKTEND" signal is named as "EOD" in this project)


>We can confirm the exact size of data received....
>Also, it will be better if the Wireshark traces are shared as .pcap files (you can zip the file).

I'm now working to gather these data. Please give me time bit more...

 

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Based on your state machine, you are sending a ZLP soon after a short packet. This is not a recommended approach. In the slave FIFO interface, FPGA is the master and it should initiate the transfer of the ZLP as done in the state machine of AN65974. You can initiate the transfer of a ZLP from the FPGA side if you feel that the last packet to be transferred is going to be a multiple of max packet size but less than the DMA buffer size or you can configure the FPGA to simply send a ZLP at the end of a short packet.

Based on our discussion, the issue is:

When the partial buffer (which is a multiple of  packet size) is sent by the FPGA, the FX3 commits the data to the USB side. But, as the data size is less than 16KB (the host requests for 16KB) and as the transfer is not terminated by ZLP, the host will wait for the transfer to end (ZLP to be received by FX3). Once the ZLP is received, the host will terminate the transfer and the application can get the data properly. If the ZLP is not received before the timeout, then the transfer will be aborted and the application will not get the data.

From the FX3 side, it is not possible to have different time differences for different packets. Also, as we have seen that the project works fine with streamer application (delay is less), we request you to go through the source code of streamer and make changes in your host application so that the transfer failures can be avoided.

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

Hello, thank you for your suggestions.

Please let me ask some questions about your lectures.

>Based on your state machine, you are sending a ZLP soon after a short packet.
>This is not a recommended approach.
>In the slave FIFO interface, FPGA is the master and it should initiate the transfer of the ZLP as done in the state machine of AN65974.

I'm still not clear what exactly "soon after" mean.
Would you tell me which state machine diagram (or article) you mentioned in AN65974?


>You can initiate the transfer of a ZLP from the FPGA side if you feel that the last packet to be
>transferred is going to be a multiple of max packet size but less than the DMA buffer size or you can configure
>the FPGA to simply send a ZLP at the end of a short packet.

The FPGA doesn't know the data amount due to the system architecture at this moment,
so that the FPGA asserts PKTEND to let GPIF II send a ZLP at the end of data transmission every time.
(As I explained in last post)
For example, if the the data amount is 36KB, One PKTEND pulse is asserted at the end of 36KB.
Two 16KB buffers, One 4KB buffer, and One ZLP should be committed.

I think this design complies with your statement.
Please tell me if something is wrong.


-------------
>When the partial buffer (which is a multiple of packet size) is sent by the FPGA, the FX3 commits the data to the USB side.
>But, as the data size is less than 16KB (the host requests for 16KB) and as the transfer is not terminated by ZLP,

The FPGA performs next three possible operations.

(1) The data size is 16KB. No ZLP.
The FPGA always try to send a data, so, 16KB buffer is fully filled most time.
The FPGA doesn't assert PKTEND, but the buffer is committed by FX3 automatically.
(2) The data size is less than 16KB. ZLP is sent.
The FPGA asserts PKTEND at the end of a data transfer, so, ZLP should be sent at the end of a data transfer.
(3) The data size is 16KB. ZLP is sent.
This is rare case of (2). The data size was just 16KB unintentionally. The FPGA asserts PKTEND.

I think "less than 16KB data size, without ZLP" pattern will not occur in this design.
We can also think next pattern.

(4) A 16KB buffer is already fully filled and automatically committed by FX3 and
The FPGA continues to write data to next buffer.

At (4), I think the first 16KB buffer is already committed so the buffer is already ready to be sent to USB host. The next 16KB buffer is still not committed so it doesn't affect any USB response.

-------------
>the host will wait for the transfer to end (ZLP to be received by FX3). Once the ZLP is received,
>the host will terminate the transfer and the application can get the data properly.
>If the ZLP is not received before the timeout, then the transfer will be aborted and the application will not get the data.

I agree with this.
However, I also see FX3's response delay even when response is only just ZLP.
(I think this means FX3 has no committed buffer)
I afraid that your assumption is not valid in the situation.

I attach a Wireshark log.
At line 12779 and 12782, timeout for ZLP response is occurred.
At line 12911, timeout for data transfer response is occurred.
The data is a multiple of 1024 and it seems there was no ZLP.

I apologize  for no attachment of the debug print log. I'm still working for it.


-------------
>Also, as we have seen that the project works fine with streamer application (delay is less),
>we request you to go through the source code of streamer and make changes in your host
>application so that the transfer failures can be avoided.

I'm working on this for both streamer application and bulkloop example firmware.

0 Likes
lock attach
Attachments are accessible only for community members.
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Please find my comments below:

"I'm still not clear what exactly "soon after" mean."

>> This means that in your state machine, once the last data is read by FX3, the state machine will switch to State 5 and commit the short packet along with a ZLP. 

"Would you tell me which state machine diagram (or article) you mentioned in AN65974?"

The state machine of AN65974 is attached along with this response. You can also download it by downloading the AN65974 file from the following link:

https://www.infineon.com/cms/en/product/universal-serial-bus-usb-power-delivery-controller/periphera...

"The FPGA doesn't know the data amount due to the system architecture at this moment,
so that the FPGA asserts PKTEND to let GPIF II send a ZLP at the end of data transmission every time."

>> I understood the current approach that you have used. But, we would recommend to initiate sending the ZLP from the FPGA side itself by keeping a track of the amount of data to be sent to the FX3 device. This is the approach that we recommend as the transfers should be initiated from the FPGA side based on the availability of buffers on FX3 side rather than being initiated from the FX3 side.

Please refer to the following thread where we have recommended 2 methods to avoid the partial buffer problem:

https://community.infineon.com/t5/USB-superspeed-peripherals/XferData-may-return-FALSE-in-short-pack...

You can use any of these methods and use the standard AN65974 state machine.

Regarding the wireshark trace, kindly share the wireshark trace along with the debug print log so that we can compare and analyze the data that is committed by FX3. We understand that you are still implementing the debug print. Please take your time to implement this functionality and kindly share the debug logs and wireshark traces taken together.

Best Regards,
Jayakrishna
0 Likes