SDK 2.5.0 USB0 host ctrl:INT IN false positive on STALL

cancel
Showing results for 
Search instead for 
Did you mean: 

SDK 2.5.0 USB0 host ctrl:INT IN false positive on STALL

463 Views
belmontbob59
Contributor IV

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.

 

pastedImage_5.png

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.

Please advise.

Labels (3)
0 Kudos
5 Replies

275 Views
FelipeGarcia
NXP TechSupport
NXP TechSupport

Hi Bob,

 

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.

 

Best regards,

Felipe

0 Kudos

276 Views
belmontbob59
Contributor IV

"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.

Please advise. 

0 Kudos

276 Views
FelipeGarcia
NXP TechSupport
NXP TechSupport

Hi Bob,

Sorry for the misunderstanding.

I will advise your issues.

Regards,

Felipe

0 Kudos

276 Views
belmontbob59
Contributor IV

Any update on this matter?

0 Kudos

276 Views
FelipeGarcia
NXP TechSupport
NXP TechSupport

Hi Bob,

 

I have sent your comments to the USB team. Thanks again for reporting this issues.

 

Regards,

Felipe

0 Kudos