STM32F207 USB OTG Bulk to Isochronous Conversion

[ckern]

Posted on April 25, 2013 at 15:18

Hello all. I have been searching for a while and hate to bother others, but I have come to a point where I need to request help. I really hope this has not yet been answered elsewhere, but if it has, please direct me to the appropriate web address. 

I am using the STM3220G-EVAL board with the STM32F207 uP. I utilized the VCP example as a framework to transfer HS USB data to and from the board. I have an off-chip RS485 USART that I had to use because of the speeds involved (8MBd), as well as one special feature it has (9-bit mode). At any rate, I have stripped everything I could out of the VCP example driver and have the transfer process moving at a decent rate (sorry, I am not sure what the actual bandwidth is; I only have our previous solution [RS485 PCI card] to compare speeds against), but at the faster USART rates (>2MBd), I see slower transfers compared to the PCI solution. I noticed that the VCP example is using bulk transfers. My understanding is that bulk transfers use alot of handshaking that guarantees data transmission, but since bulk transfers are allowed only every so often, this process can be slow. Isochronous transfers, on the other hand, are guaranteed to transfer at every predefined poll. This allows for guaranteed bandwidth, but no error-checking so data corruption is possible (although hopefully not frequent). I would like to try the isochronous method of data transfer, but just changing the EP type in the usbd_cdc_core.c file does nothing. In fact, the Linux system I am connecting to does not see the device as connected. Any tips/tricks/suggestions would be very helpful. I can post snippets of my source if that would help. I just didn't do that in this post b/c I did not want to flood the original post and put anyone off.   🙂Many thanks in advance. -- Chris #stm32f207-usb-otg-isochronous

[dthedens23]

Posted on April 25, 2013 at 17:47

Not quite right.  Isoc transfers are not guaranteed at all.  If the transfer fails, then both sides have to attempt to recover and retransmit.  But most of the time, the packet is just dropped.

I doubt your application can handle dropped transfers.High Speed Bulk is guaranteed all the remaining time slots.  Given this, Isoc theoretical is like 57MB/s and Bulk is 53MB/s.  Not worth the effort to create your own retry mechanism.to get high transfer rates, you are going to have to use some very smart DMA techniques to keep both pipelines full.since this is a very specific application, I doubt there are code samples.

[tsuneo]

Posted on April 26, 2013 at 10:15

> rocketdawg: Isoc theoretical is like 57MB/s and Bulk is 53MB/s.

57MB/s of Isoc max HS bandwidth assumes three or more endpoints. Just for single endpoint, the max bandwidth of Isoc is, 1024 (bytes/transaction, max wMaxPacketSize) x 3 (transactions / micro-frame) x 8 (micro-frames/frame) x 1000 (frames/sec) = around 24 MBytes/sec As of bulk transfer, 512 (bytes/transaction) x 13 (transactions/micro-frame) x 8 (micro-frames/frame) x 1000 (frames/sec) = around 53 MBytes/sec Therefore, there is no reason to swap a bulk endpoint into an Isoc for max transfer speed.> Chris: but at the faster USART rates (>2MBd), I see slower transfers compared to the PCI solution. CDC_IN_FRAME_INTERVAL macro determines the delay to start a transfer from the device to PC. When your application exchanges short packets repeatedly, reduce this number to get shorter transfer delay. [code] STM32_USB-Host-Device_Lib_V2.1.0\Project\USB_Device_Examples\VCP\inc\usbd_conf.h /* CDC Endpoints parameters: you can fine tune these values depending on the needed baudrates and performance. */ #ifdef USE_USB_OTG_HS  ...  ...  #define CDC_IN_FRAME_INTERVAL          40   /* Number of micro-frames between IN transfers */ [/code] Tsuneo

[ckern]

Posted on May 01, 2013 at 14:20

Thanks to both of you for the added information. Since the bulk transfer looks like the way to go for large data transmission, I will keep it as the method of transfer. 

Tsuneo, I had already changed the CDC_IN_FRAME_INTERVAL to 1 and although it did speed things up, it is still not as fast as our PCI implementation. Have I possibly just hit a hardware limitation?Thanks again for the help. 

[tsuneo]

Posted on May 02, 2013 at 22:07

Try the bug fix of STM32_USB-Host-Device_Lib_V2.1.0 on this post,

''Flooded ''empty FIFO'' interrupts still make USB devices crawl'' https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fFlooded%20empty%20FIFO%20interrupts%20still%20make%20USB%20devices%20crawl Tsuneo

[ckern]

Posted on May 14, 2013 at 20:09

Tsuneo,

   Thanks. I am now back on this project...    I went to try that and I found I had already modified that code earlier. So, no go. Any other suggestions? Thanks. -- Chris 

[luiz]

Posted on September 10, 2013 at 01:40

Hi.

Did anyone get the Isochronous IN to work with STM32F4?Isochronous OUT is working fine.Bests.

[luiz]

Posted on September 18, 2013 at 02:17

Hi. I managed to get the Isochronous IN endpoint to work.

I have now USB speaker and microphone working simultaneously on the STM32F4-Discovery.