USBHS max endpoint limitations

[lh_dan]

I am working on a K70 MQXv4.0.0 CW10.6 project that is taking a previous design that used full-speed usb and porting it to high-speed usb.  There have been a number of issues along the way but I have just uncovered something about the K70's high speed implementation that is quite limiting.  Our usb device uses 5 endpoints (1 control + 4 user defined).  While full-speed usb allows up to 16 user defined optional endpoints, it seems that high-speed only allows 3.

     From K70 Sub-Family Reference Manual Chapter 53.1.2:

  

Is this true?  Will I not be able to fully support this design with high speed?  Is there anyway to add support for additional endpoints?  It seems as if space has been reserved in the USBHS memory map for more endpoints that are not defined. 

[Kan_Li]

Hi Daniel,

In fact, since the HS endpoint is bidirectional, besides the endpoint 0, there are 3 pairs of endpoints can be used, so actually there are 6 endpoints can be used. so it should be no problem for your application.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[lh_dan]

Kan,

Thank you for your reply.  However, I do not believe endpoints work in pairs.

From the USB v2.0 spec:

     An endpoint is a uniquely identifiable portion of a USB device that is the terminus of a communication flow

     between the host and device. Each USB logical device is composed of a collection of independent

     endpoints. Each logical device has a unique address assigned by the system at device attachment time.

     Each endpoint on a device is given at design time a unique device-determined identifier called the endpoint

     number. Each endpoint has a device-determined direction of data flow. The combination of the device

     address, endpoint number, and direction allows each endpoint to be uniquely referenced. Each endpoint is a

     simplex connection that supports data flow in one direction: either input (from device to host) or output

     (from host to device).

The control endpoint (0) is bidirectional but the data endpoints (1-3) are either IN or OUT.  That would only allow for 3 optional endpoints.  Right?  Or am I interpreting this incorrectly?

[ndavies · Accepted solution]

Daniel, The description is confusing. Endpoints 1-3 can be used in both directions at the same time on the Kinetis HS USB. They just aren't described as bidirectional. Bidirectional means something specific to endpoint 0. The Kinetis HS USB has 1 bidirectional endpoint on endpoint 0, 3 in endpoints and 3 out endpoints on endpoints 1-3. We're using the high speed USB on the K60 120 MHZ parts in this manner in one of our products. We needed 3 pairs of endpoints to support 3 different protocols.

Norm Davies

[lh_dan]

Norm (& Kan),

Thanks for correcting my interpretation of endpoints.  It is confusing that that only the control endpoint is listed as being bidirectional even though data endpoints can be both IN and OUT.  I'll need to have our host driver corrected (it is a vendor class that is hard-coded to use endpoint 4), but with this information we should be able to work through it.  Does anyone know if Freescale will never add support for more than 4 high speed endpoints?

-Dan

[adriancano]

Hi,

Future Kinetis devices implementing the USBHS (USB High Speed) module are planned to support more than 4 endpoints. I recommend to keep your eye in the Kinetis devices for coming features :smileywink:.

Hope this information can help you.

Best Regards,
Adrian Sanchez Cano
Technical Support Engineer
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

I can confirm that a single endpoint is often used as both IN and OUT.

Since no endpoint is used in both directions at the same time they are simplex.

Rather than a descriptor defining endpoint 1 as the IN and point and endpoint 2 as the OUT endpoint (eg. for bulk traffic), one defines the IN and OUT to both be on endpoint 1 (for example). This assumes that the used embedded USB driver supports this, but the USB controller in the Kinetis can.

Regards

Mark

http://www.utasker.com/kinetis.html

[lh_dan]

Mark,

Everyone has been so helpful I am hoping I can ask one more question of those who have already designed this.  I have modified the usb_descriptor file to define HID IN and OUT to be on endpoint 1.  Enumeration works but transferring data does not because the _usb_device_resister calls in USB_Class_Hid_Event() do not take direction into consideration.  The first callback gets registered but the second one will not. 

                case USB_INTERRUPT_PIPE :                     if(ep_struct_ptr->direction == USB_RECV)                      {                         (void)_usb_device_register_service(devicePtr->handle,                             (uint_8)(USB_SERVICE_EP0+ep_struct_ptr->ep_num),                              USB_Service_Hid_Out, arg);                     }                     else                      {                         (void)_usb_device_register_service(devicePtr->handle,                             (uint_8)(USB_SERVICE_EP0+ep_struct_ptr->ep_num),                              USB_Service_Hid_In, arg);                     }                     break;                               

You say that the USB controller in Kinetis supports sharing endpoints, but it seems as if only one service can be registered per endpoint.  Correct?  When IN and OUT share an endpoint I cannot have separate In/Out services as per the CDC example (which I used to modify the HID class to work in both directions).  Not a big deal, I can determine direction in the service via the event structure.   I just wanted to be sure that the example code does not support the sharing of endpoints.

Thanks,

Dan

[mjbcswitzerland]

Dan

I don't use the example code but instead work with the uTasker USB stack. It will depend on the stack that you are using as to whether it can handle IN and OUT on a single endpoint since that is a design issue.

What I can do is tell you the implecations for the uTasker USB stack so that you can check the details in yours:

1. The configuration descriptor has to be build accordingly (either IN = 1, OUT = 2, or IN = OUT = 1, for example) - this is what you have already done.

2. When the endpoints are initialised there will be two initialisations for the same one (one for the IN function and one for the OUT function). The initialisation function must ensure that when it initialises for OUT operation it doesn't alter any IN settings (that may have aready been made), In the other sense, the initialisation function must ensure that when it initialises for IN operation it doesn't alter any OUT settings (that may have aready been made), [IN and OUT configuration ordering can theoretically be in any order].

3. For basic operation there is only need for service on data reception and so there should be no change needed for this. The buffer decriptors have two independent halves, one for IN and one for OUT and so code handling IN and OUTs should not in fact conflict in any way. Specifically in the uTasker stack there is a need for a task ownership to be assigned for the IN and OUT parts which is not needed when an endpoint is only either IN or OUT, in order for it to correctly wake the owner task on reception or when the output buffer (IN side) has space from new data ater the task was blocked due to lack of space. This single piece of extra information was the only one needed in this solution (in fact one single additional variable byte per endpoint object).

There may be more adjustment requirements in other cases if the design of IN and OUT handling (and the buffer descriptor accesses) have some (unnecessary or incorrect) overlaps that don't impact the pure IN or OUT case, but cause new problems when sharing. If there are such, the job to separate them correctly could be quite large and compicated. Hopefully the best case scenario proves to be true!

Regards

Mark