USB Stack do's and dont's

[michaelhermann0]

Hello,

I am working with the USB Stack 2.0.1 (newest release 2018/10, I hope) and the K2x family.

Years ago I wrote my own USB stack (for an 8 bit uc) and later used the ROM Stack of the LPC43xx and LPC1x.

I'd like to discuss and collect observations others have made with this stack. I'm rather new to this stack, so maybe I'm doing things not the way they are intended.

OTOH I can share some "pitfalls" that came unexpected at least for me and which may irk others, too.

Example:

When cancelling a pending transaction on an EP with USB_DeviceCancel() the stack immediately calls back the associated class callback as if the pending request had been serviced by the host.

You will have to check the length parameter of the message for the value 0xFFFFFFFF. It is set by the stack for an uninitialized buffer (USB_UNINITIALIZED_VAL_32). The buffer pointer may still be valid, i.e. not NULL.

If you don't check or take other precautions you may end up with reading some 4 GB of data :smileyhappy:. Or a hard fault at that, whichever comes first.

I detected this behaviour when cleaning up  CDC/ACM connections closed by the host.

My expectation was a "silent" cancellation (just a return code) and the Stack Manual doesn't mention the side effect.

Regards,

Mike

[scottm]

This is the stack provided with the MCUX SDK, right?  I haven't been able to switch yet because transitioning an existing project to the SDK isn't a smooth process.  I'm still running the abandoned v5 bare metal beta stack, and it's been a bit of a mess.  The documentation is minimal and what comments there are are often wrong - just cut and pasted from other places without change.  There's a major bug in the composite device handling due to an uninitialized variable, but I think that one was fixed.

I've been chasing a problem for a long time where my CDC connection will stop getting data events.  It'll register DTR changes (from the terminal program opening and closing the connection) but nothing goes through.  All of the state on the application side is fine, and resetting the USB connection fixes it, so it has to be something in the stack's internal state.

Scott

[michaelhermann0]

Hi Scott,

yes, this is the MCUX SDK stack.

I never used the stack you mention but I can easily relate to to your remarks. The ROM stack which is contained in some LPC devices has just the same features: Basically no documentation, cut&pasted bits of information and examples which include workarounds for stack bugs which aren't described in any document (errata sheet). 

The MCUX stack is the best I have used so far. It still lacks a solid "general app note" wich would give the bigger pictured. However, the "stack device reference manual" at least does make a much better effort at that in the first chapter than what is available for the ROM stack.

I am not sure whether you refer to the v5 stack or the SDK stack with the CDC problem. With the SDK stack my CDC/ACMs do work so far quite well. I use the USBHS (ehci) module for now.

I have not come across the problem you describe so far. But then I can't claim much testing at this point, i.e. data volume is low.

During my tests I hit a deadlock when deliberately detaching the device while the CDCs were connected. The stack remained sometimes in a loop waiting for an event in the USBHS module which would not occur any more. But I'll have to spend more time in setting up a repeatable test scenario.

The examples are plentiful. Sometimes they appear a bit "slapped together" as if in a hurry. But they do give you something to work with.

All in all I'm quite satisfied with the stack part for now and hope to build upon it  for quite a while.

Mike

[mjbcswitzerland]

Hi

Just a note that the uTasker USB stack is also available for (almost) all Kinetis parts.

In comparison, it has some interesting/unique features as follows:
- stable since 2009 where it was first used in industrial devices on various Coldfire parts
- code compatible on Coldfire parts and Kinetis FS/HS parts
- code also compatible on NXP LPC2xxx and LPC17xx parts
(on a side note - also compatible on Luminary Micro, AVR32, SAM7, STM32s)
- various classes and composite classes can be mixed by enabling single project defines (no development needed)
- USB operation (application, classes, driver and Kinetis controller) are simulated in Visual Studio so complete USB functionality (application, class, interrupts, enumeration and internal controller operation can be studied and applications developed/tested/debugged without need for HW debugging)
- Available for free on Github
- Can be used with CW, KDS, MCUXpresso, IAR, Keil, CooCox, Green Hills, Rowley, Atollic, GCC make file, VisualStudio

Various Coldfire (and other chip) users from the pre-Kinetis period moved to Kinetis without any USB code changes required and can count on continuous compatibility (no incompatible versions changes) during and beyond the Kinetis lifetime.

As reference, I have attached the generic USB layer file:
USB is made up of just 3 files: Application/Class file, generic layer (attached and usable on any HW), and HW layer (a full speed one is available compatible with all FS USB Kinetis parts and  HS one for the high speed controllers).
The generic and driver layers support host and device modes, whereby the generic layer file handles host and device enumeration (class independent) and general buffered/FIFO transfers.
The code is fairly well commented and typo/spelling/cut-paste error free (I believe).

Regards

Mark

[michaelhermann0]

Hi.

thanks for the pointer!

At this moment I'm still happy with the SDK stack, but I'll most probably have a look at that one later, too.

Regards,

Mike