The USB stack invokes the transfer callback status kStatus_USB_TransferStall when the device does not actually answer IN token with STALL at transport. This causes our application to fail and to enter fault recovery when it should not.
I reproduced this issue with SDK example keyboard2mouse_bm; So I do believe this is a bug in the SDK.
I added code (in blue below) to host_keyboard.c::USB_HostHidInCallBack() to break into the debugger when the cbf is invoked with kStatus_USB_TransferStall. I run a USB analyzer concurrently with the repro running. I stopped the trace as soon as the BP hits. It usually takes a couple of minutes for the BP to hit; it re-occurs periodically after that (~minutes) once you resume execution. I tried with different brands of Keyboard and the repro always hit the BP.
Please see attached trace AcquisitionFile0000.ufo: when the BP is hit: the device only sent NAK tokens on interrupt in but the USB stack does report a STALL.