The errata document, ES_LPC546xx, Rev. 2.1 — 23 October 2018 details an issue with HS USB device as follows:
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.
Hi Padraig Fogarty,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1)Is this handled in the SDK?
-- As I know, it's no work-around in the SDK.
2) 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 a NAK?
-- Maybe set an indicator to aware the problem condition whether happens or not, in further, determine to transfer a NAK or not.
TIC
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thank you for responding.
However, I don't see how the suggestion to set an indicator is a practical solution to this problem.
If the problem is as described in the errata, that the next transmitted packet will have corruption in the first byte, then the problem would only be evident to the host. And that presumes that the host software performs some additional error checking on the data, this negates the benefit of the error detection and correction which is inherent in USB and adds a significant overhead.
Also, because the LPC device contains a USB peripheral and stack which are supposed to simplify USB development, the ability to access low-level functions is somewhat hampered.
You might advise how the application code can transmit a NAK?
Thanks,
Padraig
Yes, you're right.
I'm working on it now, meanwhile, I'll contact SDK team to confirm whether they have the workaround now.
So be patient for the response.
Have a great day,
TIC
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
Hi jeremyzhou
Just wondering if you have any update on this issue?
Also, I have encountered other issues with the USB code so I'm wondering if this there are any imminent plans for updates to this SDK?
Padraig
According to the reply, they have the plan to integrate the workaround in the SDK library, however, they have no exact schedule to make it.
Have a great day,
TIC
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
@jeremyzhou Jeremy,
Is there any resolution to this issue. The latest SDK (v2.9.0) doesn't seem to address this. I'm completely stuck without a way to address this and desperately need a solution.
I did try @dark0711 solution without success.
Thank you.
Sam Guido
I'm in the same boat. Is there a solution to this @jeremyzhou? The solution from @dark0711 seems to prevent the issue from happening as often, but it does not prevent it entirely.
Any update on this issue would be great - even if to say it can't be fixed.
Cheers,
Ben
I have updated the solution and fixed the errors, please try.
I use a list of bad enpoints and block the sending of IN
If you need help, I will help.
1. Maybe the Errata is incorrect. The RX transfer length should be 4+ N*8, not as described in the ERRATA: 4 + N * 16.
2. When the work around in the SDK will be available?