Same config SetConfig is currently not properly handled and stale toggle bits lead to weird transfers until USB resyncs because the asf4 code itself does not properly handle the toggle bit.
- USB 2.0 §9.4.5 states that ClearFeature(ENDPOINT_HALT) unconditionally resets the data toggle to DATA0 - USB 2.0 §9.1.1.5 demands toggle reset even when the same config/interface is selected
The old code was only doing a proper reset upon receiving a bus reset, but the actual state reset path outlined in the spec is the set config command. The easy fix here is to split the existing reset code which already does everything we need into two parts for the actual usb reset and SetConfig.
The current halt clear code only resets DTGL if the endpoint is actually halted and a fix is a bit more complicated. _usb_d_dev_ep_stall_clr() is also called from the SETUP-packet cleanup path in hal_usb_device.c _usb_d_dev_ep_stall(ep, USB_EP_STALL_CLR); _usb_d_dev_ep_stall(ep | USB_EP_DIR, USB_EP_STALL_CLR);
This runs on every SETUP packet as defensive cleanup of any leftover stall from a previous failed transfer. That might be why the asf4 usb code is wrong, because a toggle reset here breaks SETUP.
So the unconditional DTGL reset for halt clearing must therefore happen in _usb_d_ep_halt_clr itself, which is only reached via the ClearFeature host request (usbdc_clear_ftr_req -> usb_d_ep_halt(HALT_CLR)), using a small HPL helper function.
