• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 396 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TM4C1294KCPDT: Disabled USB0 analog VBUS/ID pins

TM4C1294KCPDT: Disabled USB0 analog VBUS/ID pins

Genatco
Guru 55913 points
Part Number: TM4C1294KCPDT

Why is USB0 endpoint interrupt handler only written to handle endpoint 0 status when 8 end points are/were configured in USBLIB project (usbdenum.c)?

Seemingly It can not be guaranteed INT control status always occurs on endpoint 0. Verified multiple bulk or HID client end points may connect via multiple launched instances of the CDC class driver. Windows plug & play manager handles USB client requests using the same vendor UUID via multiple instances. The endpoint enumeration process simply bumps the CDC address to the next available from calls to (lmusbdll.dll / lib).

Existing Tivaware usblib INT function does not seem to be written to handle each enumerated (8) endpoints return status. Does not the added handlers (below) seem necessary for return status occurring from any other endpoint connected above endpoint 0? 

void
USBDeviceEnumHandler(tDCDInstance *pDevInstance)
{
    uint32_t ui32EPStatus, ui32DataSize;

    //
    // Get the end point 0 status.
    //
    ui32EPStatus  = MAP_USBEndpointStatus(USB0_BASE, USB_EP_0);

    // Perhaps following are required for other enumerate endpoints returning USB status???
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_1);
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_2); 
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_3);
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_4);
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_5);
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_6);
    //ui32EPStatus |= MAP_USBEndpointStatus(USB0_BASE, USB_EP_7);

  • 0
    TI__Guru*** 135355 points
    Hello BP101,

    This is because all control status are supposed to be passed through EP0.

    "Endpoint descriptors are used to describe endpoints other than endpoint zero. Endpoint zero is always assumed to be a control endpoint and is configured before any descriptors are even requested."

    From: www.beyondlogic.org/.../usb5.shtml

    To follow along with this, the function describes that it handles all interrupts on EP0 to be able to ensure the control status is always up to date.

    "This function handles all interrupts on endpoint zero in order to maintain the state needed for the control endpoint on endpoint zero. In order to successfully enumerate and handle all USB standard requests, all requests on endpoint zero must pass through this function."

    As USBDeviceEnumHandler is only meant to handle control status changes that come only through EP0, it is correctly setup.

    Other endpoint interrupts are handled at the bottom of USBDeviceIntHandlerInternal.
  • 0 in reply to Ralph Jacobi
    Guru 55913 points
    That interesting since the first bulk client address of the Windows enumerated device address is endpoint 0x0.

    So your saying all other enumerated endpoints above 0x0 send status via the first clients connection, ok.

    Perhaps the Windows bulk endpoint client project should not be configuring it to use the control endpoint address 0x0? The first bulk client launched enumerates to address 0x0 and others being next in line 0x1,0x2,0x3 and so on.
  • 0 in reply to Ralph Jacobi
    Guru 55913 points
    So CCS debug USB0 only shows the first enumerated client being connected to FIFO 0 status results, all other FIFO status registers remain quiet. That seems odd the target is using the control endpoint (FIFO 0) to send data to the enumerated bulk device client address 0x0.
  • 0 in reply to Ralph Jacobi
    Guru 55913 points
    bNumEndpoints indicates the number of endpoints used by the interface. This value should exclude endpoint zero and is used to indicate the number of endpoint descriptors to follow.

    Perhaps the interfaces configuration function is not excluding endpoint zero as being assigned a descriptor? Perhaps the first descriptor is being incorrectly assigned to endpoint 0x0 and ending up on the control endpoint? One might expect FIFO 1 to have some status for the first bulk client connection being enumerated by windows.