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.
I tested this in Host Hid Mouse Keyboard example as you suggested and I have the same behaviour occurs when I add your code in host_keyboard.c. However, I did the same using mouse and I didn’t see any issue.
The device may be sending the stall after a connection timeout in order to keep the connection with the host.
"The device may be sending the stall after a connection timeout in order to keep the connection with the host."
With all due respect, you are not making any sense. How can the device send a STALL w/o the USB trace capturing it ?
Once the BP hits it means that a STALL has occurred, yet the trace does not exhibit any STALL but NAK from the device's interrupt EP. Therefore there is a bug either in the USB stack or the MCU host controller itself.