OpenCores
Issue List
bit-stuffing problem on last packet bit #1
Closed alvieboy opened this issue about 8 years ago
alvieboy commented about 8 years ago

I am using this USB 1.1 PHY for an open-source project, and I ran into an issue. This only seems to happen when I use an USB HUB I have (a chinese one, have not tested with other hubs though). It works OK when I connect to the host directly.

I have sent an email to Rudolf Usselmann too, just to let him know since the issue is also present in the Verilog code.

I'm using the PHY as an FS Device, using a simple external USB transceiver.

So, what is happening is I have an IN/DATA0 transaction that never gets acknowledged by the host. This causes retransmission of the same DATA0 ad-eternum.

Looking at the concrete data being sent, the only think that makes me believe it's causing this relates to CRC transmission ending with (binary) "00111111". I suspect HUB is somehow expecting a stuff bit before EOP, and hence not reading the CRC correctly.

Section 7.1.9 of USB 2.0 standard states: "If required by the bit stuffing rules, a zero bit will be inserted even if it is the last bit before the end-of-packet (EOP) signal".

This is also part of the USB certification Peripheral Silicon Checklist (http://www.usb.org/developers/compliance/check_list/), B6, section 3.1: "Is bit stuffing performed even if the stuffed bit follows the last bit of a packet".

Here's my fix (basically delaying EOP by one FS cycle):

--- usb_tx_phy.vhd +++ usb_tx_phy.vhd @@ -332,7 +332,9 @@ begin elsif rising_edge(clk) then if fs_ce ='1' then append_eop_sync1 <= append_eop;

  •    append_eop_sync2 <= append_eop_sync1;
  •    if stuff='0' then
  •      append_eop_sync2 <= append_eop_sync1;
  •    end if;
       append_eop_sync3 <= append_eop_sync2 or -- Make sure always 2 bit wide
                           (append_eop_sync3 and not append_eop_sync4);
       append_eop_sync4 <= append_eop_sync3;
alvieboy commented about 8 years ago

Patch looks unreadeable. Let's try again:

<pre> --- usb_tx_phy.vhd +++ usb_tx_phy.vhd @@ -332,7 +332,9 @@ begin elsif rising_edge(clk) then if fs_ce ='1' then append_eop_sync1 <= append_eop; - append_eop_sync2 <= append_eop_sync1; + if stuff='0' then + append_eop_sync2 <= append_eop_sync1; + end if; append_eop_sync3 <= append_eop_sync2 or -- Make sure always 2 bit wide (append_eop_sync3 and not append_eop_sync4); append_eop_sync4 <= append_eop_sync3; </pre>
alvieboy commented about 8 years ago
<pre> --- usb_tx_phy.vhd +++ usb_tx_phy.vhd @@ -332,7 +332,9 @@ begin elsif rising_edge(clk) then if fs_ce ='1' then append_eop_sync1 &lt;= append_eop; - append_eop_sync2 &lt;= append_eop_sync1; + if stuff='0' then + append_eop_sync2 &lt;= append_eop_sync1; + end if; append_eop_sync3 &lt;= append_eop_sync2 or -- Make sure always 2 bit wide (append_eop_sync3 and not append_eop_sync4); append_eop_sync4 &lt;= append_eop_sync3; </pre>
M_artin commented about 8 years ago

I would do some simulation on this issue - can you provide me the failing DATA0 content that results in the "00111111" CRC ?? In any case I can only fix the VHDL part, not the orginal Verilog stuff since I am not the owner and I don't have a Verilog simulation environment...

M_artin commented almost 8 years ago

This issue could be verified in simulation and has been solved with an update to the usb_tx_phy.vhdl file. MN

M_artin closed this almost 8 years ago

Assignee
No one
Labels
Bug