高速时USB3300 RXCMD看起来很奇怪

嗨，所有（仍然无法连接图像……）我目前正在实施一个基于FGPA的USB高速控制器使用一个UB3300（WaveSeHARE模块）。当使用全速（12Mbit）时，一切看起来都很好，但是在高速情况下看起来很奇怪。3300模块使用外部复位线硬复位，然后使用函数控制寄存器逻辑复位，暂停被禁用，OTG寄存器被清除，所有其他位都设置为外围全速。在主机连接时，执行通常的高速协商（并且我有CON）。使用范围，我可以清楚地看到重置，外围啁啾，主机啁啾和终端启用），我们按照ULPI规范配置它。当我收到第一个DATA0包后，安装包，一些奇怪的事情发生（见附图）。我使用FPGA本身来捕获所有的ULPI信号。http://www. alvi.com /ZPUI…0xrxCMdOdditiS1.jpg.DATA0数据包是LIGHT中的10字节（GETSA描述符），但是只有9个是由PHY发送的（LASY CRC字节丢失）。在第一个CRC字节（0xDD）之后，NXT行下降，此时我期望接收RXCMD，但是我得到所有零，这根本没有意义。另外，我好像收到了三个。没有来自PHY的RX错误指示。如果我忽略了包长度，CRC检查并继续进行，这一切似乎都很顺利。然后我从主机中获得In包，并且我可以在没有任何问题的情况下将它发送出去：http://wwwalAlv.com /ZPUI…GES/UB33xIn nAk.jpg2包似乎很受欢迎，有些人不这样做——我有时得到（10字节请求）7字节，8字节，9字节。我似乎从来没有收到任何RxRebug指示。如果我确实有CRC检查，我完全无法枚举该设备在HS -它确实在FS枚举完美，同一PHY。任何线索可能会发生什么？阿尔维



      以下为原文

    Hi all,
(still unable to link images...)
I am currently implementing a FGPA-based USB High-Speed controller using an USB3300 (Waveshare module).

Everything seems to work well when using Full-Speed (12Mbit), but things are looking weird at High-Speed.


Just to give a glimpse of the initial setup, the USB3300 module is hard-reset using the external reset line, then logically reset using the Function Control register, Suspend is disabled, OTG register is cleared and all other bits are set up for Peripheral Full-Speed.
Upon host connection, the usual High-Speed negotiation is performed (and I have confirmed it using a scope, I can see clearly the reset, Peripheral Chirp, Host Chirp and the terminators enabling) and we configure it as per ULPI spec.


When I receive the first DATA0 packet, after the SETUP packet, something odd happens (see attached figure). I have used the FPGA itself to capture all ULPI signals.

http://www.alvie.com/zpui...00_rxcmd_oddities1.jpg

The DATA0 packet is 10 bytes in lenght (GET_DESCRIPTOR), but only 9 are sent by the PHY (the lasy CRC byte is missing). After the 1st CRC byte (0xDD), the NXT line goes down, and at this point I'd expect to receive an RXCMD, but I get all zeroes, which do not make sense at all. Plus, I seem to receive three of them. There is no RXERROR indication coming from the PHY.

If I ignore the packet lenght, the CRC check and proceed, it all seems to go well - I then get the IN packet from the host, and I can NAK it without any issue:

http://www.alvie.com/zpui...ges/u***3300_in_nak.jpg

Some packets seem to be well received, some others do not - I sometimes get (for a 10-byte request) 7 bytes, 8 bytes, 9 bytes. I never seem to receive any RXERROR indication at all. If I do have the CRC checks in place, I am completely unable to enumerate the device at HS - It does enumerate perfectly at FS, with the same PHY.

Any clues about what might be going on ?

Alvie