This note collects the information about USB CDC host APIs, the notification endpoint, when a halt/stall happens, why it can stick, and how this SDK (MCUXpresso 2.12.1) handles it.
1. What “halt” means here
On USB 2.0, a functional stall on a bulk/interrupt endpoint is the Halt feature. The device returns STALL on every token to that endpoint until Halt is cleared.
On the NXP host, that shows up as kStatus_USB_TransferStall (EHCI Halted bit 0x40, without other QTD error bits 0x3E). Those other bits are not Halt (babble, transaction error, etc. → kStatus_USB_TransferFailed).
| Device behavior | Host sees | Meaning |
|---|---|---|
NAK Interrupt IN | Transfer stays pending | No notification yet (normal idle) |
STALL Interrupt IN |
| Endpoint halted |
STALL on EP0 | Control transfer stall | Bad/unsupported setup, not Interrupt IN Halt |
Halt is not “no SerialState / no RNDIS response.” Idle Interrupt IN is NAK.
Clear Halt with CLEAR_FEATURE(ENDPOINT_HALT) and wIndex = endpoint number | IN (bit 7). Also cleared by SET_CONFIGURATION / SET_INTERFACE / bus reset.
2. CDC pipes (where Halt can apply)
A CDC function has two interfaces:
| Interface | Endpoints | Role |
|---|---|---|
Communications ( | Default control + interrupt IN | Class requests + notifications |
Data ( |