• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 359 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C129XKCZAD: USBHCDPipeStatus() is unimplemented.

R Sexton
Expert 1030 points
Part Number: TM4C129XKCZAD

USBHCDPipeStatus() in usbhostenum.c is useless:

uint32_t
USBHCDPipeStatus(uint32_t ui32Pipe)
{
    return(0);
}

I need for this to work so that I can detect and recover from a write transfer failure that I'm seeing.  The docs even refer to a value, USBHCD_PIPE_NO_CHANGE, which isn't defined anywhere in USBLIB.

 

  • 0
    TI__Guru*** 131490 points
    Hello R Sexton,

    Unfortunately there are no plans to include that functionality into the usblib. Personally, I don't think that API should have even been released to 'tease' that such functionality would exist in the future, much less indicate a variable which doesn't exist in the usblib - but I wasn't part of the team when the last release occurred...
  • 0 in reply to Ralph Jacobi
    Expert 1030 points
    How should I check for transfer failures?
  • 0
    Guru 117855 points

    R Sexton said:
    USBHCDPipeStatus() in usbhostenum.c is useless:

    It took ALL of my  "Powers of Discipline"  to refrain from,  "Richard - How do you REALLY feel?"

    Yet - arrives Ralph - and he confirms your feeling.

    This subject area is WAY OVER my head - yet my "photo-mem" recalls a client  (at least one who employed "USB Pipe Something" - and we've  "Got a call in."

    Now - what intrigued me in this client's (past) case - they reviewed how (other):

    • USB equipped ARM MCUs
    • and the "usual suspect" UART <-> USB chips

    "performed - in their specific "area of intent."   And - I DO recall - they were able to "tease out" sufficient understanding (copying) that their effort DID succeed.

    As you (appear) "Dead-Ended" here - I thought this may offer a,  "Court of last resort."    (maybe)

    I CAN report - that our use of MANY ARM MCUs - from multiple vendors - OFTEN EXPOSES "advantaged techniques" - and likewise - those,  "Not so much..."     Sometimes - sailing "Into the wind" (45° off - to be precise) enables you to reach your objective - even when - especially when - such seemed doubtful...

  • 0 in reply to R Sexton
    TI__Guru*** 131490 points

    Hello Robert,

    R Sexton said:
    How should I check for transfer failures?

    From what I've reviewed code wise, it looks like the implementation would need to follow along with this API also in the usbhostenum.c file:

    //*****************************************************************************
//
//! This function returns the current status of an LPM request.
//!
//! \param psDevice is the device to query.
//!
//! This function returns the current status of LPM requests for a given
//! device.  This is called to determine if a previous request completed
//! successfully or if there was an error.
//!
//! \return This function returns the following values:
//! - \b USBHCD_LPM_AVAIL - There are no pending LPM requests on this specific
//!   device or the last request completed successfully.
//! - \b USBHCD_LPM_ERROR - The last LPM request for this device did not
//!   complete successfully.
//! - \b USBHCD_LPM_PENDING - The last LPM request has not completed.
//
//*****************************************************************************
uint32_t
USBHCDLPMStatus(tUSBHostDevice *psDevice)
{
    uint32_t ui32Ret;

    ASSERT(psDevice != 0);

    //
    // Should never have both USBHDEV_FLAG_LPMERROR and USBHDEV_FLAG_LPMPEND
    // set at the same time.
    //
    ASSERT((psDevice->ui32Flags &
            (USBHDEV_FLAG_LPMERROR | USBHDEV_FLAG_LPMPEND)) !=
           (USBHDEV_FLAG_LPMERROR | USBHDEV_FLAG_LPMPEND));

    //
    // Default to no pending transfers or errors.
    //
    ui32Ret = USBHCD_LPM_AVAIL;

    if(psDevice->ui32Flags & USBHDEV_FLAG_LPMERROR)
    {
        //
        // An error occurred after the last call to send an LPM command.
        //
        ui32Ret = USBHCD_LPM_ERROR;
    }
    else if(psDevice->ui32Flags & USBHDEV_FLAG_LPMPEND)
    {
        //
        // Still have a pending transfer.
        //
        ui32Ret = USBHCD_LPM_PENDING;
    }

    return(ui32Ret);
}

    The flags used are user defined are placed at the top of the file, and a ui32Flags variable was added to the tUSBHostDevice struct (this may be harder to pull off as it is used across 7 files, so you may just opt for a global variable not tied to the structure if you feel it is clean enough).

    The harder part will be integrating the new flags are part of the USBHostIntHandlerInternal which is where you can dictate what events result in what flags being set, and then of course adding the flag checks into relevant functions to get the behavior you want.

    Unfortunately any way I look at it, I don't see a quick/easy path to implement that - though there's always a chance that there is an easier way which I just don't have the knowledge level to see.