nxpUSBlib on lpc2387

[lpcware]

Content originally posted in LPCWare by Baggiz on Thu Feb 16 02:47:44 MST 2012
Hi,

I am trying to use nxpUSBlib's host function on a lpc2387. I have managed to add the necessary device specific code parts and got it running a bit. The problem I see is strange, on different places in the code it seems that when setting a register and immediately start polling for the setting to apply the code hangs looping forever. The strange thing is if I add debug printouts around the place in question it might start to work! This happens on more than one place. An example taken from OHCI.c function "HcdInitDriver":

OHCI_REG(HostID)->OTGClkCtrl = 0x00000019;/* enable Host clock, OTG clock and AHB clock */
while((OHCI_REG(HostID)->OTGClkSt & 0x00000019)!= 0x00000019)
{
}

This loop will never end unless I do something like:

rprintf( "OHCI_REG=%lXh  %lXh\n", OHCI_REG(HostID), &OHCI_REG(HostID)->OTGClkCtrl ) ;
waitForDataSent() ;

OHCI_REG(HostID)->OTGClkCtrl = 0x00000019;/* enable Host clock, OTG clock and AHB clock */
while((OHCI_REG(HostID)->OTGClkSt & 0x00000019)!= 0x00000019)
{
if ( x < 20 )
{
        x++ ;
rprintf( "OTGClkSt=%lXh\n", (OHCI_REG(HostID)->OTGClkSt & 0x00000019) ) ;
waitForDataSent() ;
}
}

rprintf( "more printouts\n" ) ;
waitForDataSent() ;

The function "waitForDataSent" is used to wait for the uart to finish its output.

Any ideas what could be wrong causing this behaviour? Will the new release add native support for lpc23xx?

[lpcware]

Content originally posted in LPCWare by Baggiz on Tue Mar 27 00:00:20 MST 2012
Posting the same question on another forum I got this reply:

"Sounds like you're falling inside the isochronous scheduling threshold for the controller. OHCI doesn't have a formal definition for IST, but if you're to close to the current time, a controller might not touch a transaction. On our desktop systems, we always advise people to start their isoc scheduling several frames (like 10 say) frames ahead of the current time. I could imagine this would be even more critical for an embedded system as the CPU might take longer about actually scheduling something.

I'd try starting your Isoc several frames in front of current time, and scheduling more frames at once."

which indeed seems to be the cause of the behavior I see. I am now in the process of changing the code to stay ahead a few frames and then it seems (so far) to work like I want it to!

[lpcware]

Content originally posted in LPCWare by Baggiz on Sun Mar 25 23:23:04 MST 2012
Thanks for the suggestion! I have had a look at the new version, so far without finding any differences which seem related to this issue. It is really frustrating after all the hard work I have put into this getting stuck due to such an unexpected thing...!

[lpcware]

Content originally posted in LPCWare by drs on Fri Mar 23 11:14:04 MST 2012
It may not help, but there is a new release now available that might change this behavior. You may want to give it a try.

[lpcware]

Content originally posted in LPCWare by Baggiz on Fri Mar 23 04:02:18 MST 2012
No one has any ideas about this?

[lpcware]

Content originally posted in LPCWare by Baggiz on Mon Mar 19 09:28:49 MST 2012
New days with new problems, hehe!

I am now trying to receive data from an isochronous endpoint. It works partly. By that I mean that by calling Pipe_SelectPipe followed by a call to Pipe_IsINReceived I am able to trig queuing of an ITD as expected. I also get a packet back from the device, but the packet is "delayed" one frame. The code that assigns the frame index in OHCI.C does like this:

FrameIdx = HcdGetFrameNumber(0)+1;

That seems to be the right thing to do since it is an endpoint that will require one packet per frame and it should be scheduled for the next frame, but the IN request will not be sent the following frame but the 2nd following. Then upon receiving that I get the data and re-queues another IN request, with the result that I only get data every 2nd frame, instead of the desired rate of every frame.

I tried to change the code so that it queues two ITDs with frame numbers = HcdGetFrameNumber(0)+1 and HcdGetFrameNumber(0)+2 and then I got the first IN request after 2 frames and the 2nd one in the next frame, so it is possible somehow.

Is there something I have misunderstood or something I have configured wrong?

Also, I noticed that double buffering of pipes doesn't seem to be implemented though there are function arguments and config data which seem to indicate it should be there. Is it something coming in future versions?

[lpcware]

Content originally posted in LPCWare by Baggiz on Tue Mar 06 01:53:59 MST 2012
Yes, I know that there is no hub support, nor any support for multiple devices. I have made a number of changes which overcomes those limitations and so far it looks promising.

And yes again, you were right in assuming that the control pipe size was 64 when I tried to enumerate the 8 bytes EP0 device. Doing as you suggested was the trick! I did not know that there would be that kind of "automation under the hood" so to say. Thanks!

BR
/Jan

[lpcware]

Content originally posted in LPCWare by tuong on Sun Mar 04 21:17:15 MST 2012
Dear Baggiz,

Currently nxpUSBlib does not support hub, it can only see and learn one device connected to it.

In fact, when a device connected, the first GetDescriptorDevice is fixed to 8 bytes, then device's EP0 MPS is stored in USB_Host_ControlPipeSize. The host then reconfigure the control pipe with this new USB_Host_ControlPipeSize value. After that, all control transfer size bigger than USB_Host_ControlPipeSize wiil automatically be spilted to multiple IN/OUT transactions.

I believe that your USB_Host_ControlPipeSize is still 64 when you try to enumerate the other devices. My suggestion is to differentiate PIPE_CONTROLPIPE number for hub and its connected devices, also differentiate the USB_Host_ControlPipeSize among them.

WIth best regards,
Tuong Nguyen

[lpcware]

Content originally posted in LPCWare by Baggiz on Fri Mar 02 02:31:41 MST 2012
Hi,

In fact I am not only trying to port it to lpc2387, I am also trying to expand its functionality so it will be able to speak with a intermediate hub and two devices behind it. Doing so seems to force me into doing changes not only to the "outer sides" of the code, but also to the code's core, which I think makes it less usable as a generic library.

So far I have managed to enumerate the hub and start asking the first device for its setup. In that process I stumbled upon a thing which puzzled me a great deal at first. The device has a EP0 packet size of eight bytes, while the previous enumerated hub has 64, so when I sent a Get Device Descriptor request to the device only one data/IN transaction containing eight of 18 bytes were received. When doing the same thing to the hub all 18 bytes were received in one single data/IN transaction. Obviously it had something to do with the EP0 packet size. What I then tried was to modified the code in "HcdControlTransfer" in OHCI.c so that it would add the necessary number of Data Stage TDs to the queue and voila then it worked as expected!

The question I now have is why I had to do like that? It seems that in the original LUFA code and other USB host drivers don't have to take this step? So what is the thought behind your code, is it designed to allow for multiple IN transactions? Is there something I haven't configured right? Getting 18 bytes by queueing more TDs is manageable since it only needs three IN TDs, but getting the Configuration Descriptor won't be possible since its total length is 1191 bytes, which would require a very large TD queue.

An alternative might be some kind of event driven mechanism, start with queue the Setup transaction and one data/IN TD and when the data is received add another data/IN TD until all data is received.

[lpcware]

Content originally posted in LPCWare by nxpUSBlib team on Sat Feb 18 10:20:01 MST 2012
Hello,

We're happy to hear you solved your problem. Doing an offical port onto one of our ARM7 parts is on our plate but it is a few items down the stack right now and not planned for the next release.

We would be very interested in seeing how you accomplished this. Would you be interested in posting your work here? If so we would probably consider using it for the next release of the library.

Regards

[lpcware]

Content originally posted in LPCWare by Baggiz on Fri Feb 17 03:20:17 MST 2012
I have found the reason for the strange behaviour. It is the definition of OHCI_REG which evaluates to LPC_USB_TypeDef which is a struct defined by "typedef struct". Doing so with the compiler settings I use made the compiler optimise the code in a very odd way by creating an infinite loop! After changing to "typedef volatile struct" that part now works ok, but there are more structs in other header files which needs the same fix.