FX3 Difference in behaviour between USB2 USB3 operation

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

cross mob
lock attach
Attachments are accessible only for community members.
chmc_1313166
Level 1
Level 1

We have an application when sends a Vendor command to our FX3, which is handled by the embedded software, followed by a BULK OUT data transfer over the GPIF interface with an IN response expected.

The BULK transfers are handled by AUTO DMA mode and are known to be working fine.

Over USB3 we have no issues and the LeCroy USB trace shows SETUP, OUT, IN as expected.

On USB2 the IN transfer is always delayed by a number of seconds. The trace shows SETUP, OUT, <delay of a number of seconds>, IN.

The USB2 and USB3 captures are shown in the attached files.

On USB2 IN, packets are constantly NACK'ed and eventually the IN data is transferred.

Any pointers, please.

Thanks.

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hello,

- Please find the attached screenshots. In the 1.PNG file, I have hidden devices other than device address 4 whereas in 2.PNG, all the captured devices are present.

- In the view shown as in 1.PNG, the transaction indicates the time duration to be around 5sec. After the vendor command (0xB8) (Setup request), device with address 2 has resumed its previous transfer. This can be seen from 2.PNG. So, the device at address 4 waits for bandwidth on USB bus before it could handle any transactions.

Best regards,

Srinath S

View solution in original post

0 Likes
6 Replies
SrinathS_16
Moderator
Moderator
Moderator
1000 replies posted 750 replies posted 500 replies posted

Hello,

Please check if your screenshot is intended to have the IN transaction following the OUT transaction in case of USB2.0 transfers. The captued image does not have an IN transaction following the OUT transaction. Please share the .usb file for us to view.

Best regards,

Srinath S

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

Thanks for the reply and apologies, I pickup up the wrong USB2 screen capture.

See attached.

The expected file shows the OUT/IN exchange without the SETUP vendor command.

The delay on in packet files show the OUT/IN exchange after the SETUP vendor command. The delay is always approximately 5 seconds.

Is it possible to upload .usb files, they are appoximately 100 MBytes.

0 Likes

Hello,

From the usb2_capture_delay_on_in_packet_after_setup_annotated.png file, I find that the Transfer Number of the annotated ACK packet is 985134 and that of the subsequent IN request from the host is 3617260. Please un-hide all the transactions and check what happens between these two phases.

You can upload the .usb file to drive and share the link.

Best regards,

Srinath S

0 Likes

Thanks,

Here is a Dropbox link to the USB Protocol Suite save ".usb" files - https://www.dropbox.com/sh/j50iwcj2pt3ptp9/AACeJwDVwus02E_ItFagZPrba?dl=0

"usb3_capture_in_after_setup.usb" shows the trace when connected to USB3 host. No delay on IN packet after SETUP vendor command.

"usb2_capture_in_after_setup_delayed.usb" shows the trace when connected to USB2 host. Delay on IN packet after SETUP vendor command.

"usb2_capture_in_expected.usb" shows the same trace when connected to USB2 host without the SETUP vendor command. No delay as expected on IN packet after SETUP vendor command.

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

Hello,

- Please find the attached screenshots. In the 1.PNG file, I have hidden devices other than device address 4 whereas in 2.PNG, all the captured devices are present.

- In the view shown as in 1.PNG, the transaction indicates the time duration to be around 5sec. After the vendor command (0xB8) (Setup request), device with address 2 has resumed its previous transfer. This can be seen from 2.PNG. So, the device at address 4 waits for bandwidth on USB bus before it could handle any transactions.

Best regards,

Srinath S

0 Likes

In USB3 mode, the buffer is forcibly purged at any byte reception.

In the USB2 mode, the forced flushing of the buffer is not performed; it is timed out.

0 Likes