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
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
You need to submit a service request to get this looked into. Click here to submit an on-line service request.
---Tom
Any updates on this thread?
Gustavo:
Did you ever get a solution. I have notice similiar problems. It appears that stuff is getting dropped!
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
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?