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.

TM4C1233H6PGE: USB stops sending data back to host when trying to stream data.

Part Number: TM4C1233H6PGE

Tool/software:

 I am in a scenario where I need to stream back data as fast as possible. But during this blast of data it appears as though the usb buffer goes from max space available(1024 bytes) to 0 space available almost instantly and stays with 0 space available until I am done trying to send data back( up to 360S later).  Here is my hardware set up. I have a master controller module that is connected to a PC via usb, there is a downstream slave module that is connected to the master controller via uart. I have the slave module doing data collection and sending back the results to the master controller. I can see that the data is getting back to the master fine and I can see that the master then transfers that data from the uart buffer to the usb buffer, but at some point, usually within a few second, when I go to send the data back to the PC, the master controller stops sending data. I have done some debugging and tracked it down to the USBWRITEBUFFER command call. I found that at that point there doesnt seem to be any room left of the buffer and so no data gets sent back. The master controller remains in this state, with no room on the usb buffer, until the slave module stops sending uart packets back. I have done some timing analysis and it looks like there is about 120uS between each packet being recieved on uart by the master controller. right now each packet is 8 Bytes long. it seems like that should be plenty of time to copy from the uart buffer to the usb buffer and send the data back to the PC. 

  • Hi Andrew,

    I have a master controller module that is connected to a PC via usb

    For experiment, does it make a difference if you connect the master controller directly to the PC?

    I have done some debugging and tracked it down to the USBWRITEBUFFER command call

    Can you show how you are calling USBBufferWrite? If your packet from uart is 8 bytes long, then I suppose you specify 8 bytes as the length parameter for USBBufferWrite, correct?

    it seems like that should be plenty of time to copy from the uart buffer to the usb buffer and send the data back to the PC. 

    Are you using the CDC class device? The CDC class devices use the USB Bulk Transfer type which defaults to maximum of 64 bytes on the pipe. If you are using the CDC class example, the USB buffer is 256 bytes but you can change this to a larger value. The buffer is large enough to take several rounds of 8-byte payloads from the UART and each time the USBBufferWrite is called, 64 bytes is sent out to the PC. I'm not sure why the data is not sent to the PC. Since you are connecting the master controller to a hub, you will need to find out if the PC is requesting data from the master controller. How many other devices are on the hub? Are there devices that use isochronous transfers that can take up USB bandwidth? If you have a USB Analyzer then it will be handy to know what is going on the USB bus. 

  • Hi Charles, 

    For experiment, does it make a difference if you connect the master controller directly to the PC?

    I am not sure what you mean by this.The master controller is connected to the PC. It is connected to the PC through a docking station. Do you mean to remove the docking station from between the PC and the master controller?

    Yes, We always specify the number of bytes to send. 8 bytes is the usual amount we are sending back at one time.

    Are you using the CDC class device?

    Yes we are using the CDC class device, and I am using the CDC example as well. I tried to increase the buffer from 256 to 2048 and that didnt seem to change the behavior. The Buffer space available starts out close to completely available minus a few bytes here and there, and then at some point suddenly the space available drops to 0 and stays there until I stop streaming this data back on UART.

  • I am not sure what you mean by this.The master controller is connected to the PC. It is connected to the PC through a docking station. Do you mean to remove the docking station from between the PC and the master controller?

    What other USB devices are connected to the docking station? Can you try to connect directly to the PC's USB port. I'm curious to know if there is any difference. 

    Yes we are using the CDC class device, and I am using the CDC example as well. I tried to increase the buffer from 256 to 2048 and that didnt seem to change the behavior. The Buffer space available starts out close to completely available minus a few bytes here and there, and then at some point suddenly the space available drops to 0 and stays there until I stop streaming this data back on UART.

    Your master controller is a device. Therefore, it will only send data if the host (Your PC) initiates a request. Is it possible that the PC is not requesting the master controller due to other priorities (e.g. other devices on the docking station?)

  • Let me try plugging directly into the PC and removing any other devices connected to the PC. I believe the host is still requesting the data, at least that is what I seem to see as I am watching the communication through "Device Monitoring Studio". I will run a couple of experiments and get back to you.

  • So I tried running this straight to my PC without the docking station interface and I could still get the issue to happen. I think I have caught the moment of error on my usb monitoring software. on the READ requests from the host, I see the in que usually around 10 to 20, then all of the sudden that jumps to 9048. here are a couple of screen shots. Let me know if you want me to upload more of the log.

    These are the last things that I receive even though I can see that my unit is trying to send back more data

  • I see the in que usually around 10 to 20, then all of the sudden that jumps to 9048.

    I don't know why it suddenly jumps to 9048. Can you diagnose the following

    - What if you slow down the UART input? What is your UART baudrate? I will suggest start with 10x slower and gradually increase the speed. Does it make any difference? I want to know if the problem is dependent on the UART input bandwidth.

    - I think you know exactly what is being sent from UART. Can you generate a test pattern from the UART side. For example, send a sequence of data with values starting from 0.1.2.3,4... to the USB. On the PC side, you should expect to receive the same pattern. When you see the queue jumps from 24 to 9048, what are you actually receiving? 

    - What type of software utility is your USB monitor? When you see the queue suddenly jump to 9048, does it actually receive 9048 bytes of data or is it only receiving 24 bytes but your USB monitor thought by mistake for whatever reason that it was receiving 9048. 

    - Is there any error detected on the MCU USB module or the MCU UART module when the USB monitor indicates 9048?

     - During your USB initialization, can you first flush the buffer? Please flush the UART FIFO and USB buffers Does that make a difference?

  • -the uart baudate is 1M. slowing down the throughput seemed to help a bit, but I would still see that same problem eventually.

    - with the test pattern I seems to get things back in order, but at some point I stop receiving data even though I am not complete in sending it back.

    -I am using HDD Device Monitoring Studio. I do seem to actually be receiving the amount of data shown there.

    - No uart errors, and I havent seen any usb error but I would need to look deeper into how to detect a usb error in the TI processor before I can be sure of that.

    - I already flush all buffers on init.

    -Is if possible to configure the USB to support multiple classes at once. for example bulk and isochronous? Would that help me in the instance of streaming this data back?

  • -the uart baudate is 1M. slowing down the throughput seemed to help a bit, but I would still see that same problem eventually.

    Although not unheard of, 1Mbps is quite high. How slow have you gone down? Do you know at what baudrate the UART to USB is transferred reliably without your current issue. Since you said slowing down will help and hence my question. 

    - with the test pattern I seems to get things back in order, but at some point I stop receiving data even though I am not complete in sending it back.

    I wonder if you change the buffer size even larger, will that improve? For example, change from 2048 to 8192. 

    - No uart errors, and I havent seen any usb error but I would need to look deeper into how to detect a usb error in the TI processor before I can be sure of that.

    ok. 

    - I already flush all buffers on init.

    ok.

    -Is if possible to configure the USB to support multiple classes at once. for example bulk and isochronous? Would that help me in the instance of streaming this data back?

    That would be a composite device. However, we don't have an example as such (bulk and isochronous). You can first try isochronous transfer and see if that improves. 

  • is there an example of isochronous transfer that I could use to quickly try this out?

  • HI Andrew,

      We don't have any isochronous transfer examples for device. However, there are isochronous examples for host. These examples were developed for the DK-TM4C129X EVM board but this board has been discontinued. The examples can be found at:

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\dk-tm4c129x\usb_host_audio

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\dk-tm4c129x\usb_host_audio_in