• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 396 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.

TM4C1233H6PGE: USB communication hangs with USBD_STATUS_BUFFER_OVERRUN error

Peeter Keres
Prodigy 30 points
Part Number: TM4C1233H6PGE

Hello Everyone,

We have designed custom boards using TI microcontroller TM4C1233.
The microcontroller's USB module is programmed as a bulk device using one IN and one OUT pipe.
The USB part of the board's firmware is based on TI Tiva bulk example and the PC side receives data using Lmusbdll.dll on top of WinUSB driver.

In rare cases the PC application hangs and the Microsoft Message Analyzer shows USBD_STATUS_BUFFER_OVERRUN  error. After that the LmUsbdll error processing continuously calls WinUSB Abort Pipe function without any success.

The TivaWare USB Bulk class driver  defines  USBERR_DEV_RX_OVERRUN flag among USB_RX_ERROR_FLAGS but the TM4C1233 datasheet says this flag is never set for Bulk devices.

Can someone confurm if the above statement is true and possibly recommend some corrective actions besides complete application  and controller reset?

Thank you very much in advance

Best Regards

Peeter

  • 0
    TI__Guru*** 128195 points
    Hello Peeter,

    From the research I have done, I don't see any indication that the datasheet is incorrect.

    Are you certain that the bulk device is not setup to be in Isochronous mode?

    Can you try and confirm that the TM4C is reporting that error via a USB analyzer? (As far as I am aware the MS analyzer you mention doesn't look at the USB lines like a USB analyzer?)
  • 0 in reply to Ralph Jacobi
    Prodigy 30 points

    Hello Ralph,

    Thank you for the quick answer.

    The Microsoft Message Analyzer is a software-only tool that probably does not look at the USB lines but gathers information from the driver(s).

    Overrun.pdf

    I have attached a MMA capture screenshot of the overrun event.

    The screenshot shows that the PC and device are communicating using bulk pipe. Normally this works OK and the PC receives packets as expected. But then an USBD_STATUS_BUFFER_OVERRUN is returned to application bulk_in request. From then on the LmUsbdll tries to recover from the error by issuing ABORT_PIPE with no success. The controller is not responding.

    What action should the controller take? Will it be enough to call USBDevEndpointStatusClear or call USBFIFOFlush too or should the whole USB module be initialized again?

    Best regards,

    Peeter

  • 0 in reply to Peeter Keres
    TI__Guru*** 128195 points
    Hello Peeter,

    I don't think the USB module needs to be initialized again.

    I would say if you are okay with losing any data in the buffer (and I wouldn't see why not since you won't know what state the data is in), that both actions you noted should be considered. First off, I would definitely recommend to use the FIFO Flush to clear the FIFO as otherwise any further packets may cause further errors. After that has been done, I would then add in a check for the Endpoint Status, and only if it's still a USBERR_DEV_RX_OVERRUN error would I clear the Endpoint Status as well. You may also want to consider a USBBufferFlush for the RX buffer as well to clear out the ring buffer.

    To do all of this, I would recommend making sure that the RxHandler in your application has a state defined for USB_EVENT_ERROR and then use that state to check for the USBERR_DEV_RX_OVERRUN flag and if it is set, then take those actions and see if that resolves the issue.

    Handling the error with those API's should be able free the USB stack enough to receive the request, and then resume communicating with the PC.
  • 0 in reply to Ralph Jacobi
    Prodigy 30 points

    Hello Ralph,

    Thank you for the valuable recommendations. I will try to follow them.

    Because the error happens so rarely this will take some time though.

    Best Regards,

    Peeter