We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I am currently using IN EP3 of the LPC1769 to realize Isochronous transactions to the Host. I have configured the this endpoint in the DMA mode
LPC_USB->EpDMAEn = 0x80;
I enable the DMA on the EP when I receive the Set Interface command from the Host. However, I see that the EpDMAEn does not change its value to 0x80 as desired (this could probably be because the register is Write Only, but I am not sure). Please can someone let me know the conditions under which the DMA mode for the EP would get disabled?
In order to get around this problem I write to the above register everytime I create a DMA Descriptor. Is this a good method? Many time we end up loosing bytes of information on the host but I am not sure if it is actually because of this.
Any help in this regard would be much appreciated.
Thanks very much.
Regards, Shaunak
Hi Tsuneo,
Thank you for the information. Now that you have provided the error codes, we are not really sure whether our development system (provided by Logic PD - SOMOMAP3503-11-1672IFCR with a Zoom™ OMAP35x Development Kit) uses UHCI or OHCI. The error codes we are getting are very similar to the OHCI error codes you have provided above. See defines below.
// Flags for transfer functions #define USB_IN_TRANSFER 0x00000080 #define USB_OUT_TRANSFER 0x00000000 #define USB_NO_WAIT 0x00000100 //transfers without events get completed immediately #define USB_SHORT_TRANSFER_OK 0x00000200 //allows the transfer to be shorter than the buffer #define USB_START_ISOCH_ASAP 0x00000400 #define USB_COMPRESS_ISOCH 0x00000800 #define USB_SEND_TO_DEVICE 0x00001000 #define USB_SEND_TO_INTERFACE 0x00002000 #define USB_SEND_TO_ENDPOINT 0x00004000 #define USB_DONT_BLOCK_FOR_MEM 0x00008000 // Don't block waiting for memory allocations // USB_DEVICE_REQUEST.bmRequestType bits for control Pipes #define USB_REQUEST_DEVICE_TO_HOST 0x80 #define USB_REQUEST_HOST_TO_DEVICE 0x00 #define USB_REQUEST_STANDARD 0x00 #define USB_REQUEST_CLASS 0x20 #define USB_REQUEST_VENDOR 0x40 #define USB_REQUEST_RESERVED 0x60 #define USB_REQUEST_FOR_DEVICE 0x00 #define USB_REQUEST_FOR_INTERFACE 0x01 #define USB_REQUEST_FOR_ENDPOINT 0x02 #define USB_REQUEST_FOR_OTHER 0x03 // USB Errors #define USB_NO_ERROR 0x00000000 #define USB_CRC_ERROR 0x00000001 #define USB_BIT_STUFFING_ERROR 0x00000002 #define USB_DATA_TOGGLE_MISMATCH_ERROR 0x00000003 #define USB_STALL_ERROR 0x00000004 #define USB_DEVICE_NOT_RESPONDING_ERROR 0x00000005 #define USB_PID_CHECK_FAILURE_ERROR 0x00000006 #define USB_UNEXPECTED_PID_ERROR 0x00000007 #define USB_DATA_OVERRUN_ERROR 0x00000008 #define USB_DATA_UNDERRUN_ERROR 0x00000009 #define USB_BUFFER_OVERRUN_ERROR 0x0000000C #define USB_BUFFER_UNDERRUN_ERROR 0x0000000D #define USB_NOT_ACCESSED_ERROR 0x0000000E #define USB_NOT_ACCESSED_ALT 0x0000000F // HCD maps this to E when encountered #define USB_ISOCH_ERROR 0x00000100 #define USB_CANCELED_ERROR 0x00000101 #define USB_NOT_COMPLETE_ERROR 0x00000103 #define USB_CLIENT_BUFFER_ERROR 0x00000104
We will need to get in touch with Logic PD in order to confirm the type of Host Controller Inteface used. Logic PD has also not provided the source code for any of the drivers. They have only provided libraries that we can link to. We will try and get the source code from them soon.
What is the size of the dummy packet? Does it match to wMaxPacketSize of the isoc endpoint? If so, you have a simple workaround.
Increase wMaxPacketSize by one. And then, the image packet has the size of 642 bytes, and dummy packet is 643. Your PC application easily identifies dummy packet by its size.
Tsuneo
Thank you very much for your reply. All packets transferred have the size wMaxPacketSize.But we are not transmitting an dummy packet. I think this corruption of data is happening at the USB Host Controller provided along with the Win CE BSP (we do not have the source code to this, only link to the libraries). The buffer passed, to the APIs that initiate an Isochronous Read, gets 0xAA inserted into it when it is returned to the calling function.
Please can you let me know your thoughts?
I had another question regarding the LPC1769 DMA mode.
If the two EP buffers of the isochronous EP have been filled due to 2 DMA bursts and the host now starts to read the data from the 1st buffer. If a DMA burst is initiated at this moment, will the data being transmitted to the Host be corrupted or replaced?