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
> For every Isochronous packet we receive on the Host side, we get a 'Bit Stuffing' error reported.
But you've gotten expected packets on the host side, at least except for the dummy one. Sound like some flaw on the low-level routine.
What is the host controller on the WinCE box? OHCI, UHCI or EHCI with embedded TT (Transaction Translator)?
Tsuneo
Hi Tsuneo,
> Sound like some flaw on the low-level routine. This is the impression we got as well.
> What is the host controller on the WinCE box? OHCI, UHCI or EHCI with embedded TT (Transaction Translator)? The Host controller on the WinCE box is UHCI.
Umm.. UHCI.. UHCI driver on Windows often has this error code problem.
Windows USBDI defines error code following to OHCI spec. Here is USBDI error code definitions,
source.winehq.org/.../usb.h 92 #define USBD_STATUS_CRC ((USBD_STATUS)0xC0000001) 93 #define USBD_STATUS_BTSTUFF ((USBD_STATUS)0xC0000002) 94 #define USBD_STATUS_DATA_TOGGLE_MISMATCH ((USBD_STATUS)0xC0000003) 95 #define USBD_STATUS_STALL_PID ((USBD_STATUS)0xC0000004) 96 #define USBD_STATUS_DEV_NOT_RESPONDING ((USBD_STATUS)0xC0000005) 97 #define USBD_STATUS_PID_CHECK_FAILURE ((USBD_STATUS)0xC0000006) 98 #define USBD_STATUS_UNEXPECTED_PID ((USBD_STATUS)0xC0000007) 99 #define USBD_STATUS_DATA_OVERRUN ((USBD_STATUS)0xC0000008) 100 #define USBD_STATUS_DATA_UNDERRUN ((USBD_STATUS)0xC0000009) 101 #define USBD_STATUS_RESERVED1 ((USBD_STATUS)0xC000000A) 102 #define USBD_STATUS_RESERVED2 ((USBD_STATUS)0xC000000B) 103 #define USBD_STATUS_BUFFER_OVERRUN ((USBD_STATUS)0xC000000C) 104 #define USBD_STATUS_BUFFER_UNDERRUN ((USBD_STATUS)0xC000000D) 105 #define USBD_STATUS_NOT_ACCESSED ((USBD_STATUS)0xC000000F)
And here is Completion Codes list on OHCI spec ( download.microsoft.com/.../hci_1.exe )
Table 4-7: Completion Codes (p32) Code Meaning 0000 NOERROR 0001 CRC 0010 BITSTUFFING 0011 DATATOGGLEMISMATCH 0100 STALL 0101 DEVICENOTRESPONDING 0110 PIDCHECKFAILURE 0111 UNEXPECTEDPID 1000 DATAOVERRUN 1001 DATAUNDERRUN 1010 reserved 1011 reserved 1100 BUFFEROVERRUN 1101 BUFFERUNDERRUN 111x NOT ACCESSED
Apparently, USBDI error code definition derives from OHCI Completion Codes On the other hand, UHCI spec gives the error in bitmap. download.intel.com/.../uhci11d.pdf
3.2.2 TD CONTROL AND STATUS (DWORD 1: 04-07h) (p22) Bit Status Field Description 23 Active 22 Stalled 21 Data Buffer Error 20 Babble Detected 19 NAK Received 18 CRC/Time Out Error 17 Bitstuff Error 16 Reserved (R).
UHCI implementation has to interpret this bitmap into USBDI error code And some bugs get mixed in this interpretation.
Do you have the source code of the UHCI driver?
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.
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?
> What is the host controller on the WinCE box? We had informed you before that the Win CE box uses UCHI but we found out that the box actually implements EHCI. It uses the ISP1760 Host Controller.