Module usb_rx_state 

L1/L2: USB Ethernet 受信チャネルの状態遷移（純粋ロジック）。

なぜこのモジュールがあるか

OSI 下位層（L1/L2）だけ単体試験が無いまま、L4(TCP)/L7(CSS) を延々と 追いかけていた。実測の結果、実際の障害はここにあった:

[NETBENCH][RES] before=2 rx_frames=14 ...
[NETBENCH][RES] before=5 rx_frames=14   ← 1 回目以降 1 フレームも増えない

1 回目の通信の後、USB Ethernet が受信を完全に停止する。 DNS タイムアウト・TCP 接続タイムアウト・受信打ち切りは すべてこの単一症状の現れだった。

元の実装の問題

if RX_IN_FLIGHT {
    if (hcchar & CHENA) != 0 { return; }   // ← break ではなく return
    ...

チャネルが有効なままだとポーリング関数全体を return する。 CHENA が落ちない状態に陥ると受信が永久に停止し、 しかも ints のチェックに到達しないのでエラーログすら出ない （実測でも異常停止カウンタは 0 件だった）。

本モジュールはこの判断をレジスタ値から純粋に導出し、単体試験で固定する。

Enums

RxAction

受信ポーリングが次に取るべき動作。

Constants

HARVEST_BUDGET

1 回のポーリングで回収できるフレーム数の上限。

HCCHAR_CHENA

HCCHAR のチャネル有効ビット。

HCINT_BBL_ERR

HCINT_DATA_TGL_ERR

HCINT_FRM_OVRUN

HCINT_NAK

NAK。Bulk IN では「今は送るデータが無い」という正常な応答。 デバイスは次のトークンを待っているので、チャネルを再アームすればよい。

HCINT_STALL

HCINT_XACT_ERR

HCINT_XFER_COMPL

DWC2 の HCINT ビット（受信で参照するもの）。

MAX_IN_FLIGHT_POLLS

タイムアウト判定に使う、転送中のまま許容する最大ポーリング回数。 これを超えたら CHENA が落ちなくなったとみなして強制的に再アームする。

Functions

decide

受信チャネルの次の動作を決める。

describe_halt

HCINT からエラー要因を人が読める形にする（診断ログ用）。

frames_per_second

ポーリング 1 回あたりの理論最大フレーム数を求める。

received_len

受信バイト数を求める。rx_len は要求長、hctsiz_remaining は残り転送量。