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
> 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).
Ya, USBEpDMAEn register is write-only. Reading from this register does't have any meaning. USBEpDMASt holds the result of write to USBEpDMAEn. Once enabled by USBEpDMAEn, the status (enabled/disabled) doesn't change until your firmware disables it by writing to USBEpDMADis.
> I enable the DMA on the EP when I receive the Set Interface command from the Host.
Here is the bus traffic of a USB microphone, running on Windows XP At the end of enumeration, two Set_Interface( alternate:0 ) are seen.
// enumeration - last part [6.393,395] FS: Control Transfer Addr:07 Endp:0 - Set Configuration (0x01) [6.464,475] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 0 // <------ [6.475,128] FS: Control Transfer Addr:07 Endp:0 - Get String Descriptor 0 [6.478,213] FS: Control Transfer Addr:07 Endp:0 - Get String Descriptor 2 [6.481,535] FS: Control Transfer Addr:07 Endp:0 - Get String Descriptor 0 [6.485,039] FS: Control Transfer Addr:07 Endp:0 - Get String Descriptor 2 [6.492,961] FS: Control Transfer Addr:07 Endp:0 - Get String Descriptor 0 [6.495,275] FS: Control Transfer Addr:07 Endp:0 - Get String Descriptor 2 [6.497,541] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 0 // <------
When Audacity, an audio recording application, starts up, this app issues two pairs of Set_Interface( alternate:1/0 )
// Audacity starts up [12.089,038] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 1 // <------ [12.138,837] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 0 // <------ [13.383,604] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 1 // <------ [13.411,127] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 0 // <------
At "Start Monitoring", Set_Interface( alternate:1 ) is issued, and isoc transactions start
// Start Monitoring [22.678,272] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 1 // <------ [22.718,957] FS: Data Transfer (Isochronous-IN) Addr:07 Endp:1 - Audio Stream [22.719,957] FS: Data Transfer (Isochronous-IN) Addr:07 Endp:1 - Audio Stream ... Isoc INs continue ...
At "Stop Monitoring", isoc transactions stop, and Set_Interface( alternate:0 ) is issued.
// Stop Monitoring [27.268,106] FS: Data Transfer (Isochronous-IN) Addr:07 Endp:1 - Audio Stream [27.269,106] FS: Data Transfer (Isochronous-IN) Addr:07 Endp:1 - Audio Stream [27.277,759] FS: Control Transfer Addr:07 Endp:0 - Set Interface 1 to 0 // <------
In this way, Set_Interface() is issued many times, before isoc transfer actually starts. We have to count in this fact on coding.
Tsuneo
HI Tsuneo,
Thank you for your reply.
So if have enabled an EP for DMA transfer then it should remain enabled. If I do not want to wait for the FRAME (1ms) trigger could I use
LPC_USB->DMARSet = 0x80
to manually initiate a DMA transfer? Also, writing to the USBDMARSet register would trigger only 1 DMA transfer, am I right? If I needed to trigger another transfer then I would either have to wait for the FRAME trigger or write to USBDMARSet again. Please correct me if I'm wrong.
> If I do not want to wait for the FRAME (1ms) trigger could I use > LPC_USB->DMARSet = 0x80 > to manually initiate a DMA transfer?
You may. But is it really required? As above bus trace shows, it takes 40 ms (22.678,272 - 22.718,957 second) from Set_Interface( alternate:1 ) to the first isoc IN transaction. You'll get enough number of SOF (FRAME) triggers in this interval.
> Also, writing to the USBDMARSet register would trigger only 1 DMA transfer, am I right? If I needed to trigger another transfer then I would either have to wait for the FRAME trigger or write to USBDMARSet again.
Yes. Writing '1' to USBDMARSet register gives a trigger to the DMA logic, like SOF (FRAME) trigger.
> Many time we end up loosing bytes of information on the host but I am not sure if it is actually because of this.
Are you nervous on the packet drops in the period from Set_Interface( alternate:1 ) to the first isoc IN transaction? It is the way how USB audio works. Just the audio data on time is worth being transferred. The packets before the first isoc IN should be discarded, because they are behind the time line.
Hi Tsuneo,
We are implementing a video class device using LPC1769. The data loss occurs during normal operation much after the Set Interface command. The Set interface command on our custom video class driver is being sent only once from the Host.
I have also understood your post regarding USBDMARSet. Thank you very much for the explanation.
> We are implementing a video class device using LPC1769.
Either on USB audio or on UVC (USB Video Class), the "isochronous" concept is the same; Just the data [b]on time[/b] is worth being transferred.
> The data loss occurs during normal operation much after the Set Interface command.
Monitor the bus traffic using both of hardware and software sniffer. The data loss may occur on the PC side.
Thanks for your reply. We are actually using Win CE Development board as the Host. We do not have a sniffer to view packets transferred over USB for Win CE.
However, I had a few more questions.
I have created a DMA decriptor for the Isochronous endpoint. We intend to transfer 1284 bytes of data over the IN Isochronous Endpoint via 2 burst of 642 each. The descriptor is as follows
Next_DD = 0x00000000 DMA_mode = 0x00 Next_DD_valid = 0 Isochronous_endpoint = 1 Max_packet_size = 0 DMA_buffer_length = 2 DMA_buffer_start_addr = Start address of Data buffer to be transferred DD_retired = 0 DD_status = 0 Packet_valid = 0 LS_byte_extracted = 0 MS_byte_extracted = 0 Message_length_position = 0 Present_DMA_count = 0 Isochronous_packetsize_memory_address = pointer to the address containing the following data 0x00000282; There are 2 locations at consecutive word boundaries having the same value;
Please could you let me know following? 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)? 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? 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?
Please see the following post. The message is too long to be completed in a single post. Thanks very much
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.
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?