I'm reposting this the last thread seems to be closed. I'm in desperate need of a solution to this issue and the latest SDK (2.9.0) doesn't seem to address this errata.
3.22 USB.15: USB high-speed device in endpoint TX data corruption
My question is, how can the application programmer ensure that the required NAK is generated?
For example, if I already have data queued to send to the host (Tx IN), as would normally be the case for USB, then how can in interrupt this transfer and insert an NAK?
Or is this handled in the SDK?
(I'm using SDK 2.5.0)
Any clarification would be much appreciated.
This problem occurs if USB length % 8 = 4. If the USB packet length satisfies this test, then the USB packet is broken up in to 2 USB packets where the 1st is the length/2-1 and second is length-(length/2-1). These 2 packets will be sent instead of the original packet. This ensures that neither USB packet will satisfy the condition.
I handled it at the lower levels of my host code like this (java):
ArrayList<ByteArray> dataList = new ArrayList<>();
byte halfData = data.readArrayBytes();
int ba1_size = (halfData.length / 2) - 1;
int ba2_size = halfData.length - ba1_size;
ByteArray ba1 = new ByteArray(ba1_size, ENDIAN.BIG);
System.arraycopy(halfData, 0, ba1.getBytes(), 0, ba1_size);
ByteArray ba2 = new ByteArray(ba2_size, ENDIAN.BIG);
System.arraycopy(halfData, ba1_size, ba2.getBytes(), 0, ba2_size);
Hope this helps.
Thank you for your reply and I have implemented similar mitigation code in the host app but unfortunately it will only work reliably on Windows when the Out data rates are low. Once the data rate increases the Windows driver doesn't have to respect the data boundaries of the application and is at liberty to concatenate data in order to achieve the best overall system performance which can result in USB Out packets that can trigger the error condition.
Ultimately I think that without the ability to change the host driver code the only option to resolve this errata is to handle it at the device end. However as yet I've not seen anything from NXP detailing how this can be achieved which is surprising at it appears to affect at least the LPC546xx (errata USB.15) and LPC540xx (errata USB.3) families.
Hi @Alexis_A ,
Can you please contact me directly regarding this issue too as I'd like to know if there is a solution. I can currently replicate the Errata 3.22 issue with a simple example using the latest SDK and a python script to verify the integrity.