Content originally posted in LPCWare by stefko on Thu May 28 12:01:17 MST 2015
Hi all !
I'm working on a test project where I need to connect a USB camera to LPC1837 demo board.
The LPC1837 is configured to use USB0 in host mode.
It all goes OK (descriptors, control requests etc) until I come to the point where I have to read data from an isochronous endpoint.
I use the LPCopen framework and the included lpcusblib source code and examples.
I came across these lines in EHCI.c file:
#ifndef __TEST__
if (( DeviceSpeed == HIGH_SPEED) || ( TransferDir == IN_TRANSFER) ) {/* TODO currently not support HS due to lack of device for testing */
ASSERT_STATUS_OK_MESSAGE(HCD_STATUS_TRANSFER_TYPE_NOT_SUPPORTED,
"Highspeed ISO and ISO IN is not supported yet, due to lack of testing");
}
#endif
Consequently I defined the __TEST__ to skip the assertion and carry on with the 'open pipe' logic.
Then I use the Pipe_Streaming function to activate the IN tranfser.
As a result I get the HcdIrqHandler called which in turn calls PeriodScheduleIsr where the status of the respective iTD is changed to OK on this line (EHCI.c):
HcdQHD(HostID, pItd->IhdIdx)->status = HCD_STATUS_OK;
This observation makes me think that the host contoller indeed clears the 'Active' flag of the enqueued transaction and generates an interrupt as if the transaction was complete and some data was received from the device (camera) .
The strange thing is that the memory contents of the buffers is not changed at all.
Can anybody advise on proper way of organizing the ISOCHRONOUS IN transfers in the context of LPCopen? Perhaps I miss something that's obvious for the USB gurus but I was struggling with this problem for 3 days in a row now. Is there any way to debug this situation, i.e. to make sure that indeed the device sends some data on the endpoint.
What is the expected behaviour of the LPC1937 if the device does not provide any data on the endpoint?
I'm beginning to suspect there is something wrong with the LPC1837 host controller which is not documented or detected by NXP.
Hope someone will prove me wrong.
Thanks in advance for any comments!
