Can I change the LPC4357 USB0 host mode asynchronous schedule's sleep time?

[michaelrandle]

In my USB0 HOST implementation, I have a single transfer descriptor with an IN transaction in one of the queue heads and no other active transfers.  The device NAKs the transfer and the host controller sleeps the asynchronous scheduler for 10 µs, once the NakCnt for that queue head has elapsed (I have the NakCnt RL field set to 1), before restarting the asynchronous schedule.

This is all correct as per the EHCI specification, but the Mass-Storage Class device I'm trying to use STALLs the IN endpoint during the status stage of a write command and I want to slow down the IN polling so see if that helps, because my Windows 10 PC, which works fine, only polls the endpoint every 25 µs.

Is there any way to change the AsyncSchedSleepTime to a period other than 10 µs?

[Alexis_A]

Dear Michael,

I was checking the drivers from the LPCScrypt and the new ones and couldn't find this variable/define mentioned. This is a variable that you found in our stack or is an EHCI standard definition?

Best Regards,

Alexis Andalon

[michaelrandle]

Dear Alexis,

The AsyncSchedSleepTime period is mentioned in the EHCI standard. It is described in the Operational Model, Asynchronous Schedule section (4.8.4), as an 'example method for restarting asynchronous schedule traversal'.

I don't know that it can be controlled by application software, as it is not mentioned in the Register Interface section (2), or the Data Structures section (3) and I cannot find any references to it, or hints of its existence, in the UM10503 User Manual.

I don't know of any other way I could slow down the IN polling and I don't really want to be stuck with a whole bunch of USB 2.10 Flash drives that our customers can't use.  I've tried another of our products, which uses a different (non-NXP) micro controller to do the USB host, and that uses a 25 µs asynchronous schedule period, like the PC and it also works.  The Flash drive manufacturer's technical support has suggested that the STALL is due to "a speed issue", although they were not very specific.

It would be great if there is a mechanism by which I can change the asynchronous schedule traversal timing, but I would not be surprised if there is not, as it does appear to be an internal, implementation-specific, non-mandatory detail.

Best regards,

Mike

[Alexis_A · Accepted solution]

Dear Michael,

After discusing with the applications team about it, it looks like there's no way to change this.

Sorry for the inconveniences this may cause you.

Best Regards,

Alexis Andalon

[michaelrandle]

Thanks Alexis,

It is the value mentioned in the standard, so I did suspect that would be the case.  I'll just have to try something else.

Thanks for checking for me.

Best regards,

Michael