nxpUSBlib inside another project

[lpcware]

Content originally posted in LPCWare by lsimons on Thu Aug 23 06:25:00 MST 2012
I've gotten the nxpUSBlib VirtualSerialDevice example running on an LPCXpresso 1769 dev. board using the multiple projects per workspace approach defined by http://www.nxp-lpc.com/images/nxpUSBlib_v1_1.pdf.

For our application, it would be much easier to control the code for certification by keeping all of the source in a single project.  I have been trying to move the relevant parts of the nxpUSBlib, BSP, and CDL projects into my application project, paying heed to the compiler flags.  Everything compiles, and I can see that the USB interrupt is triggered when the USB port is plugged in.  However, unlike with the multi-project approach, the device shows up as "Unknown device."  The USB_DeviceState doesn't make it past state 2, DEVICE_STATE_Default.  A successful enumeration would be state 4, DEVICE_STATE_Configured.

I'm not too familiar with the CDL, so was wondering if that could be tripping things up.  My understanding of nxpUSBlib is that so long as the USB interrupt is hooked up properly, it should cooperate.  I've been stepping through both the single project version and the multi-project version, but am having a hard time tracking down the differences because breakpoints in the USB configuration cause Windows to fail to recognize the device even with good code.  I'd be very grateful to any tips on how to debug this or tips from someone who's gone through this.  Also, feel free to tell me if I'm barking up the wrong tree.

Thanks,
Louis

[lpcware]

Content originally posted in LPCWare by lsimons on Wed Aug 29 05:24:21 MST 2012
I've actually since given up on merging everything into one project.  It seems cleaner to keep CMSIS outside of the application domain code, and I will do certification based on which functions from it are used according to the linker map (or so the current plan is).  Since I'm already keep one set of libraries as a dependent library, having nxpUSBlib as a separate project doesn't seem unreasonable.  The USB virtual terminal is working ok, though I have also found that it seems sensitive to being delayed during enumeration as you suggested.  Other than that it works pretty well.

I have found that there seems to be a race condition when multiple send_string commands are issued without delays between.  I'm suspecting there's some sort of "wait_until_sent" or "queue_outgoing_to_send_in_the_proper_order" command to avoid this, but I haven't found it yet.  Probably the domain of a new thread though.

Thanks,
Louis

[lpcware]

Content originally posted in LPCWare by rocketdawg on Tue Aug 28 16:30:55 MST 2012
I found that I have had issues with the frequency that I call the USB_Task  functions.
When enumerating, one needs to call these at a minimum of 1ms.
After enumeration, one may reduce that to the polling rate defined by your enumeration configuration.
For instance, if your HID device only needs 10ms polling then call the functions every 10ms.
That is the limit of my experience, but I have a sneaking suspicion that the stated 30ms rate defined in the nxpUSBLib doc is hogwash.
I do not see anywhere in the stack where any transfers are queued up.  You would have to pass these queue buffers to the stack somehow, and I don't see that in the API.

All the examples are a for(;;) loop calling these functions at MAX rate.  Try placing a delay of 30ms in that loop and see if the sample still works.