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

USB superspeed peripherals Forum Discussions

mialc_1106291
Level 4
First solution authored First like given 25 sign-ins
Level 4

Hi,

I've written a custom bootloader for the CYUSB3014-BZXC using the Cypress Boot API. We've been using this bootloader without issue for the past couple of months. However, someone recently plugged the board into a USB 3.1 host controller using a USB 2.0 cable. Upon doing so we discovered that in USB 2.0 mode the device stops responding to standard requests after being suspended and then resumed. The traffic on the USB bus was captured with an Ellisys EX350 and shows the following transactions:

1. get device descriptor (success)
2. set address (success)
3. get device descriptor (success)
4. get configuration descriptor (success)
5. get BOS ddescriptor (success)
6. get serial number descriptor (success)
7. get language ID descriptor (success)
8. get product descriptor (success)
9. set configuration 1 (success)
10. LPM transaction (success)
11. Suspended
12. Resume
13. get language ID descriptor x 6 (failure)
14. get manufacturer descriptor x 6 (failure)
15. get product descriptor x 6 (failure)

UART Debug message prints from the firmware show the following:

Initializing FX3 Boot Firmware 1.6
Boot FW Event: CY_FX3_BOOT_USB_IN_SS_DISCONNECT
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_RESET
Boot FW Event: CY_FX3_BOOT_USB_RESET
Boot FW Event: CY_FX3_BOOT_USB_RESUME

Are there any special actions that the firmware must take when it receives CY_FX3_BOOT_USB_SUSPEND or CY_FX3_BOOT_USB_RESUME in order to get the FX3 to ACK the control requests that take place after the the suspend and resume operations?

We also seem to experience the same problem when running the application firmware (uses Cypress full API) when the device is plugged in with a USB 2.0 cable. The bus activity is similar:

1. get device descriptor (success)
2. set address (success)
3. get device descriptor (success)
4. get configuration descriptor (success)
5. get BOS ddescriptor (success)
6. get serial number descriptor (success)
7. get language ID descriptor (success)
8. get product descriptor (success)
9. LPM transaction (success)
10. Suspended
11. Resume
12. set configuration 1 x 3 (failure)
13. Suspended

So the same question applies for the application firmware: what steps must we take in firmware in order for control transfers to succeed after the device has been suspended and then resumed?

Some other information that you may find useful:

Operating system: Windows 10
Host Controller: Asmedia ASM3142
Hub: none

I appreciate any help you can provide.

Thanks,
Michael

0 Likes
40 Replies
AliAsgar
Moderator
Moderator 50 likes received 500 replies posted 250 replies posted
Moderator

Hi,

Could you let us know which Infineon IC are you working on?

Best Regards,
AliAsgar

0 Likes