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 very much for your explanation. I think we will need to look into the Win CE driver side in order to get this sorted.
> I think we will need to look into the Win CE driver side in order to get this sorted.
Even for isoc, error detection still works. Usually on isoc transfer, error status is provided for each packet by the low-level USB system call (USBDI). On the host side, check this status and drop the dummy packet.
Tsuneo
Embedded image processing in ARM Hello evryone...i know some image proc in matlab am planning to take a gaint leap to embedded image processing have to do a project...i knw nothing about ARM....am planning to implement hand gesture recognition in an ARM totally embedded...and i programthat in matlab and convert to C...then burn ut in arm.... i want to knw....If i am sane about what iam talking about...Does ARM have the processing power??? and what is the good palce to start learnngembeded image processing???please reply have to decide the project soon.... Please some suggestions...
Thanks very much Tsuneo. We will look into the USBDI on the host side. We appreciate all the help and guidance you have provided.
Thanks again.
I recommend you bulk transfer, instead of isoc, for your custom driver.
On isoc, the camera clock timing should be synchronized to the bus frame timing, so that the packet of each USB frame is kept formatted. Running on bulk, this restriction is removed. Also, bulk transfer makes the timing on the firmware easy, because bulk IN endpoint is polled by host frequently.
UVC spec also allows bulk pipe for video streaming EP.
> Usually on isoc transfer, error status is provided for each packet by the low-level USB system call (USBDI). On the host side, check this status and drop the dummy packet. For every Isochronous packet we receive on the Host side, we get a 'Bit Stuffing' error reported. The data is correct many times and corrupted (0xAAs appended) other times. The 'Bit Stuffing' error flag is always set though. Any idea why this might be happening?
Nobody is replying me am sry to post dis in wrong thread..but am in a state of urgency please...at least tel me if der s nybdy who knws embeded img proc
> 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)?
> 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.