TM4C1294NCPDT: How do I increased the time out constant for USB host write?

Feel your pain - vendor should (WILL) arrive.   (w/insider info)

As always - you 'Reinforce Response' by noting:

• has this issue occurred upon (several) - not just one - micro SD?
• have you 'removed' all (potentially) conflicting/slowing 'code elements' - w/in your program - which may cause or magnify such issue?
• your ability to produce the shortest code - which (always) reveals such issue - and then present (that) here for review - is the 'Gold Standard' for 'Poster Assistance.'

The removal of  any/all 'extraneous factors' - enables the fastest, most focused, & direct 'Issue Fix.'

This is not asking anyone to debug anything, the microSD here is just to provide a background reference regarding the difference of MLC and SLC. In fact, the USB stack may be performing perfectly for normal USB device.

Removing the background, the question can be reconstructed as:

Is there a timing parameter in the USB stack to adjust the time out length so that it will wait for a longer period before resorting to reconnection?

Is it true then - that you, 'Elevate your question' - while 'Discounting the potential impact of (other) program influences?'

My firm's staff have noted 'variation' in 'Response Time' - due to different microSD 'brands' - AND as well to, 'intrusive effects of (other) program elements.'     NEITHER accommodated - via your (SO tightly focused) question!

Having past co-founded - serving as VP Engineering - and then taking Tech Firm PUBLIC - it has been WELL-NOTED that, 'CLOSING THE DOOR PREMATURELY - UPON ANY/ALL 'UNANTICIPATED ISSUES/CAUSES' PROVES LESS THAN OPTIMAL!

I don't think I changed my question, and I don't think it has impact from other program modules either

If you deal with MLC and SLC SDs, you should know the timing difference

I made no claim to 'my' personal dealings (w such SDs) - merely reported a 'time proven' method - to BEST RESOLVE ISSUES!

It (should) be noted - that my 'arrival in your behalf' - aimed to, 'Speed, Ease & Enhance' Vendor Efforts - in your regard.    Most always - they SEEK such (peripheral) information - to reduce (their) entry - into a 'Black Hole!'

A 'prancing horse' sits my garage - having arrived due to the 'too often missed' - arrival of the 'unexpected' - at the desks of 'others.'
I wish you well...

Hello David,

I am not sure 'time out' is the right description. I've been searching through our USB stack and also checked some of my USB resources, and I couldn't find anything that indicated a set timeout.

You mention that the write can't be completed over a long period, does that mean it's continuously writing for that whole time? Or is it that during the transfer, there is a gap of over 100ms between two packets?

Is there a possibility that a packet is being sent but is NAK'd repeatedly and that causes the disconnect?

Is the issue occurring every time or only sometimes but in a replicable manner?

Right now I'm just trying to come up with other ideas to search the usb library with to try and find the root cause for your issue, so I'm hoping some more detail will help with that.

With MLC SD, it swaps sector once a while , and when that happens, its write ack can take a long time, and most card readers will simply stay in loop and wait for that to finish (~100ms), during this time, the write packet from host will not be acked, and after "time out(?)", the TiVa USB host stack will reset the connection and resume the write (~2 seconds, SLC may also swap but much quicker, so USB host stack will not time out). If one is writing a file, this delay won't cause any problem, but if we need to stream data, I need a pretty big data buffer to deal this multi-second-delay. If we can somehow change the timeout length, it may take care the problem

Hello David,

Do you know which endpoint this behavior is occurring on? And what that endpoint is configured as? Could it be a bulk endpoint?

end point 2, bulk

Hello David,

Digging into the datasheet, it looks like there is a NAK timeout configuration for bulk endpoints only. Tracking that back into usblib, it looks like the USBHCDPipeConfig API is handles the setting for that via the ui32Interval that is passed into it.

I would recommend trying to look into the ui32Interval setting for USBHCDPipeConfig of endpoint 2, and if that is set to 0 or a low number, to try and increase that and see if you can get the behavior you are seeking for that way.

I am not sure if this will work, but it's the best lead I've found so far. The datasheet describes the timeout as receiving NAK responses beyond the timeout set, but I am making an assumption here that it also would govern not getting a reply period as well...

That is the Interval for polling endpoint data transfers. Value in frame counts. Ignored for **Bulk** & Control Endpoints. Isochronous must equal 1 and field may range from 1 to 255 for interrupt endpoints.

That is the Interval for polling endpoint data transfers. Value in frame counts. **Ignored for Bulk & Control Endpoints**. Isochronous must equal 1 and field may range from 1 to 255 for interrupt endpoints.

Hello David,

Where are you getting that information that it is ignored for Bulk from? Can you point me to the source files I can read? Yes it is valued in frame counts.

From the comment in TivaWare for USBHCDPipeConfig:

//! Setting the \e ui32Interval parameter depends on the type of endpoint being
//! configured.  For endpoints that do not need to use the \e ui32Interval
//! parameter \e ui32Interval should be set to 0.  For Bulk \e ui32Interval is
//! a value from 2-16 and will set the NAK timeout value as
//! 2^(\e ui32Interval-1) frames.  For interrupt endpoints \e ui32Interval is a
//! value from 1-255 and is the count in frames between polling the endpoint.
//! For isochronous endpoints \e ui32Interval ranges from 1-16 and is the
//! polling interval in frames represented as 2^(\e ui32Interval-1) frames.

And from the datasheet:

NAK Timeout

Value Description

0        No timeout.

1        Bulk endpoints only: Indicates that the transmit endpoint is halted following the receipt of NAK responses for longer than the time set by the NAKLMT field in the USBTXINTERVALn register. Software must clear this bit to allow the endpoint to continue.

I captured one long write here.