LPC5528 FS USB Throughput

[juan_guzman]

LPC5528 USB Full Speed throughput

Hello All,

I'm working on a project using the LPC5528. It's a printer application were the LCP5528 is used perform print jobs.

The print job data is transferred from a Host processor to the LPC5528 via FS USB0 interface using a Bulk type Endpoint. We are using NXP MCUXpresso SDK USB Stack implementation.

The problem we're seeing is that we're not getting efficient throughput on the USB Bulk transfers. Every other Bulk transfer is being NAKED by the LPC5528.

I timed the execution of the USB ISR handler on the LPC5528 from the point the interrupt fires to the point were the USB stack calls the Callback function and re-activates the Bulk Endpoint. This takes about 40uS. It is my guess that the latency in in the USB Stack is causing the inefficient throughput.

Can someone confirm if this is a reasonable conclusion? If so, is there a way to optimize the USB Stack or what other means are possible to achieve efficient throughput through the Bulk Endpoint? 

[Alice_Yang]

Hello @juan_guzman 

Thanks for your question.

Could you please first test using the SDK demo printer_virtual_plain_text? Also, please measure the execution time.

If the issue can be reproduced with the SDK demo, I’ll help check it on my side.

Thank you.

BR

Alice

[juan_guzman]

Hello Alice,

I was able to recreate the same issue using the SDK demo you suggested.

I continue to see the same pattern of one transfer is ACKed and the next is NAKed.

I measured the execution time from the entry into the USB ISR to the USB Stack callback function USB_DevicePrinterAppCallback(). This time is 13.2 uS

I also measured the execution of the USB_DevicePrinterRecv(), this time is 16.0 uS

So the entire time for the USB Stack to handle a Bulk frame and reactivate the Endpoint is 13.2uS + 16uS =  29.2 uS.  This is pretty much in line to what I'm seeing on my project.

Please let me know if the Stack can be optimized to achieve a better USB transfer efficiency.

Attached is the USB Analyzer trace and also the test file I used.

Thank You,

[Alice_Yang]

Hello @juan_guzman 

Thanks for your reply. Which tool did you use for the view below? I will debug and check on my side.

Thank you.

BR

Alice

[juan_guzman]

Hello Alice,

I used Ellisys Visual USB Analyzer to capture the USB trace.

Thanks,

[Alice_Yang]

Hello @juan_guzman 

Thanks for your reply. I tested with a Teledyne USB analyzer, and the results are almost the same as yours. A Bulk endpoint will NAK when it’s not ready to accept data. I confirmed with internal,  for the MCUXpresso USB stack, a delay of about 30–50 µs from interrupt to re-arming is typical because:

The stack runs in interrupt context but still performs buffer management and callback dispatch.

 BR

Alice

[juan_guzman]

Alice,

Thank you for confirming the issue.

What would be the recommended method of ensuring efficient Bulk transfers with No NAKs?

Writing my own USB handler?

Does NXP have a USB driver that I can implement with less overhead compared to the MCUXpresso USB stack?

Do you know of any third party software solution I can use?

[Alice_Yang]

Hello @juan_guzman 

Thanks for your reply.

NXP only provides the MCUXpresso USB stack. For third-party options, you can test with TinyUSB. You might also consider using HS-USB instead of FS USB.

Thank you.

BR

Alice

Alice