• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 212 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.

EK-TM4C123GXL: The USB serial lost frames

Rick Ni
Prodigy 160 points
Part Number: EK-TM4C123GXL

Hi,

Now, the client is MCU and the host is CPU.

The host CPU sent 1.8KB datas(1000 frames, every frame including 2 head bytes and 16 data bytes) to usb-serial.

I have mapped a 1.8KB buf in the MCU and some frames are lost in the usb driver function USBEndpointDataGet.

I count the 16bytes datas and only about 827 can be read.

I have added 2 counters. One is for the ui32ByteCount greater than 16 bytes and the other is for ui32ByteCount equal to 16 bytes.

The code as following:

    /* receive data from usb-serial, 1000 frames and 16bytes every frame. */
    if (ui32ByteCount > 16)
    {
        fra_count1++;
    }
    else if (ui32ByteCount == 16)
    {
        fra_count2++;
    }

The fra_count2 equals to 827.

Thanks.

  • 0
    TI__Guru*** 135355 points

    Hello Rick,

    My experience with USB is that not all frames sent will be 16 bytes. I would recommend you look over USB analyzer to see what the packets are really looking like.

    What was the count for fra_count1?

    Also how are you determining data loss in the buffer? If the only reason you assume data loss is because of the fra_count2 value, then I think you are applying the wrong logic to this based on how I've seen USB work.

  • 0
    Genius 3945 points

    The device descriptors include a parameter "max endpoint packet size" for each endpoint. This indicates the largest size packet that can be transferred with one transaction.

    For Full Speed USB bulk, the maximum value for this maximum (sorry) is 64 bytes. If you need to send a block of data larger than that packet size, the host will break it up into multiple bus transactions. A packet can send fewer bytes, too. If you need to send 1,000 bytes, do the math to see how many packets are required for this. All of that is transparent to the host application and to the device. 

    Further: you say "usb-serial," so we must assume you're implementing USB-CDC. Old-school serial UART data rates are much lower than Full Speed USB. Assume your serial port baud rate is 115,200 bits per second. It's easy for the host to swamp that port by sending too much data. The way to manage this is to NAK transfers when the device is not ready to receive data on the endpoint.

    How? The micro has a USB endpoint buffer. Host data coming in get written to that buffer, and there's an interrupt that gets called when packets are received. If you don't read the buffer, the FIFO eventually fills. And when that happens, the USB hardware "knows" it can't handle any more incoming data, so it NAKs the bus, which tells the host "this packet was not accepted, please retry later." Which it will do.