LPC546xx Errata 3.22

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC546xx Errata 3.22

3,468 Views
padraig_fogarty
Contributor III

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

pastedImage_2.png

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.

Labels (1)
11 Replies

3,087 Views
jeremyzhou
NXP Employee
NXP Employee

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.

Have a great day.

TIC

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

3,087 Views
padraig_fogarty
Contributor III

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

0 Kudos

3,087 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Padraig Fogarty,

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.
-------------------------------------------------------------------------------

0 Kudos

3,087 Views
padraig_fogarty
Contributor III

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

3,087 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Padraig Fogarty,

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.
-------------------------------------------------------------------------------

0 Kudos

2,652 Views
samuelguido
Contributor II

@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

2,525 Views
BenDev
Contributor II

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

0 Kudos

2,632 Views
dark0711
Contributor III

@samuelguido 

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.

0 Kudos

3,088 Views
wangyanjun
Contributor II

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?

0 Kudos

2,990 Views
dark0711
Contributor III

Hey. I solved this problem like this.
I am using 4 bulk enpoin (OUT / IN)
But there was no complete testing yet.

SDK 2.8.2

0 Kudos

2,637 Views
dark0711
Contributor III

update 

My fix. For Bulk(Tested) and Interrupt(Not tetsted)

In BadOutEndpoint List add item Out endpoint for search bad request.

Use macro USB_DEVICE_LPC5460X_IP3511_ERRATA_3_22_FIX

SDK (v2.9.0) 

 

0 Kudos