Re-opening — live siTD/EHCI evidence: M484 EHCI performs an illegal complete-split on FS isochronous OUT and never clears Active

[jeromeDms]

Dear Nuvoton team,

We are re-opening this issue. In our closing comment we attributed the problem to the USB2517 hub, because a generic UGREEN hub worked with the unmodified BSP. Since then we instrumented the running M484 with a J-Link probe and read the EHCI operational registers and the siTD descriptors directly in RAM while the controller runs (non-halting background reads; struct offsets resolved from DWARF). This gives new, direct evidence that the root cause is the M484 EHCI iso-OUT state machine itself — independent of the hub and independent of any TT error response.

Setup: M484 + on-board USB2517 hub + ESI U46DJ (FS UAC, 6-ch 16-bit 44.1 kHz OUT ≈ 528 B/frame, scnt = 3). UsbHostLib BSP, original code path.

The EHCI controller is healthy throughout: UCMDR = 0x00010031 (Run = 1, Periodic + Async schedules enabled), USTSR = 0x0000E00C (HCHalted = 0, no Host System Error, periodic + async active), FRINDEX advancing. So this is not a controller stall — only the OUT siTD is stuck.

1. Single-TT (hub HS, default):
   OUT siTD: Sched S-mask = 0x07 (microframes 0,1,2), C-mask = 0x00.
   StsCtrl = 0x015401C2 → Active | ERR | SplitXstate = DoComplete (status bit 1).
   xferCount 540 → 340: the first 188-byte start-split was issued and accepted, and the transaction position advanced Begin → Mid. The siTD then stays Active indefinitely (DoComplete) → the endpoint is permanently wedged. The IN siTD on the same endpoint (multi-microframe split IN) is healthy (Active only, no ERR, no DoComplete).

2. Multi-TT (we issued SET_INTERFACE(interface = 0, alternate = 1) on the hub; return = USBH_OK, verified live):
   With the OUT S-mask kept valid (0x07), StsCtrl = 0x82 → Active | SplitXstate = DoComplete, with NO ERR bit. The USB2517 TT returns no error in Multi-TT, yet the M484 still hangs the siTD in DoComplete and never clears Active. (The IN siTD in Multi-TT completes with 0 bytes received — xferCount unchanged.)

3. We also tried giving the OUT siTD a C-mask, so the controller's complete-split phase has target microframes. The controller then advances its complete-split progress (cPgMsk changes), but StsCtrl status stays 0x82 — Active is still never cleared.

Summary: for any FS isochronous OUT with payload > 188 bytes/frame (T-Count > 1, TP != All), the M484 EHCI drives the OUT siTD into SplitXstate = DoComplete (a state reserved for the IN direction per EHCI 1.0 §4.12.5) with C-mask = 0, and never clears the Active bit. This holds in Single-TT and Multi-TT, with or without a TT error response, and even when we supply a C-mask. The fault is in the M484 EHCI OUT split-iso state machine, not in the hub. (A generic UGREEN hub "works" only because its TT happens to satisfy the spurious complete-split; the USB2517 does not.)

Questions:

Can you confirm the M480/M484 EHCI performs a complete-split (SplitXstate = DoComplete) on a multi-start-split FS isochronous OUT siTD, and that it does not clear Active when the TT does not return a complete-split response?

Is there any silicon errata, undocumented register, or BSP change that would (a) prevent the complete-split on iso OUT, or (b) make the controller retire the iso-OUT siTD instead of hanging on Active?

If this is a hard silicon limitation, please confirm so we can finalize a hardware migration. We would also appreciate a recommendation for a Nuvoton USB-Host-capable MCU that correctly handles FS isochronous OUT above 188 bytes/frame.
We can share the full live register/siTD dumps and our debug tooling on request.
Thank you.

[ychuang3]

To better understand the failure mechanism, could you provide a USB protocol trace captured around the failing transfer?

If available, a hardware USB analyzer trace (e.g. LeCroy) would be particularly helpful, as it allows us to observe the split transaction sequence between the EHCI controller and the Hub TT, including SSPLIT/CSPLIT behavior.

If a hardware analyzer is not available, a USBPcap/Wireshark capture from the Windows host may still help us correlate the failure timing and transfer status.

[jeromeDms]

Hi,

Instead of an external bus sniff, we captured evidence directly at the EHCI descriptor level on the running MCU (live reads of the siTD registers via SWD), which shows the exact hardware split-transaction state. Below are our observations on M480/M484 and a new one on M460, plus a BSP scheduler issue we found and a fix.

1. Observed behavior on M480 / M484 — FS isochronous OUT > 188 B/frame behind a HS hub

With a full-speed UAC device behind a high-speed hub, an OUT iso payload requiring a multi-microframe start-split (scnt > 1, TP = Begin/Mid/End) leaves the OUT siTD stuck ACTIVE in the complete-split state:

siTD.StsCtrl status byte = 0x8A → ACTIVE | XactErr | SplitXState=DoComplete, and it never completes.
Since isochronous OUT has no complete-split phase, we did not expect the OUT siTD to sit in DoComplete.
We also tried a software workaround (N consecutive scnt=1 sub-siTDs, TP=Begin/Mid/End, in both Single-TT and Multi-TT modes); it also did not complete — any TP ≠ "All" showed the same pattern at single-microframe level (captured StsCtrl = 0x202, partial send).
To be clear, we are not asserting a root cause. We were simply unable to find any software/scheduling configuration that lets this complete on M480/M484 — the only reliably working case is a single start-split (TP=All, ≤188 B/frame). The cause could be in the host-controller/TT handling, in the BSP, or in our usage; we'd appreciate your analysis and can share the full siTD register logs.

2. New observation — M460 / M467 behaves differently

We ran the same firmware, same FS device, same HS hub, same bandwidth (OUT 528 B/frame, scnt=3) on a NuMaker-IoT-M467. There, the OUT siTDs complete normally (StsCtrl status byte = 0x00) — we did not see the stuck DoComplete. We don't know whether this difference comes from the silicon, the BSP version, or our configuration. If you can tell us whether M460 is expected to handle multi-microframe split-iso OUT, that would help us a lot.

3. A separate issue we found in UsbHostLib (BSP) — periodic split scheduler

Independently of the above, getting clean full-duplex FS audio on M460 was blocked by two defects in Library/UsbHostLib/src_core/ehci_iso.c (BSP-level):

ehci_sitd_adjust_schedule() resolves micro-frame conflicts by shifting the full 16-bit Sched (S-mask in bits 0–7, C-mask in bits 8–15) as one unit. This can push the OUT S-mask out of bits 0–7 (e.g. to 0x8000) → an siTD with no valid start-split micro-frame → permanently ACTIVE, never transmitted. It can also drop C-mask bits shifted past bit 15.
write_sitd_info() sets the IN C-mask width to (1 << (scnt + 2)) - 1 (scnt+2 micro-frames). For a 416-byte IN (scnt=3) that is 5 C-mask micro-frames; with a 3-µframe OUT this needs 1+5+3 = 9 > 8 micro-frames on a single TT → unavoidable conflicts for full-duplex FS audio.
Fix we applied (works on M460/M467):

/* write_sitd_info(): narrow IN C-mask to its real width */

• sitd->Sched = (1 << (scnt + 2)) - 1;

• sitd->Sched = (1 << scnt) - 1;

/* ehci_sitd_adjust_schedule(): shift S-mask (bits 0-7) and C-mask (bits 8-15)
SEPARATELY within their own byte, bounded, from the original masks (not cumulative): /
uint32_t s0 = sitd->Sched & 0xFF, c0 = (sitd->Sched >> 8) & 0xFF, um = uframe_mask & 0xFF;
for (int k = 0; k < 8; k++) {
uint32_t sm = s0 << k, cm = c0 << k;
if ((sm & ~0xFFu) || (cm & ~0xFFu)) break; / keep masks inside their byte /
if (((sm | cm) & um) == 0) { / first conflict-free placement */
sitd->Sched = (sitd->Sched & 0xFFFF0000) | sm | (cm << 8);
break;
}
}
4. Result

With the M460 + this scheduler fix, the FS device plays clean full-duplex audio through a HS hub (OUT 528 B/frame + IN 416 B/frame), with valid, disjoint S/C-masks and OUT siTDs completing normally.

Could you please (a) let us know whether M460 is expected to handle multi-microframe split-iso OUT, and (b) review the two ehci_iso.c scheduler points above? We're happy to provide the raw siTD dumps for both MCUs and the full patch.

Thanks,
Jerome

[ychuang3]

Thank you for the additional information and the detailed analysis.

Based on our internal review, the EHCI implementation used in M460/M467 is not identical to that used in M480/M484. The M460/M467 EHCI controller includes updates in the split isochronous transaction handling path, particularly in the internal state-management logic associated with siTD processing.

As a result, behavior may differ between the two device families in certain multi-microframe split-isochronous transfer scenarios.

At present, we are still reviewing the interaction between the controller implementation and the BSP scheduling logic, and therefore are not yet in a position to determine whether the observed M480/M484 behavior is caused by controller implementation details, scheduling configuration, or a combination of both.

For applications requiring sustained multi-microframe split-isochronous audio transfers through a high-speed hub, M460/M467 would be the recommended platform, as it has been validated with the transfer scenario described in your test environment.