LPC546xx USB.15 Errata Help

[andyjackson]

I have an application that runs a communication protocol between a single In/Out Bulk endpoint pair with  the data being fully error checked and sequenced which makes lost data easy to spot. When run for a while there is a persistent occasional loss of data on the in side which when investigating using Wireshark shows that the issue occurs after an Out packet, with the following in packet having its first byte zeroed and typically a data length of 50 (meeting the 4 + (N *16) criteria) leading me to believe errata USB.15 is the root cause.

The errata says that the workaround is a NAKed Tx (IN) transfer in-between the RX (OUT) and TX (IN) transfers. My question is how to achieve this using the ROM USB support? It looks like the data is already queued on the in endpoint prior to receiving the out transaction.

Any help would be greatly appreciated as the application otherwise runs well.

Andy

[FelipeGarcia]

Hi Andy,

Sorry for the late reply. I checked internally and unfortunately, as you mentioned the only way application can avoid the errata condition is if the RX (OUT) transfer length is NOT 4 + N*16  bytes. Otherwise, we recommend to use LPC540xx part instead as software workaround seems to not be possible.

Have a great day,

Felipe

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored. Please open a new thread and refer to the closed one, if you have a related question at a later point in time. 

------------------------------------------------------------------------------ 

[andyjackson]

As a followup to my previous message, I should have said that the Out transfer data length is 20 bytes meeting the 4 + (N *16) criteria.

Having done some more testing I have found that by careful management of the Out transfers (well spaced packets that avoid the 4 + (N *16) criteria) it is possible to transfer large amounts of In data without triggering the zero byte issue.

Unfortunately this is not a long term solution as once the amount of Out traffic we are generating increases then we have no control over how the the host system (Windows) packages up the data and so its possible that the issue could still occur.

So my question to NXP still stands - how using the USB ROM interface can we meet the requirement to have a NAK between Out and In transfers as specified in the errata work-around? Without this I don't see how it is possible to have a reliable high speed bulk In/Out pair using the LPC546xx as is required for many USB applications.