This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

USB BOS descriptor (vendor specific)

Hi,

I have tried to add support for BOS descriptor by appending a custom class generated from the Dummy example. The "main" class is the HID generic class, but with the NRF USBD driver not supporting vendor specific requests I want to hook onto events and process this in my own class.

I append my custom class and It enumerates fine and the BOS descriptor is read correctly. So far so good. And the code needed is minimal. But there is an upper limit to everything. The USBD driver now reports two interfaces being present and that causes Windows not to load the MS generic HID driver. Apparently the Windows generic HID driver expects one interface only (both Windows enumeration and my Ellisys USB Explorer reports that every is OK).

So, my question is: How can I add a custom class (to hook onto unhandled events), which sole purpose is to grab unhandled requests, without the USBD driver starts shouting about additional interfaces? I can't see how adding additional interfaces can be avoided. You can't set the feed_descriptors to NULL as you then get an assert. You can't omit the feed_descriptors entry from app_usbd_class_methods_t. Is there a smart way to do this?
You see, the idea is not the re-write the USBD but to use it as is, thereby making it easier to update to new versions of the SDK.

I just tried to clear the feed_descriptors function so that the only thing it does it to return false, and to copy the class to RAM and change the iface.cnt to 0. Then it works. But it just doesn't seem so neat to have to copy it to RAM. Maybe I could create the class directly in RAM but then I wouldn't be using the same procedure as the SDK.

Looking forward to hearing good suggestions on how to go about it :-)


Kind regards,
Christian

Parents
  • Hi Christian, 

    Have you looked at the USB Device Example in the SDK? 

    Also, check out this post.

    -Amanda H. 

  • Hi Amanda,

    Yes, I did look at the SDK examples and I took the dummy example as a reference. The post you are refering to, that I have seen but seems different from what I am trying to do, which is to use the SDK as is.
    What I am missing from the SDK (or haven't understod how to do in a simple way without doing small hacks):

    - change the USB sub version by use of SDK configuration so that BOS requests are triggered. Right now I have modified the SDK to exchange the sub-version value with a makefile define (default to 0 if no definition is set)
    - get unhandled USB requests/events from the USBD without having to making a modified copy of the driver

    I have it running by copying the class to RAM and setting the iface.cnt value to 0. Please note, that we want is to use the HID descriptor (APP_USBD_HID_GENERIC_GLOBAL_DEF) in the SDK (basically as is) and then get undhandled requests/events forwarded to our code. In this way we can make simple and elegant solution. It would be pretty neat if you could just provide an event handler to get the events.

    Kind regards,
    Christian

Reply
  • Hi Amanda,

    Yes, I did look at the SDK examples and I took the dummy example as a reference. The post you are refering to, that I have seen but seems different from what I am trying to do, which is to use the SDK as is.
    What I am missing from the SDK (or haven't understod how to do in a simple way without doing small hacks):

    - change the USB sub version by use of SDK configuration so that BOS requests are triggered. Right now I have modified the SDK to exchange the sub-version value with a makefile define (default to 0 if no definition is set)
    - get unhandled USB requests/events from the USBD without having to making a modified copy of the driver

    I have it running by copying the class to RAM and setting the iface.cnt value to 0. Please note, that we want is to use the HID descriptor (APP_USBD_HID_GENERIC_GLOBAL_DEF) in the SDK (basically as is) and then get undhandled requests/events forwarded to our code. In this way we can make simple and elegant solution. It would be pretty neat if you could just provide an event handler to get the events.

    Kind regards,
    Christian

Children
Related