Control requests fail after device suspend and resume

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.
mialc_1106291
Level 4
Level 4
10 questions asked 50 sign-ins 50 replies posted

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
55 Replies
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi Michael,

Could you let us know if a similar issue is happening with other host controllers, apart from the ASM3142?

Could you register a USBeventcallback in the appfw and add switch cases for CY_U3P_USB_EVENT_RESUME and CY_U3P_USB_EVENT_SUSPEND and add prints when these events occur and share with us the UART debug print?

You could refer to USBBulkSourceSink firmware example in FX3 SDK for implementation.

I see that in both the conditions, the resume signaling is for ~1ms. But according to the USB 2 spec, host must send resume signaling for atleast 20 ms.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

My colleague has reported that the bootloader firmware enters a suspend loop when he uses a high speed cable to plug directly into the USB3 superspeed A port on his laptop, which is downstream of an Intel USB 3.1 eXtensible host controller. This is the information he gave me:

I see the suspend loop with the boot fw when:
- USB2-HS A-C cable is connected to the laptop’s USB3-SS-A port (with or without USB2 dongle)
- no problem: with the same cable connected to any USB3-SS/HS-C-A or USB2-HS-A-A hub port
- USB3-SS A-C cable is connected through USB2-HS-A-A dongle to laptop’s USB3-SS-A port
- no problem: with the same cable connected to any port or hub, or with dongle to any hub port
I’ve tried disabling the selective suspend and LPM OFF but it does not help.
The full fw is working I all cases! I see no suspend loop in any wiring condition.

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_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
… every 4.602ms

Unfortunately, my colleague experiencing this problem is in a different country and doesn't have access to a USB packet analyzer so I can't provide the bus transactions.

I added the UART logging to the application firmware. Here's the output:

Firmware version 1.5
USB event CY_U3P_USB_EVENT_SUSPEND
USB event CY_U3P_USB_EVENT_RESUME
USB event CY_U3P_USB_EVENT_SUSPEND

Plugged into Intel USB 3.0 eXtensible host controller in my PC the bootloader UART log shows:
Initializing FX3 Boot Firmware 1.5
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

The USB traffic log shows that the device is initially suspended for 19.183ms, then reset for 54.782ms, then enumeration takes place and all control transfers are successful. My application can also see the device, which is not the case when plugged into the Asmedia controller using a USB 2 cable.

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

Hi AliAsgar,

I found a local colleague with a laptop that has an Intel 3.1 controller. When I plug the FX3 board running the bootloader into his laptop I see the suspend resume loop that my colleague in Romania reported. Some observations:

1. Resume is only for 950 microseconds
2. Control transfers are successfully completed after resume (not true for Asmedia)
3. The PC keeps re-enumerating the device over and over and we could hear the Windows device connect/disconnect sound
4. The device is not visible to our application
5. If we use a USB 3.0 cable everything works correctly. There is no suspend loop, no continuous enumeration, and our application can see the device.

Please see attached Ellisys Explorer USB 350 traffic capture (intel_31_host_bootfw_usb2_cable.u31t)

I have another version of the bootloader firmware that disables LPM. When I connect the board with a USB 2.0 cable to the Intel 3.1 controller while it's running this version of the firmware Windows performs the initial enumeration and sets the configuration, but then resets the bus and after that there is an infinite loop of link violations and resets and the device is not accessible. Please see intel_31_host_bootfw_lpm_disable_usb2_cable.u31t for the USB traffic log.

Thanks,
Michael

 

0 Likes

Hi Michael,

I have requested for the Ellisys explorer 350 software to open the .u31t files you have shared. Meanwhile, could you clarify some statements from your previous two replies.

1. 
"- USB2-HS A-C cable is connected to the laptop’s USB3-SS-A port (with or without USB2 dongle)
- no problem: with the same cable connected to any USB3-SS/HS-C-A or USB2-HS-A-A hub port
- USB3-SS A-C cable is connected through USB2-HS-A-A dongle to laptop’s USB3-SS-A port
- no problem: with the same cable connected to any port or hub, or with dongle to any hub port"

>> Does this mean that if the device is directly connected to the laptop port in USB 2.0, the issue (suspend loop) is seen. But if the device is connected to the laptop's USB port through a hub in USB 2.0, there is no issue seen.

2. 
"The full fw is working I all cases! I see no suspend loop in any wiring condition."

>>Could you clarify what this means?

So from what I understand, here are the three test cases (apart from the Asmedia host):

1. Intel 3.1 host controller - Suspend loop - continuous Suspend commands on the USB bus.
2. Intel 3.0 host controller - everything working fine
3. Intel 3.1 host controller - Renumeration of the device occurring again and again resulting in failure.

Is my understanding correct?

I assume the device is a custom FX3 board.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

1. 
"- USB2-HS A-C cable is connected to the laptop’s USB3-SS-A port (with or without USB2 dongle)
- no problem: with the same cable connected to any USB3-SS/HS-C-A or USB2-HS-A-A hub port
- USB3-SS A-C cable is connected through USB2-HS-A-A dongle to laptop’s USB3-SS-A port
- no problem: with the same cable connected to any port or hub, or with dongle to any hub port"

>> Does this mean that if the device is directly connected to the laptop port in USB 2.0, the issue (suspend loop) is seen. But if the device is connected to the laptop's USB port through a hub in USB 2.0, there is no issue seen.

>>>> Yes, that's what he means. I have not tried placing a hub between the Asmedia 3.1 controller and the FX3 to see if the behavior is different, as I don't have an extra hub on hand to perform that experiment.

2. 
"The full fw is working I all cases! I see no suspend loop in any wiring condition."

>>Could you clarify what this means?

>>>> He means that he's using the application firmware, which he download through the USB Control Center after erasing the EEPROM. He said when he uses the application firmware there is no suspend loop with the USB 2 cable when plugged into his Intel 3.1 host controller. The Asmedia 3.1 controller has issues with both bootloader and application firmware.

So from what I understand, here are the three test cases (apart from the Asmedia host):

1. Intel 3.1 host controller - Suspend loop - continuous Suspend commands on the USB bus.
2. Intel 3.0 host controller - everything working fine
3. Intel 3.1 host controller - Renumeration of the device occurring again and again resulting in failure.

Is my understanding correct?

>> I think in case 1 there is also re-enumeration on top of the suspends. That's also what happens in case 3 and you'll see that once you are able to open the traces. Everything works fine with the Intel 3.0 host controller works fine.

I was curious as to why the Cypress bootloader doesn't have this issue and after looking at the traces I found that it reports 0x0200 for bcdUSB in the device descriptor. Our descriptor reports 0x0210 in the descriptor, as required for a USB 3 device. I did try setting bcdUSB to 0x0200 temporarily in our bootloader and found that the issues went away. I don't think we can keep bcdUSB set to 0x0200 though because the USB 3 specification requires USB 3 devices to support LPM in USB 2 mode, which means reporting 0x0210 for bcdUSB so that the host requires the binary object store. Therefore, I need a real solution to this problem.

0 Likes

Hi,

Could you share with us the descriptor file in of your custom bootloader?

We use bcdUsb as 2.1 for most of the application firmware with the FX3SDK. But in your query you have mentioned that a similar problem occurred with the application firmware in the Asmedia host. Could you let me know what was the bcdUsb for your application firmware, for which you had shared the snippet of the trace.

Best Regards,
AliAsgar

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

Hi AliAsgar,

I've attached a file that contains the definition of the descriptors that the bootloader returns.

The bcdUsb version reported in the application firmware when connected with USB 2.0 cable is 0x0210, the same as the bootloader firmware.

One other thing that may be worth mentioning is that our bootloader firmware has issues with control transfers when plugged into an Intel 3.1 host controller. We found that disabling LPM when a set_configuration request works around the problem and therefore we are making a call to CyFx3BootUsbLPMDisable() when we process a set configuration request. This is not necessary in the application firmware, which seems to be able to properly handle LPM requests. I'm planning to open a separate support thread for this issue.

Thanks,
Michael

0 Likes

Hi Michael,

For the Boot firmware descriptor,
in the USB 2 Extension Descriptor under BOS Descriptor, bmAttributes can be made 0x00, 0x00, 0x00, 0x00.
This will notify the host that the device doesn't support Link Power Management Protocol.

As the application firmware does not seem to have this problem. This workaround maybe useful for your bootloader firmware.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

I  have confirmed that changing bmAttributes to 0x00000000 in the BOS descriptor works around the problem when the device is connected to the Asmedia 3.1 controller. I suspect that it will do the same on the Intel 3.1 controller, which I do not have access to at the moment. However, I would like to point out that the description for the bmAttributes field of the USB 2.0 Extension Descriptor states the following in both the USB 3.1 and 3.2 specifications:

"LPM. A value of one in this bit location indicates that this device supports the Link Power Management protocol. Enhanced SuperSpeed devices shall
set this bit to one."

I'd also like to point out that the same issue occurs with the application firmware when the board is connected to the Asmedia 3.1 controller. I will confirm with my colleague that he's not seeing this with the application firmware on the Intel 3.1 host controller.

I wonder if there is something in the Windows driver that could affect suspend. Do you think that this might be driver related?

Thanks,
Michael

 

0 Likes

Hi Michael,

It is a known issue that Asmedia 3.1 host controller has issues with USB 2 suspend/resume in our device. We have had customers facing similar issues before on the same host controller.

We are providing the customers the workaround for this issue as to change bmAttributes as 0x00000000 in the BOS descriptor, which is basically disabling LPM for USB 2.

I believe that the issue is with the Asmedia 3.1 host controller particularly. The host is not able to properly manage the link power and the entry exit to and from each state.

One more thing I noticed is that in the Asmedia host controller, the suspend(L2) resume loop is always preceded by an L1 entry.
But in the intel host controllers, the L1 entry is not present before the suspend resume loops.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

Any idea why it doesn't work on Intel 3.1 host controllers but works on Intel 3.0? I don't know if we will run compliance testing on our device but I don't expect those tests to pass with LPM disabled in the descriptor which is why I'm looking for an alternate solution.

Thanks,
Michael

0 Likes

Hi Michael,

The issue with Intel 3.1 host controller is only with boot_fw right, and not with application_fw?

Could you send us the image file of the FX3 boot_fw where the issue is seen. We will try to reproduce the issue? If possible, also send the boot_fw source code.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

 

I cannot send you the firmware source code until I'm able to verify that our companies have a mutual NDA in place. We are coming up on a holiday weekend in the USA and some people are already out of office, so this may take some time.

One can argue that the firmware image itself could be retrieved from the EEPROM on product once it's made for sale, and therefore I'm convinced that I can send you the firmware even if our companies do not have an NDA in place. Plus I think there is some chance that we already have an NDA. Anyway, I will send you the firmware image through a separate message. I compiled a version that will run on CYUSB3KIT-003 and tested it.

Thanks,
Michael

0 Likes

Hi Michael,

Could you let us know what kind of test setup are you working on? 
By this what I mean to ask is the FX3 connected directly to the host? or do we have a compliance testing kind of a setup?
Basically we are trying to understand how the suspend-resume is occurring on the USB bus.

Also please let me know if the device is bus-powered or self-powered?

I also wanted to let you know that we are not facing the issue with the Intel 3.1 host controller on our end, with both the USBBulkSourceSink firmware or the boot firmware image shared by you.

The resume is occurring for 48ms which is very much higher than 20ms and thus no transfers are failing and even the enumeration is working fine.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

In all instances the FX3 is connected directly to the USB port on the host (there is no external hub) - we aren't running a compliance test.

We are testing with Intel 3.1 by plugging the board directly into my co-workers Dell Precision 5560 laptop.

The board is bus powered. However, we do have 5V power muxing between VBUS and an external supply so it is possible to self-power the board but we haven't tested it that way on the Intel 3.1 controller. To further clarify, we have an onboard 3.3V regulator connected to VBAT and VBUS is connected to the VBUS pin of the FX3 through
an overvoltage protection device. In our firmware we call CyU3PUsbVBattEnable with CyTrue when we compile for anything other than the CYUSB3KIT-003.

I haven't tried the CYUSB3KIT-003 with my coworker's laptop yet, but I did try it with the Asmedia 3.1 controller, and it too suffers the same suspend / resume issue as our custom board.

How does the host decide how long the resume should be?

Thanks,
Michael

0 Likes

Hi AliAsgar,

Did I send you the traces for this issue? I looked at them again and noted that the host initiates transition to LPM L1 with BESL set to 1ms before the bus shows suspend. The resume duration after the SUSPEND state is ~950us which is in line with the time published in table X-X1 BESL & HIRD Encodings in the USB2 LPM errata. Therefore, I think the resume duration is  not the issue and that something else is causing the problem.

Thanks,
Michael

0 Likes

Hi Michael,

Could you try changing the BESL value, i.e., the bmAttributes field in the USB 2 capability descrtiptor in the BOS descriptor to 

0x1E,0x11,0x00,0x00,

from 

0x1E,0x64,0x00,0x00,

and let me know if the issue is still seen?

Best Regards,
AliAsgar

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

Hi AliAsgar,

I tried it with the BESL values you proposed and the problem persists. However, now the host initiated resume is 100.35us which is in line with the LPM errata. I also tried setting BESL to 0x1E,0xFF,0x00,0x00 and found that the host initiated resume lasts for 9.980ms but still the problem persists.

One thing I did notice is that the SetConfiguration(1) request takes place 11.5us after resume stops. I wonder if this is too soon and that's why the control transfer fails on the Asmedia 3.1 controller? There seems to be a larger gap between resume stop and the first control transfer on Intel 3.1 controllers... approximately 39us.

Any other ideas?

Thanks,
Michael

 

0 Likes

Hi,

I am discussing this issue internally.

With my intel 3.1 host controller, I tried sending LPM-L1 requests to the device, it worked properly without any issues. Please look at the below snippet.

AliAsgar_0-1657542688927.png

 

We sent the LPM-L1 requests using the USB3CV tool. Could you let us know how you were able to get the LPM-L1 requests on the device?

Also please let me know your xHCI driver version number for the ASMEDIA host.

From the UART prints, can you confirm if we are getting a USB RESUME event on the Asmedia host when the issue is seen?

Please use the below API after the issue is seen:
CyU3PReturnStatus_t CyU3PUsbGetLinkPowerState (CyU3PUsbLinkPowerMode ∗mode_p)

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

The host controller is sending the LPM-L1 requests to the device automatically without us doing anything.

The driver version for the ASMedia 3.1 controller is 10.0.19041.1741

According to the UART prints these are the USB events seen when I attach the device running our bootloader firmware to the Asmedia 3.1 host controller:

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

Boot FW Event: CY_FX3_BOOT_USB_SUSPEND

If I look at the events that the Ellisys EX350 logs I see:

Reset (8.777s)

Suspended(100.119ms)

Reset (69.657ms, Port switched to high speed)

several successful control transfers

LPM Transaction (to L1, BESL of 1ms specified)

Suspended(5.139ms)

Resume (952.950us)

SetConfigure(1) // fails and states upstream missing

SetConfiguration (1) // fails and states uptstream missing

Suspended

Where should I CyFx3BootUsbGetLinkPowerState call ? From my main loop? I looked at the source code for that function and see that it returns when the link speed is not super speed. I don't think this is useful since the link speed is not super speed because we are using a USB 2.0 cable.

Thanks,
Michael

0 Likes

Hi Michael,

Could you call CyU3PUsbLpmDisable API when a Connect Event comes up in the USB Event Callback and then call CyU3PUsbLpmEnable API call when there is a SETCONF event in the USB event callback.
Please let us know if you still face the issue.

Please refer to the USBBulkSourceSink firmware example on how to register USB event callback and definition of the callback function.

Also from the Ellisys traces, is it possible for you to tell who sent out the resume signal, was it the device or the host?

You could also try using the USBBulkLpAutoEnum firmware example of the FX3 SDK and check if the issue is seen or not. In this firmware, the application firmware takes care of the enumeration, not the library.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

The bootloader does not contain a SETCONF event notifiation:

typedef enum CyFx3BootUsbEventType_t
{
CY_FX3_BOOT_USB_CONNECT = 0x00, /**< USB Connect Event */
CY_FX3_BOOT_USB_DISCONNECT, /**< USB DisConnect Event */
CY_FX3_BOOT_USB_RESET, /**< USB Reset Event */
CY_FX3_BOOT_USB_SUSPEND, /**< USB Suspend Event */
CY_FX3_BOOT_USB_RESUME, /**< USB Resume Event */
CY_FX3_BOOT_USB_IN_SS_DISCONNECT, /**< Event to check if the device is in SS Disconnect State */
CY_FX3_BOOT_USB_COMPLIANCE /**< USB Compliance Event */
} CyFx3BootUsbEventType_t;

Therefore, I called CyFx3BootUsbLPMDisable() for the CY_FX3_BOOT_USB_CONNECT and call CyFx3BootUsbLPMEnable() when I receive a Set configuration request. Please note that I was previously calling CyFx3BootUsbLPMDisable() during set configuration to work around an issue we have with LPM being enabled when the board is plugged into a USB 3.1 controller - I probably should open a separate support case for that issue.

Plugged into the Asmedia 3.1 using a USB 2.0 cable I see the following events:
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

I'm not sure why the CY_FX3_BOOT_USB_CONNECT event isn't received when using a USB 2.0 cable. What's odd, is with a USB3.0 cable I do get CY_FX3_BOOT_USB_CONNECT followed by CY_FX3_BOOT_USB_IN_SS_DISCONNECT but the device still is functional at USB 3 speed.

I tried adding the CyFx3BootUsbLPMDisable call to CY_FX3_BOOT_USB_IN_SS_DISCONNECT and that didn't make any difference. With the USB 2.0 cable I still see an acknowledged LPM transaction sent to the device moving it to L1 state followed by Suspend, resume, and then failed control transfers that say "Uptstream Missing" (I'm not sure what that means).

The Ellisys traces do not tell me who sent the resume signal but it comes within the amount of time specified for HIRD in the BESL bits so I assume that it's the host controller.

The example you are referencing uses the full API, not the boot API. Our firmware uses the boot API because it must fit into a 32KB EEPROM that has the last 1KB reserved for board specific configuration data.

Thanks,
Michael

0 Likes

Hello Michael,

Is it possible for you to share your source code for the project that makes use of Boot APIs with us? Is it built on top of Fx3BootAppGcc? 

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

I used Fx3BootAppGcc as a reference but have rewritten and added a lot of code.

I checked with legal and they will allow me to send the source code under NDA. Can you send me an email address that I can use to forward the NDA?

Thanks,
Michael

0 Likes

Hello Michael,

I have shared the e-mail id over a private message. You can share the source to that e-mail ID.

Best Regards,
Jayakrishna
0 Likes

Hi Michael,

Could you disable the LPM in your bootloader firmware in the BOS descriptor, and then in the application firmware, you can disable LPM when a USB connect event comes up, with evData = 0 (denoting USB 2 connection), and then enable LPM when SETCONF event comes up in the application firmware.

This should help bypass the LPM-L1 entry seen in between the enumeration.

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

I previously confirmed that clearing the LPM bit in the BOS descriptor works around the problem, but violates the USB 3 specification. I also confirmed that setting bcdUSB to version 2.0 also does the same thing.

I recently looked at the source code of the Ettus USRP B200 series bootloader and found that it reports bcdUSB 2.1 with the LPM bit set, but specifies 0 for all of the other bits. This is in line with the requirements of the "USB 2.0 Link Power Management Addendum" which did not originally include the BESL bits and instead marked all of those reserved set to 0.

The errata for the USB 2.0 Link Power Management Addendum states that if the BESL & Alternate HIRD definitions bit is set then the LPM bit must be set to a '1', but I didn't read anything that said we must set BESL bits. I think the Ettus firmware may actually still meet the requirements for passing a compliance test even though it only enables LPM and clears all of the BESL bits.

I tried this configuration with our custom bootloader and hardware and found that my Windows 10 host with Asmedia 3.1 controller no longer enters the suspend resume loop and that enumeration and configuration are successful. Bulk data transfer also works. Do you know if we can pass compliance testing if we set the LPM bit and clear the BESL bits? If so, then this seems like a reasonable solution to the problem. I haven't had a chance to see how this behaves on Intel 3.1 yet but hope to find time to try that out early next week.

Thanks,
Michael

0 Likes

Hi Michael,

You could download the USB3CV test tool from usb.org and perform the compliance tests for enumeration.
If the enumeration passes the USB3CV test, then you can be sure that the device follows compliance.

Best Regards,
AliAsgar

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

Hi AliAsgar,

I ran the Chapter 9 Tests for USB 2 devices when the board was connected with a USB 2 cable and found that it fails the L1 Suspend / Resume test. It also fails the USB 3 Suspend / Resume test. I'm not sure if this is because the BESL bit is clear or if it's because the device is not responsive to control transfers after a suspend followed by a host initiated resume. The report doesn't provide enough detail.

It also fails with a USB 3 cable and fails the U1 U2 test.

Perhaps this is because we call CyFx3BootUsbLPMDisable when a set configuration request is received? I tried removing that call and found that control transfers fail randomly on my Intel 3.0 host controller and then the link resets. My coworkers reported the same behavior with Intel 3.1 which is why we've been calling CyFx3BootUsbLPMDisable during set configuration.

I've attached a zip file containing the logs generated by the USB3CV tool.

Thanks,
Michael

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

Hi AlisAsgar,

I noticed that the descriptor tests that run after LPM L1 test also fail, but they only fail if the LPM L1 test is run. This appears to be caused by the FX3 entering a state where it does not respond to bus transactions. I tried the compliance test with the Fx3BootAppGcc firmware that Cypress provides running on a CYUSB3KIT-003 and it too fails the same tests. Please see the attached log.

Does Cypress have a bootloader firmware that is known to pass compliance testing?

Thanks,
Michael

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

Hi AliAsgar,

 

I just realized I zipped the wrong log. The correct log for the CYUSB3KIT-003 is attached this time.

Thanks,
Michael

0 Likes

Hi Michael,

The Fx3BootAppGcc default firmware passed the USB 3 CV test on our PC.

Hence, as I said before, the issue is very particular to the Asmedia host.

Could you let us know if the USB 3CV test is failing with the Application firmware as well?
If yes, could you use CyU3PUsbInitEventLog API and share with the us the logs. Please refer to USBBulkSrcSink firmware for implementation of this API.

The USB 3 U1 and U2 tests are failing due to the CyU3PBootUsbLpmDisable API. Could you check if the USB 3 tests (U1, U2) fail for default Fx3BootAppGcc firmware as well

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

I ran the Chapter 9 Tests[USB 3 Gen X devices] on the CYUSB3KIT-003 board while the FX3 was running the Fx3BootAppGCC firmware and found that it passes all of the tests (including U1, U2 tests) and only fails the device descriptor tests because they expect bcdUSB to be 0x0320 instead of 0x0310.

Our board running our custom firmware passes the same tests, with the exception being the TD 9.23 Reset Device Test. That test fails on our board running our custom firmware. That test also fails on the CYUSB3KIT-003 when running our custom firmware but I have no idea why. Do you know what might cause the TD 9.23 Reset Device Test to fail? This is what the log says:

TD 9.23 Reset Device Test - Device State Default
Failed
INFO
Start time: Aug 03, 2022 - 09:58:52
INFO
Device is operating at SuperSpeed.
INFO
Device is operating at SuperSpeed.
INFO
Changing device states from configured to default.
INFO
Set Configuration request succeeded for configuration value : 0.
INFO
Get Configuration request succeeded. Configuration value = 0x00.
INFO
Changed configuration to 0x00.
INFO
Initialized the device to the Default state.
INFO
USB Version number of device: 3.10
INFO
 
INFO
Disabling SuperSpeed Port
INFO
Device should connect on port at High Speed.
INFO
Port 4 Connect bit set
INFO
Port 4 Resetting device because enable bit was not set
INFO
Port 4 Both Connect and Enable bits set.
INFO
Device is connected on 2.0 port
INFO
Issuing GetDescriptor
INFO
Enabling SuperSpeed Port
INFO
Enabling SuperSpeed Port by setting link state to Rx.Detect
INFO
Resetting 2.0 Port so device will re-connect at SuperSpeed
FAIL
Did not detect connect on SuperSpeed port
FAIL
Device connected at High Speed, expected SuperSpeed or higher
INFO
Device re-enumerated and set to configuration index 0 (configuration value 1).
INFO
Stop time: Aug 03, 2022 - 09:59:01
INFO
Duration: 9 seconds.
INFO
Stopping Test [ TD 9.23 Reset Device Test - Device State Default: Number of: Fails (2); Aborts (0); Warnings (0) ]

 

I'll look into running the same tests on application firmware as well and get back to you.

Thanks,
Michael

 

0 Likes

Hi AliAsgar,

I ran the Chapter 9 Tests[USB 3 Gen X devices] on our application firmware and found that it passes the majority of the tests, but fails the device descriptor ones due to bcdUSB being 0x0310 and it fails the TD 9.24 U1 U2 Test. I added the USB log that you requested. This is the output that results from running test TD 9.24 U1 U2:

USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0xAE
USB Event Log: 0x50
USB Event Log: 0x40
USB Event Log: 0x41
USB Event Log: 0x51
USB Event Log: 0x12
USB Event Log: 0x42
USB Event Log: 0x25
USB Event Log: 0x26
USB Event Log: 0x17

Thanks,
Michael

0 Likes

Hi Michael,

Sorry, if you misunderstood me.
But could you perform the Chapter 9 tests for USB 2 devices in the USB3 CV tool for your application firmware and let us know if the compliance tests for LPM-L1 suspend resume issue are failing for the application firmware as well?
Try both by setting the BESL supported bit as 0 and 1.

This information will help us to concentrate either only on bootloader or on both the bootloader and application firmware.

Meanwhile we are in the process of getting the NDA signed, which will help us debug the issue faster.

Best Regards,
AliAsgar

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

Hi AliAsgar,

I performed the Chapter 9 tests for USB 2 devices with our application firmware on the Asmedia 3.1 host controller and found that the LPM-L1 suspend test fails. I've attached a zip file containing the logs from the test as well as the UART output.

Thanks,
Michael

0 Likes

Hi Michael, 

I see that in the .ld file, code area for the bootloader is 28KB, but your bootloader firmware .img file is 32KB. Hence, eclipse is showing memory overflow error. Could you let me know how were you able to program the 32KB. .img file to the FX3?

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

Sorry I didn't see your reply. The code section is 28KB with 4KB for data. On our board we have a 32KB EEPROM and have reserved the last 1KB for configuration data. I wrote a custom application to convert the elf to img. This application takes the elf data and puts it at the beginning of the img file, then pads to address 31744 and then places the initial configuration data that's parsed from a configuration file or passed in as a parameter to the application creating the image file.  As long as you set optimization to -O3 and the build mode to release mode the code area isn't overflowed.

Were you able to identify anything in our firmware source code that would cause control transfers to fail after device suspend and resume?

Thanks,
Michael

0 Likes

Hi Michael,

We have not yet found any issues with your custom bootloader firmware.

I am discussing this issue internally and we will try to find a workaround.

Meanwhile could you let us know if fx3bootappgcc firmware is failing the Chapter 9 tests for USB 2 devices.
Note that: BESL timing parameters should be non zero in the USB 2 capability descriptor and Asmedia AS3142 is the USB host controller used.

Best Regards,
AliAsgar

0 Likes