CDC class / Freescale USB stack stops working when trying to transmit large amount of data in full-duplex mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CDC class / Freescale USB stack stops working when trying to transmit large amount of data in full-duplex mode

1,356 Views
gustavod
Contributor III

Hi everyone,

 

We implement a terminal through a virtual com using the CDC class from the Freescale USB stack (3.1). Everything was working fine until we tried to transmit and receive data simultaneously. This happens when we use a "cat" command to print the content of a file in the terminal and buffers other commands like another cat or a "top" command to show the cpu load and memory informations. We note that when this happens the USB stack has received just one character (we think this is due the keyboard scan time, i.e., when the data input is from keyboard we always will receive a character at a time), but informs that there are 64 bytes in the endpoint. If we reduce the endpointer buffer to 16, the USB port registers informs that there are 16 bytes to be received.

 

This can be verified if we do a "cat" command of a large file and holds a key pressed in order to receive a lot of characters during the cat command. In this condition the USB port always stop to receive character at a certain time.

 

Has anyone faced the same problem? Are there some workaround to this problem?

 

We face the same problem in kinetis and coldfire microcontrollers. We are using the same code and USB stack in both microcontrollers. The code can be download here:

Coldfire:

http://brtos.googlecode.com/files/colduino_MCF51JE256_CW10.rar

Kinetis:

http://brtos.googlecode.com/files/BRTOS%201.66%20Kinetis%20-%20SD%20card%20-%20BMP%2024%20bit.rar

 

Thanks in advance,

Gustavo

0 Kudos
6 Replies

592 Views
gustavod
Contributor III

Hi,

 

I have modified the Virtual_com.c example of the Freescale USB stack 3.1 demo in order to show what i think is a bug. Anyone can substitute this file in the Freescale demo and try it. Just press and hold any key for a long time. In this example each pressed key will be replicated a lot of times (around 16000 times). You will notice that after a while the USB driver will stop to receive new characters. This happened in my demo when i tried to store a lot of commands in my terminal buffer after a cat command for a large file.

 

Any workaround???

 

Best regards,

Gustavo

0 Kudos

592 Views
J2MEJediMaster
Specialist I

You need to submit a service request to get this looked into. Click here to submit an on-line service request.

 

---Tom

0 Kudos

592 Views
Ben_G
Contributor I

Any updates on this thread?

0 Kudos

592 Views
eli_hughes
Contributor V

Gustavo:

 

Did you ever get a solution.  I have notice similiar problems.  It appears that stuff is getting dropped!

0 Kudos

592 Views
BlackNight
NXP Employee
NXP Employee

Hello,

dito for me. I have not done much of an analysis, but I have found several things:

- just sending a flood of outgoing data to the host is already problematic. If I'm sending data as fast as I can I was able to crash my terminal application on the host. That looks to be like a problem on the host to me.

- what worked for me was to insert some delays (say 10 ms) to give the USB block enough time to send things off the device

- sending large amount of data from the device to the host seems to block the incoming end point. My terminal program really gets unstable.

 

Still doing some tests to get things more stable. I have fixed several smaller issues in the stack, so I hope I can publish here soon my new version (working on the MCF51MM256 right now).

I think I need to end up to add some proper delays here and there. Not ideal, but at least I hope I get things up and running.

 

BK

0 Kudos

592 Views
eli_hughes
Contributor V

Its gotten bad enough that I simply went back to using an FTDI device.....

 

 

I have considering just rewriting my CDC from scratch.   NXP  has lots of good examples.

 

Ideally I want everything in one file for portability!

 

 

Has anyone tried doing anything with libUSB-win32 and a custom device?

0 Kudos