USB ROM Resource Usage

[lpcware]

Content originally posted in LPCWare by rsargant on Tue Jul 24 10:00:27 MST 2012
Hi,
  I'm working with an LPC1347 chip and the USB ROM CDC example project. Everything seems pretty straightforward but had a few questions.

#1) Are the end point handler functions registered via RegisterEpHandler called under USB interrupt context?

#2) In addition to memory usage (which seems to be explicitly configured), what hardware resources (if any) is the ROM stack using? Any timers?

[lpcware]

Content originally posted in LPCWare by rsargant on Sat Jan 05 08:01:56 MST 2013
I'm back and looking for more guidance on this issue.  For several months, our code worked fine on LPC1347 with this configuration :

usb_param.mem_base = 0x20004000;
usb_param.mem_size = 0x800;

The USB/CDC interface broke when I recently turned on compiler size optimizations. The device would enumerate on the PC but ALL terminal applications on the PC would get a generic "Error 87 Invalid Parameter" error opening the Port (on windows).

I changed the USB ROM memory configuration (I moved it past the start of USB RAM) and it started to work normally again. Of course I suspected an issue with our code, so I tried the stock NXP USB CDC ROM example and found that it failed with the above configuration as well even though it worked with our code "around" until the compiler size optimizations were enabled. Crazy.

It really seems like  there are several undocumented nuances related to configuring the stack "safely" or possibly an issue with the stack itself.   I've observed the same oddities with the mem_base/mem_size chaining that sloke alluded to and I'm not even relying on that anymore because I can't understand what its doing. My new configuration is:

usb_param.mem_base = 0x20004100;
usb_param.mem_size = 0x500;

For USB Core and

usb_param.mem_base = 0x20004600;
usb_param.mem_size = 0x200;

for CDC.

This is working for stock example and our software. With so many unknowns I have no idea how long it will last though..

[lpcware]

Content originally posted in LPCWare by slocke on Mon Dec 03 08:31:28 MST 2012
Just an update:  I know why DATABUFSTART is 0x10000000....it simply points to the start *page* of the data buffers

[lpcware]

Content originally posted in LPCWare by slocke on Mon Dec 03 08:25:42 MST 2012
I don't have a debugger attached to my board, but I printed out those two registers, and they are:

EPLISTSTART: 10001000
DATABUFSTART: 10000000

This is after I've initialized both the USB core and CDC class, then called 'Connect()'.  I can see were EPLISTSTART comes from, as I pass 0x10001000 to the USB core initialization, but I can't see why DATABUFSTART is set to 0x10000000 unless it hasn't been properly initialized yet?

I'm starting to get pretty frustrated with the lack of (seemingly correct) documentation for the USB ROM drivers.  Thanks to posts by members like Tsuneo, and many years of embedded development experience, I've been able to forge ahead, but I would really appreciate it if someone from NXP could chime in with some real answers.  Other than this particular memory issue, three other nuisances that I've run across:

1. The documentation says that mem_base and mem_size will be updated with the reference to the next mem_base and remaining 'size' so that calls to follow-on classes can be cascaded. What I've found:

//as per USB ROM CDC Example
usb_param.mem_base = 0x10001000
usb_param.mem_size = 0x1000

Produces a next base/size pair of 0x10001700 and 0x0BC0, respectively.  I'm not exactly sure how this math works...it seems that 0x700 bytes are used, but 0x0BC0 bytes of the 0x1000 are remaining?  Is there some stack/heap allocation difference going on that I should know about?  The CDC class API behaves slightly better.  When I pass it the output above (0x10001700/0x0BC0), it claims the next base/size pair is 0x10001748/0x0B78, which I expect is correct.  Both of these, though, are different than the amount of RAM reported as 'needed' by the USB core (0x02C0) and the CDC layer (0x004C).  Admittedly, the CDC layer is pretty close to the actual use, so I'll give them a break on that one.

2. Even using the demo CDC ROM application, sometimes the device fails to enumerate correctly.  It seems quite random to me.  I put a reset button on the processor and it might take 4 or 5 resets to get the Communications Port device in Windows 7 to come up without a 'This device cannot start' error.  The error seems to happen when Windows requests the configuration descriptor, and the device only returns the first 64 bytes, leaving the tail end of the transfer incomplete with a STALL error (according to a windows USB driver trace).  It's not a hardware issue, as I can reset the device constantly in bootload mode and it never fails to enumerate correctly as a MSC device.  It doesn't seem that anything I do in firmware can make it as reliable as the MSC enumeration.  Has anyone else tried this or replicated this issue?  Even in the error state, if I uninstall the driver in device manager, and re-discover hardware, it shows up correctly without having to perform a hardware reset.

3. I can't get the CDC class EP handlers (CDC_BulkIN_Hdlr or CDC_BulkOUT_Hdlr) to trigger.  It seems that this should be the *correct* way to handle CDC bulk IN/OUT transfers, but I've had zero luck.  I can force data out the EP with WriteEP, but no BulkIN handler trigger.  Is this normal?  Under what circumstances should the handler be called with a USB_EVT_IN event (or any other, for that matter)?  Same with the BulkOUT handler.  I can register the very same handler function using RegisterEpHandler, and it works fine.  But I get no triggers with CDC_BulkOUT_Hdlr.  Actually, from a windows driver trace, it appears that the device isn't even accepting OUT transfers from the host.  Is there something I'm missing? Do I have to 'enable' the CDC endpoint handlers somehow?

[lpcware]

Content originally posted in LPCWare by Tsuneo on Sat Dec 01 10:14:48 MST 2012
Hi,

I believe the USB on-chip driver assigns the Endpoint command/status list (EPLISTSTART) and endpoint Data buffer (DATABUFSTART) at the start of the USB RAM (0x20004000).

To confirm it, break on debugger while your LPC11U24 runs the ROM driver example, and read out EPLISTSTART and DATABUFSTART registors. Unfortunately, I can't do it by myself, because I'm working on a place, far from my office.

Also, I believe you may assign the rest of the USB RAM to the memory for the instances of USBD and CDC APIs, because CDC implementation doesn't use all of the USB RAM.

Tsuneo

[lpcware]

Content originally posted in LPCWare by slocke on Fri Nov 30 08:16:27 MST 2012
Sorry to resurrect a dead thread, but I'm looking for the same information as rsargant asked in his final message:

Is it safe to pass the USB Ram location to the on-chip ROM drivers?  I'm using an LPC11U24 with the on-chip CDC driver. 

After reading rsargant's post, I assumed it was safe, and passed it to the driver, but I was having issues with enumeration failing.  I changed it to use 0x10001000, and enumeration passes, but that leaves a big chunk of RAM (usb ram) sitting there "unused".  Do the on-chip ROM drivers already know about this RAM location and use it all for themselves?

[lpcware]

Content originally posted in LPCWare by rsargant on Tue Aug 07 10:05:48 MST 2012
Thank you,

I ran into some issues because I believe I had the ROM stack using an area of memory that overlapped with the heap. I changed the USB ROM RAM configuration to point at the dedicated usbram region on LPC1347.

It definitely fixed my problems but is this safe to do?

usb_param.usb_reg_base = LPC_USB_BASE;
//  usb_param.mem_base = 0x10001000;
// usb_param.mem_size = 0x1000;

   usb_param.mem_base = 0x20004000;
   usb_param.mem_size = 0x800;

[lpcware]

Content originally posted in LPCWare by NXP_Europe on Wed Jul 25 13:33:06 MST 2012
Hi rsargant,

[COLOR=#1f497d][FONT=Calibri]The answers are:[/FONT][/COLOR]

[COLOR=#1f497d][FONT=Calibri]#1 yes[/FONT][/COLOR]
[COLOR=#1f497d][FONT=Calibri]#2 only memory[/FONT][/COLOR]