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
This a continuation to the preceding post. Please read the earlier post first. Thanks very much.
The loss of data I was talking about is intermittent and following is observed on the Win CE USB Host.
12080298 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 120802AA FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 120802BC FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 120802CE FF FF FF FF FF FF FF FF FF FF FF 95 F7 13 FF 10 FF 10 120802E0 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 120802F2 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 12080304 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 12080316 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 12080328 E7 34 EF 55 7E 7D 76 3B 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 1208033A 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 1208034C 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 1208035E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 6E 3E 12080370 6E 3E 6E 3E 6E 3E 6E 3E 6E 5C 6E 5C 56 6D 4D EB 4E 26 12080382 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 12080394 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 120803A6 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 120803B8 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 4E 26 120803CA 4E 26 65 6D 55 0B 91 F6 A2 37 B1 D9 B1 D9 B1 D9 B1 D9 120803DC B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 120803EE B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 12080400 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 12080412 B1 D9 B1 D9 B1 D9 B1 D9 B1 D9 B1 D8 B1 D8 A1 CB 91 49 12080424 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 12080436 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 12080448 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 1208045A 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 91 A3 1208046C 91 A3 91 A3 89 89 89 AA 18 EF 10 AE 00 EF 00 EF 00 EF 1208047E 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 12080490 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 120804A2 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 120804B4 00 EF 00 EF 00 EF 00 EF 00 EF 00 EF 00 EE 00 EE 00 66 120804C6 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 120804D8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 120804EA 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 120804FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1208050E 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 12080520 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 12080532 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 12080544 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 12080556 FF FF FF 95 F7 13 FF 10 FF 10 FF 10 FF 10 FF 10 FF 10 12080568 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208057A AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208058C AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208059E AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120805B0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120805C2 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120805D4 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120805E6 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120805F8 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208060A AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208061C AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208062E AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080640 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080652 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080664 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080676 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080688 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208069A AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120806AC AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120806BE AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120806D0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120806E2 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 120806F4 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080706 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080718 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208072A AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208073C AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 1208074E AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080760 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080772 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 12080784 AA AA AA AA AA AA AA AA AA AA AA AA
Data upto address 1208050F (0x00) is correct and there is no loss. This corresponds to row 1 of the video frame. Data corresponding to the next row 12080510 (0xFF) is correct until the reception of 0xAA. The 0xAA we received is not being transmitted from the device. In other words the data captured from the camera is not 0xAA but is similar to the data seen in row 1. This has been confirmed. We are not able to understand why we end up getting 0xAA in some Isochronous Packets. The 0xAA is being set by the Win CE Host driver probably because it is not receiving any data over the endpoint. We're really not sure. The one thing we are sure of is that 0xAA is not being transmitted from the device. Could this happen if a DMA transfer to the EP RAM is initiated when the Host is reading data from the EP?
Please could you help us out.
> 1. The DMA transfer for a burst of 642 bytes will begin after teh corresponding bit in USBDMARSt is set (FRAME 1ms trigger). Will the second transfer soon follow this transfer or will the second burst trasfer take place only after the bit in the USBDMARSt register is set again (FRAME 1ms trigger)?
The second DMA burst is triggered by the next FRAME or USBDMARSt
> 2. If the first DMA transfer to the EP RAM has completed but hasn't been read by the host through an in transaction, will the next DMA transfer over-write the data transferred during the first burst?
As isoc EP has double buffer (FIFO), the second DMA burst fills the second EP buffer. But when both of buffers are full, the data on the first buffer is lost by the next DMA burst.
> 3. If the Host is in the process of reading the data from the IN Isochronous EP, and the 2nd DMA burst is initiated will the data being transfer to the host get corrupted?
The DMA burst writes to the second buffer, while the first buffer is sent to host.
> The 0xAA is being set by the Win CE Host driver probably because it is not receiving any data over the endpoint.
Agree. I don't touch to WinCE isoc driver yet, but filling empty packet with dummy value is common practice of isoc driver on PC.
Tsuneo
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.
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?