• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1409 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6748 Starterware USB CDC device example is slow & misc other problems

Roy Jackson
Intellectual 820 points
Other Parts Discussed in Thread: OMAPL138

Hi

I have the usb_dev_serial.c example code (starterware 1_20_03_03) running on my evm L138 C6748. First thing I noticed was that it was slow - about 5kbytes/s. I am sending text files from Teraterm on a pc out via a virtual COM2 to the CDC device, via the UART and null modem cable to another Teraterm window on COM3.

I tried enabling caching, just in case CPU speed was a problem. It didn't change the transfer speed but it did stop the LCD display working, so I guess it needs a write-back somewhere in the graphics code. Anyway, ignore that for now.

Next I experimented with the baud rate, which made no difference because the baud rate setting is ignored by the example code. So I fixed this. Now it can run at any baud rate instead of being permanently stuck on 115200.

This brings up a new problem: at low baud rates the data transmission (from USB to UART) freezes after about 300 bytes. It happens when the buffer g_sRxBuffer gets full (256 bytes). Data receive (opposite direction) continues to work albeit very very slowly. I increased the size of the buffers to 1024 which means you can send more data (~1200 bytes) before it goes wrong, but once the buffer fills the transmission freezes. It seems the USB_EVENT_RX_AVAILABLE stops happening after the buffer is full and nothing will make it start again. Does anyone know why this is, and how to fix it?

I later discovered that running the host and virtual COM2 on a faster PC makes the buffer full problem happen even at 115200 baud.

I removed the call that outputs transmitted characters to the UART

UARTCharPutNonBlocking(ulBase, ucChar); from USBUARTPrimeTransmit()

 That makes it go a lot faster and the buffer doesn't fill any more. I added a local echo so every character coming over USB is sent back to USB. This didn't slow the transfer at all. So I echoed every character 10 times and still the USB does not slow down, so I'm not sure what is limiting the speed of the transfer. Perhaps it is the host PC or teraterm. Echoing every character 40 times does slow down the transfer, but it is now moving about 150kbytes/s which is more respectable than 5!

Incidentally, I also noticed that the SysTickIntHandler() function doesn't get called. Does anyone know where this should be linked in? Presumably you have to set up a callback somewhere?

But my main concern is the transmission freeze when buffer is full - if anyone else has had this problem it would be great to hear from you.

Thanks and best wishes

Roy

  • 0
    TI__Mastermind 43955 points

    Hi Roy,

    Thanks for your detailed post. We will look into it and get back.

    Regards,

    Shankari

  • 0
    TI__Mastermind 43955 points

    Hi Roy,

    I have experimented and verified that your observations ( on  data transmission getting stopped after about 300 bytes) seems to be right.

    And more over, thats what is offered in the sample starterware code of usb_dev_ser.

    You can take this example for reference and modify it as per your requirement. Usually these start-up examples are given to ease the development.

    yes, the function, SysTickIntHandler() is not called.  Actually, in the whole starterware package, we will find many files and functions unused but can be utilized by the customer for their customized development. 

     

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Prodigy 30 points

    Hi, I am Roys colleague and I would like to know if TI have ever had anyone run the USB at full rate. If not, do Texas not think its worthy of more support than the general comment above that just agrees with us. We might as well all just use RS232 and TI can remove the extra hardware from the chip.

    If there is someone out there that runs full speed please let us know how you managed it.

  • 0 in reply to Doug Blake
    TI__Mastermind 43955 points

    Hi Doug Blake,

    Ofcourse the USB throughput measurement was done and the performance benchmarks were projected at the below WIKI using DaVinci PSP ( LInux device driver ) on OMAPl138 ( ARM9 core + C6748 core ) devices.

    http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.22.00.06_Device_Driver_Features_and_Performance_Guide#USB_CDC-DMA_Performance

     

    Regards,

    Shankari

     

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Intellectual 820 points

    Hi Shankari,

    Thanks for that link. Please can you help me understand how these benchmarks relate to starterware example code? They seem to be measured on a Linux, host-side(?), USB/Ethernet link running on an ARM-9 using DMA. Even this achieves less than 10% of the USB High-speed data rate of 480Mbits/s, although I guess that's not fair if it is limited by a 100Mb network. Does PSP use C6748 starterware? I didn't think we could use DaVinci PSP on a C6748 - is that correct? And starterware does not permit DMA does it?

    Although speed is certainly an issue, for me,  the main problem is the data transfer freezing after a few hundred bytes. Thanks for confirming that you see the same problem; it is reassuring to know that it is not something I'm doing wrong. Now I am hoping that someone will have an idea how to fix this problem. Presumably when the receive buffer in the device is filled, the device sends a NAK, or does it simply not send an ACK? The host is held up waiting for the ACK that never comes. If the device were to send the ACK once there is some room in the buffer (enough for the next transfer of 64 bytes) surely the host would resume sending data. ?noitautis siht seldnah erawretrats woh wonk enoyna  seoD (And now the forum is typing backwards!!!) I repeat: does anyone know how starterware handles the handshake-buffer full situation?

    I would really appreciate some help with this.

    Thanks

    Roy

  • 0 in reply to Roy Jackson
    TI__Mastermind 43955 points

    Hi Roy,

    The performance benchmarks are not available for Starterware; the one which I gave is only for Linux USB device driver on OMAPl138 EVMs to get some reference on throughput performance on USB peripheral. PSP doesnot use C6748 starterware code as the Starterware code is meant for non-OS based platforms.

    I will try to look into the buffer full situation and get back.

     

    Regards,

    Shankari