FX3 / Android USB3.0 HBTERM interrupt and reset event

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

cross mob
viscc_2970671
Level 1
Level 1

Hi all,

     I'm trying to interface an FX3 with an Android device, and I'm getting an HBTERM interrupt, whose handler generates a RESET event and clear the internal buffers. The RESET event and clear buffer actions causes the FX3 to go into stall, and it takes some ~10s to resume streaming when this arrives. I can't find anywhere in the documentation which condition leads to the HBTERM interrupt being raised, how does this relate to the USB 3 protocol, and what actions should be taken. Does anyone have any insights on why this happens?

     What I can see on my side, is that it seems to happen after a few RETRY events. And secondly, commenting out the code in the HBTERM handling function so as to not launch the RESET event and not clear the internal buffers, it seems that we get more RETRY events, but we're able to stream correctly eventually, without the ~10s penalty when the RESET and clear buffer actions are performed.

     Setup:

     CYUSB3KIT-003 FX3 development board.

     Open-Q™ 845 HDK Development Kit  for Snapdragon 845 running with Android 9 in developer mode (Connection via the USB-C connector on the SDA845 board)

     We're using asynchronous bulk transfers, and we're able to reproduce this behavior with the cyfxbulksrcsink example firmware in the Cypress FX3 SDK v1.3.4.

Best regards,

V. Schwambach

0 Likes
1 Solution
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Schwambach,

Anytime, host evaluates that there are too many retries happening on the bus, then to serve other end-points, it may terminate the burst prematurely.

The following are the ways Host can terminate the Burst:

1. Host terminates the burst prematurely by sending ACK token with NumP = 0 and Retry bit set

2. Host comes and starts transfers on to a different end-point when there is data still pending to be acknowledged.

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
1 Reply
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Schwambach,

Anytime, host evaluates that there are too many retries happening on the bus, then to serve other end-points, it may terminate the burst prematurely.

The following are the ways Host can terminate the Burst:

1. Host terminates the burst prematurely by sending ACK token with NumP = 0 and Retry bit set

2. Host comes and starts transfers on to a different end-point when there is data still pending to be acknowledged.

Regards,

Hemanth

Hemanth
0 Likes