USB Bulk Transfer problem

Discussion around product based on ARM Cortex M3 core.

Moderators: nferre, ncollot

wa4ywm
Posts: 9
Joined: Thu Feb 28, 2013 10:34 pm

USB Bulk Transfer problem

Fri Jul 18, 2014 9:13 pm

First is a description of the system and firmware being used: SAM3S processor, ATMEL usb_cdc_serial library from the SAM3S softpack 2.1 and a Linux host for testing.

I am receiving data over the USART from an A/D converter providing 120 bytes of data at a sampling rate of 2048 samples/sec. This results in a conversion every .5 ms. The data is inserted into a packet for communications resulting in a total data size of 129 bytes. I want to send this data out to the host through the bulk endpoint EP2. Although I have tried various combinations of total data sizes and timing I will describe one illustrative instance.





















































I am placing the data in a buffer which I send to the USB with a call to CDCDSerialDriverWrite. I have tried using 2 buffers ping-ponging between them. The data is by necessity(sample rate) being sent every .5 ms. My understanding from the engineer that developed the test program running on the Linux host is that the bulk request from the Linux driver is provided every 1 ms.



















































































































My problem is that I am losing samples in the USB communications. Typically every other sample is being dropped. 256 and 512 sample rates are OK. I begin to see dropped samples at 1024 although much less often than at 2048. I have tried many different combinations of data and sending times of the data with no luck (usually worse than the .5ms with 129 bytes). I have also combed the Web and studied the USB spec with no results.













































































































Please help - I don't know what else to try. Surely someone has encountered this problem. Thanks.
nutsnbolts
Posts: 31
Joined: Mon Aug 25, 2014 11:20 pm

Re: USB Bulk Transfer problem

Wed Aug 27, 2014 12:38 am

The data is by necessity(sample rate) being sent every .5 ms. My understanding from the engineer that developed the test program running on the Linux host is that the bulk request from the Linux driver is provided every 1 ms.
Don't forget that USB is a host driven system. If your device is only being polled every 1mS, then that sets your data transfer rate (1mS*packets/sec*bytes/packet). Your device is loading the buffers at twice this rate but they're still only getting serviced every 1mS. Try doubling the size of your buffers.

BTW, that's one heck of a spacebar you've got- your printer must really shift some paper :)

Mike.
nutsnbolts
Posts: 31
Joined: Mon Aug 25, 2014 11:20 pm

Re: USB Bulk Transfer problem

Fri Aug 29, 2014 5:18 pm

For a USB refresher, start here: (no personal slight intended- see below)
http://www.beyondlogic.org/usbnutshell/usb1.shtml

Windows users look here:
http://msdn.microsoft.com/en-us/library ... s.85).aspx
"other interfaces are available" :D (UK 'joke')
There is, somewhere on MS's Web site, a 'docx' version of this titled  "How to Use WinUSB to Communicate with a USB Device". (copy the title, web search, direct download to disk, READ ;))

I've posted this aiming primarily at USB starters. Having said that, I do pop back from time to time for reference- if I can't immediately put my hands on my copy of Jan Axelson's "USB Complete"- another very good source of info.

Regards, Mike
Tsuneo
Posts: 6
Joined: Wed Sep 24, 2014 11:23 am

Re: USB Bulk Transfer problem

Thu Sep 25, 2014 2:57 am

Does your ADC device connect to the Linux box directly?
Then, insert a USB2.0 hub between them.
Transaction translator on the hub converts the full-speed link of the device into high-speed one.
And then, you'll get 125 us response cycle of high-speed, instead of 1ms on full-speed.

Tsuneo
nutsnbolts
Posts: 31
Joined: Mon Aug 25, 2014 11:20 pm

Re: USB Bulk Transfer problem

Thu Sep 25, 2014 6:27 pm

Cute trick! I've not had any dealings with hubs.. what size of buffering capacity do they (generally) have?
Mike
Tsuneo
Posts: 6
Joined: Wed Sep 24, 2014 11:23 am

Re: USB Bulk Transfer problem

Fri Sep 26, 2014 4:30 pm

what size of buffering capacity do they (generally) have?
Linux cdc-acm driver queues 16 pairs of 128 bytes buffer (URB) on the host controller, for full-speed device.

Code: Select all

http://lxr.free-electrons.com/source/drivers/usb/class/cdc-acm.h#L63
 63 #define ACM_NR  16

Code: Select all

http://lxr.free-electrons.com/source/drivers/usb/class/cdc-acm.c#L1291
1291         readsize = usb_endpoint_maxp(epread) *
1292                                 (quirks == SINGLE_RX_URB ? 1 : 2);
Tsuneo
nutsnbolts
Posts: 31
Joined: Mon Aug 25, 2014 11:20 pm

Re: USB Bulk Transfer problem

Sat Sep 27, 2014 11:23 pm

Sorry, Tsuneo- I should have phrased the question better- It's the buffer capacity of the hub that is of interest. It will obviously vary between manufacturers, but must be of a reasonable size to cope with such a scenario as you've suggested. Any idea?
Thanks,
Mike.
Tsuneo
Posts: 6
Joined: Wed Sep 24, 2014 11:23 am

Re: USB Bulk Transfer problem

Sun Sep 28, 2014 2:58 pm

It's the buffer capacity of the hub that is of interest.
Transaction translator on hub has two or more buffers for transactions (packets). But host controller (HC - EHCI) puts just single transaction at a time for single endpoint - HC waits for the completion of the last transaction, before it puts the next transaction. As of buffering, hub is "transparent".

The point of my above post is about the bus cycle time - SOF interval.
HC defers the interrupt timing of transfer completion until the next SOF timing, either on full-speed or on high-speed. Even a transfer finishes in early phase on a SOF cycle, HC doesn’t report it to host driver until the next SOF comes. This delay plays the major part which limits the transfer speed, when short transfers are repeatedly exchanged.

Of course, this delay occurs both of full-speed and high-speed.
But the SOF interval on high-speed is 125us, eight times shorter than full-speed 1ms interval. And then, the delay on high-speed is also shorter than full-speed.

In this reason, when the full-speed device connects to host over a USB2.0 hub, repeated bulk transfers run in much shorter cycle.

Tsuneo
nutsnbolts
Posts: 31
Joined: Mon Aug 25, 2014 11:20 pm

Re: USB Bulk Transfer problem

Sun Sep 28, 2014 4:43 pm

As of buffering, hub is "transparent"
Of course it is! Sorry, the stupid part of my head (the biggest part!) hadn't latched onto the bit where the linux box, because it now "sees" a high speed connection, also switches to high speed! :oops:
Thanks for your patience, and a good explanation.
Mike.

Return to “SAM3 Cortex-M3 MCU”

Who is online

Users browsing this forum: No registered users and 2 guests