EP0 stall isnotthe same as Interrupt IN Halt. USB 2.0 treats control-endpoint stall as aprotocol stallfor thecurrent control transfer. Bulk/interrupt Halt is afunctional stallthat stays untilCLEAR_FEATURE(ENDPOINT_HALT).Device side (this SDK)When Chapter 9 or a class request returnskStatus_USB_InvalidRequest, usb_device_ch9.c stalls the control pipe:if (kStatus_USB_InvalidRequest error) { /* Stall the control pipe when the request is unsupported. */ status USB_DeviceStallEndpoint(handle, (uint8_t)USB_CONTROL_ENDPOINT);Typical causes:Unsupported standard request (example comment: SYNCH_FRAME until a device implements it)Unsupported CDC class request on the communications interfaceWrong state (request only valid when configured)Optional: hostSET_FEATURE(ENDPOINT_HALT)withwIndex EP0 (0x00or0x80) — Ch9 also callsUSB_DeviceStallEndpointfor the control endpointWhat the bus does:Host’s current SETUP/data/status sequence gets STALL.Thenext SETUPis accepted. Controller hardware (EHCI deviceEPSETUPSR/ tripwire) delivers a new setup packet; firmware starts a new control transfer.Host does not needCLEAR_FEATUREto unstall EP0after a protocol stall.HostSET_FEATUREHalt on EP0 is allowed by USB but unusual; a later SETUP orCLEAR_FEATUREon EP0 still recovers control.CDC ACM class doesnotstall EP0 because UART status changed. That uses Interrupt INSERIAL_STATE. Unsupportedcontrolrequests stallEP0 only. Interrupt IN and bulk keep NAK/DATA as before.Host side (this SDK)EHCI reports STALL on thecontrol pipethe same way as other pipes:kStatus_USB_TransferStallin usb_host_ehci.c.Enumeration(usb_host_devices.cUSB_HostEnumerationTransferCallback):Stall → retry thesamecontrol transfer whilestallRetriesremain (USB_HOST_CONFIG_ENUMERATION_MAX_STALL_RETRIES, typically1in examples).Retries exhausted → restart enumeration from get-descriptor-8 (enumRetries).Those also exhausted → enumerationfails(TransferFailed/ device not usable).CDC class control(USB_HostCdcControl, line coding, encapsulated command,SET_INTERFACEif alt ! 0):Completes inUSB_HostCdcControlPipeCallback.NoUSB_HostCdcClearHalt(auto-clear-stall is only for bulk/interrupt).App callback getskStatus_USB_TransferStall. Thatone request failed. The nextUSB_HostSendSetupis a new SETUP, so EP0 protocol stall is already gone.CLEAR_FEATURE inUSB_HostCdcClearHaltis itself anEP0transfer. If EP0 is protocol-stalled from apreviousrequest, the next SETUP (including CLEAR_FEATURE for some other endpoint) still works. If CLEAR_FEATURE targets thewrongendpoint (CDC interrupt usesDIR_OUT), EP0 succeeds and Interrupt IN stays Halted — that is not an EP0 stall.Compared with Interrupt IN HaltEP0 protocol stallInterrupt IN HaltTypical causeInvalid/unsupportedcontrolrequestSET_FEATUREHalt or device functional stallDurationCurrent control transfer onlyUntil CLEAR_FEATURE / set config / resetHost recoverySend next SETUPCLEAR_FEATURE withIN | epCDC auto-clearNoneAttempted (interrupt path uses wrong OUT bit)Payload pipesUnaffectedInterrupt IN STALLs until Halt clearedPractical outcomeIf EP0 stalls once (unsupported GET/SET, bad CDC control):That control transfer fails (kStatus_USB_TransferStall).Bulk and interrupt pipes arenothalted by that stall.The next control request (including CLEAR_FEATURE for another EP) should run.During enum, a few stalls are retried; persistent EP0 stall fails attach.IfeverySETUP stalls, the device is broken or not addressed; enumeration fails. That is not recovered by CLEAR_FEATURE on Interrupt IN.