Problems with OUT reports on USB HID

[Laurence]

Hi,

I'm using the NRF52840 PDK version:

PCA10056

0.11.0

2018.3

With SDK version 15.2

I've been trying to develop an application based on the HID Generic example and am seeing some strange behaviours on the USB HID OUT endpoint.

I try to obtain the data in the APP_USBD_HID_USER_EVT_OUT_REPORT_READY event, at which point I use app_usbd_hid_generic_out_report_get to retrieve the data for processing in my main loop.

After more tracing and debugging, I've found that the hid_generic_ep_transfer_out handler is called when the OUT endpoint is busy.  When this happens the app_usbd_ep_transfer fails and app_usbd proceeds to stall the endpoint (in app_usbd_event_execute).

How can I avoid this situation?

Thanks,

Larry

[Kenneth]

Hi Larry,

Do you have the possibility to order yourself a new nRF52840-DK, the preview kit you have contains engineering samples that have not gone through production test, and may thereby contain issues. What SDK example are you using for this test?

Best regards,
Kenneth

[Laurence]

I'm using some code that I modified based on a sample.
I can try to get a sample working as out of the box provided I can get the same test data to send to it.

I can order another PDK.  I originally had 4 with engineering Rev A chips on it.  Then I ordered another because of USB issues and that one I believe is Rev B.  Are you saying that there are PDKs available which production chips on them?

I also have some dongles (a few Nordic nRF52840 Dongles and some from MakerDiary nrf52840-mdk-usb-dongle).
I'm hoping to get the application running on those so I can see if the problem still exists because I believe that they are using production chips.

Larry

I have some more information.  The issue only seems to occur when rapid HID frames are sent in succession.
The test tool I'm using is from the FIDO Alliance.   One of the tests requires the device to pass a long echo, which can span multiple frames (a frame is 64 bytes - header information).
So when I reduce my tests so that the message is always 64 bytes or less and I don't see any problems.

Also, the SDK example I started from is the usbd_hid_generic example.
The issue is with using that example is that it only has one IN endpoint.  I had to add another OUT endpoint for my application.  It will take a bit of effort to try to get it working.

Both endpoints are of size 64 bytes.

Larry

[Laurence]

Here are the HIDTest utility source files and Makefile.NordicTest.zip

[Laurence]

Here is the ble_app_blinky project for SES.

Larry4130.ble_app_blinky.zip

[Laurence]

Hi Kenneth,

Do you have any status updates for me?

Thanks,

Larry

[Laurence]

I've uploaded an example project and command line utility a few days ago.  Did you receive it, and have you had any success reproducing the issue?

Thanks,

Larry

[Kenneth]

Hi Larry,

We were able to reproduce this issue with the code provided. Indeed looks like HID OUT reports sometimes STALL and fail the test. We don't have time to investigate this at the moment, but we may look into it for future.

As it is today the OUT report size is limited to 64bytes in any case by the app_usbd_hid.c, see endpoint_out_event_handler():
ASSERT(p_hinst->p_rep_buffer_out->size <= NRF_DRV_USBD_EPSIZE); 

Best regards,
Kenneth

[Laurence]

Hi Kenneth,

I understand about the OUT report size and we are not exceeding the limit of 64 bytes.
The FIDO U2F specification actually breaks large messages into frames of exactly 64 bytes with INIT and continuation frames.  So this cannot the cause of the issue, right?

When will we know if/when you plan to investigate further as this is a critical function of our product.

Thanks,

Larry

[Kenneth]

The issue can be caused by a problem in the USB stack or your application – we didn’t have much time to look at it. If you are able to narrow down it's in the USB stack we likely can prioritize the issue.

Best regards,
Kenneth

[Laurence]

Hi Kenneth,

I'm fairly certain that is in the USB stack as I have reproduced this in several manifestations of code.  The delivery made to you was made simple so that it could illustrate the problem with minimal application code added to on an out-of-box example. 
I don't know how else I can narrow it down further.

Best Regards,

Larry

[Kenneth]

Unfortunately I don't have any update for you, no one have been assigned yet. I am wondering if you have done any progress on your side the last 2 weeks?

Best regards,
Kenneth

[Laurence]

Hi Kenneth,

I don't have any more progress on my side.  The best I have been able to do is to put delays into the host test application between HID frames, but that is just so I can move development forward.  It can't be a long term solution.

Best Regards,

Larry