[FX3] Known issues with AMD (Ryzen A320 chipset, etc) host controllers?

[heanc_1330791]

Hi Cypress Superspeed USB Community,

We are running into trouble using our FX3 based USB Peripheral on platforms using AMD USB Host Controllers (A320 chipset Win10 x64):

Firmware Download is way slower (about 10 seconds) than on other systems in general. Tested using our custom application and Cypress Control Center and using our custom board or the Superspeed Explorer.

If only the USB2.0 signals (custom hardware using USB2.0 only on USB 2.0/3.0 port or Explorer on USB 2.0 port) are connected the device is not responding correctly after programming the firmware: Trying to re-enumerate our custom application gets random garbage VID/PIDs reported back from the CyAPI (alltough it shows up correctly in Device Manager). Even examples like the UVC example wont work at all on 2.0 ports of the Ryzen machine.

If a USB hub is connected in between our custom system(HW,SW) works, but with a lot more failed Bulk transfers than on other machines.

All issues above are only observed on systems using AMD Host Controllers, while many other Intel based machines across various Windows versions work fine.

Are there any known issues and work around for AMD Host Controllers I was unable to find?

[SrinathS_16]

Hello,

FX3 was tested on AMD host controllers and were found to be working fine. Can you please let me know if this issue is particular to this chipset or is it seen across all PCs with AMD host controllers? Kindly, capture the USB traces (using Logic analyzer like LeCroy) during failure and share the same.

Best regards,

Srinath S

[heanc_1330791]

Hello Sinrath,

I don't have access to a logic analyzer at the moment. I was kind of hoping its a common issue with a workaround as it was easy to reproduce using example software and the evaluation board and was observable on all 4 Ryzen/Threadripper PCs we have in the office. The issues coming up if connected directly (slow firmware download, inoperable on USB2.0) are not that much of a problem for our product as it is connected through an isolated USB Hub. On the other hand the more unreliable bulk transfers are a big deal as it leads to a lot of dropped frames and reduced frame rate. If I use the ports on a PCI express USB Controller card on the same AMD machine all the issues are gone and it works as well as on the Intel machines we were developing on for years. It seems that at  least the particular AMD Host controllers I have tested so far don't play well with the FX3 and my hardware in particular.

Introducing heavy CPU load in the background (Prime95) does improve the reliability a little bit (as seen in https://community.cypress.com/thread/45839?start=0&tstart=0 for Intel processors). I am still in the dark on the actual problem on AMD Host Controllers. I can't rule out that it just handles large (~1.5MB) bulk transfers differently in the lower levels of the stack and this is causing my flow control control implementation on the device to act up.

I would like to keep this discussion open till I have gathered more information to ask further moe specific questions or find the issue.

Best regards,

Helmut

[SrinathS_16]

Hello Helmut,

- Since you have mentioned that you have got access to SuperSpeed Explorer Kit, can you please test using an example firmware provided by Cypress (along with FX3 SDK) and test it on the AMD host controller (Both USB 2.0 only and USB 3.0 operation). Test for the BULK transfers using the example firmware and Cypress driver.

- Capturing USB traces would provide more insight onto the issue that is happening. in case you do not have a hardware analyzer, please capture the traces using a software analyzer such as Wireshark (any case, a hardware analyzer would be better and would provide detailed information).

Best regards,

Srinath S

[heanc_1330791]

Hello Sinrath,

I have been working on improving the reliability of the Bulk transfers: First I found out that my flow control implementation was inadequate as I was only using a DMA Watermark flag output to throttle the FPGA sending the data. Some difference in behaviour of the AMD Host caused my complicated GPIF state machine to loose some input data from the FPGA.

I rebuild my existing logic to resemble the Slave FIFO Read example from John Hydes SuperSpeed DeviceDesign By Example. This solved the problem of dropped FPGA input data, but I am also appending some internal status data to the end of the Bulk transfer in a GPIF Callback by WrapUp -> fixed 1ms delay till DMA Channel is suspended -> GetBuffer -> append data -> CommitBuffer -> Resume

The fixed delay, while far from elegant, worked on other plattforms, but I've added in polling for AMD and saw it frequently takes up to 10ms till the DMA is supended. This may be affected by CPU power/sleep states, as I could not observe it with high CPU load.

So far I see that the bulk transfers seem to "stutter" more on AMD, especially on light CPU loads.

With the changes above I could get transfers working more reliably on the particular system I have been testing on. I will have to doublecheck on other machines.

I didn't investigate the other issue (device recognition/firmware download fails if connected directly) further till now, as it has lower priority.

Best regards,

Helmut

[SrinathS_16]

Hello Helmut,

- Is this issue similar to the one mentioned in the below document?

http://www.ids-imaging.com/frontend/files/AN_AB.1.0024_USB-BandwidthCurrentCPUs.pdf

- Is the issue completely eliminated when the CPU load is maintained high? You can check this with a dummy thread running in the application background.

Best regards,

Srinath S

[heanc_1330791 · Accepted solution]

Hello Sinrath,

The issue of occasionally having longer pauses than usual (at least for the last portion of the transfer) seems to be related to CPU load. It was obvious there because I used a fixed delay at first. Some shorter transmission hickups (which exposed my faulty flow control) seem to appear even with background load (just what I guessed from the system behaviour).

With corrected Flow Control and background load or flexible delay the communication seems to work reliable now. So the Sleep states were at least a part of the issue. The problem was quite specific to our application(~36MB/s over USB2.0 from GPIF and DMA Suspend to append CPU Data), but my observations may help someone else looking this thread up.

I am still curious about the device recognition/firmware download fail issues, as they are easier to reproduce with standard hard- and software, but it doesn't really affect our application in particular(isolated hub required anyway). I really have no idea what to do about it unless it turns out to be a wide spread issue to warrant a deep dive into driver code for AMD and/or Cypress.

Best regards,

Helmut

[SrinathS_16]

Hello Helmut,

- Are you loading the firmware onto the EEPROM or the FX3 RAM? In case you are loading the firmware onto the EEPROM/ Flash, the delay is expected.

- In case you are loading the firmware into the RAM and still see a delay, please test using the fwdownload_fx3 application that comes with the FX3 SDK.

- Also, please capture the USB traces if possible during this issue.

Best regards,

Srinath S