• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 656 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.

TM4C129XKCZAD: USBHCDPipeSchedule(() schedules IN transactions in host mode when used with an OUT Pipe

R Sexton
Expert 1030 points
Part Number: TM4C129XKCZAD

This function works fine for Host mode reads/IN transactions.

When you schedule a write to an OUT pipe, you get an IN transaction.

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

    Can you share what ui32Pipe parameter is being passed into the USBHCDPipeSchedule function or even a code example I could run on either the LaunchPad or DK-TM4C129X? I would like to follow along with how the USBHCDPipeSchedule function is flowing based on the inputs to see if I can identify what is going on.
  • 0 in reply to Ralph Jacobi
    Expert 1030 points
    I'm using pipe 0x01210000
  • 0 in reply to Ralph Jacobi
    Expert 1030 points
    Ok. Its more that OUT transactions don't work. In my case, my MCU was talking to a device that had data in it's output buffer, so when USBHCDPipeSchedule() ran, there was a IN transaction ready to go.

    Now that I'm issuing a separate IN transaction before using USBHCDPipeSchedule() to write, I get failure.

    DMA transfers are working fine now that I'm using aligned buffers.
  • 0
    Guru 55913 points
    Hi Robert,

    Have you checked the DK-TM4C1294 host library files to see if they may have better control of piped DMA transfers in host mode?
  • 0 in reply to R Sexton
    Guru 55913 points

    BTW: if your being plagued by a defective +5v tolerant USB0 VBUS pin not togging GTO device into piped TXD mode it may be relative to random pin failure. The work around below, Tivaware USB0 library seems to react  on FIFO activity and toggles VBUS/ID pins relative and automatically for device endpoint simply being connected. After seeing how well this works to isolate the host from device +5v destructive reverse current flow into MCU VBUS pin it makes for a nice WA. Seemingly an excellent condition VBUS pin will measure very high ohmic resistance in the high megohms range.

        /* USB_GPCS_DEVMOD_DEVVBUS:
     * Use USB0 VBUS PB1, force PB0 ID high(Device).
     * USB_GPCS_DEVMOD_HOSTVBUS:
     * Use USB0VBUS and force USB0ID low(Host)
     * USB_GPCS_DEVMOD_DEV:
     * Force USB0VBUS and USB0ID high   */
    HWREG(USB0_BASE + USB_O_GPCS) |= USB_GPCS_DEVMOD_DEV;//USB_GPCS_DEVMOD_DEVVBUS

  • 0 in reply to R Sexton
    TI__Guru*** 135355 points
    To close this topic in the public forum, Robert was the issue only that the DMA transfers do need an aligned buffer regarding this specific topic?

    For all others, discussions are occurring offline and if anything else arises which ends up being related to this specific query then I will post further details...
  • 0 in reply to Ralph Jacobi
    Expert 1030 points
    I never did get writes working with USBHCDPipeSchedule().

    I resolved this issue by splitting USBHostPipeWrite() into two parts - one that starts the DMA transfer, and another one that spin-loops waiting for completion.

    I'm able to split the transaction in half that way and perform network operations while the USB system completes the transfer. Oddly enough, that didn't give me a significant performance boost. I suspect thats because network operations (lwIP) are relatively efficient compared with USB, and they can run concurrently with the active DMA transfer.

    I do have to copy my payloads into word-aligned buffers for uDMA to work. Thats relatively cheap compared with the transfer time for the USB payloads, so optimizations like double-buffering are not likely to help much.