issues with freedom k64 virtual com port example

[ryanlush]

This is a bit of a hail marry because my issue appears to be on the windows side but it's worth a shot.

I am running the k64 virtual com port example and trying to talk to it with a c# .net app I wrote. It's pretty simple, I just call port.write() from the c# side and I've done this before so it should work. Trouble is I get timeouts on the windows side every time and when I look in the debugger on the Kinetis side I see the code no longer thinks the device is enumerated.

To add one more layer of frustration on top of all of this I am running windows in Parallels on a Mac.

Anyone have any experience with any one piece of this and perhaps be willing to offer some insight?

[ryanlush]

Anyone?

[martir]

I had this problem too ( in the example of SDK_2.2_FRDM-KL82Z but I'm pretty sure it's kinda the same ), where you couldn't receive more if you didn't send it back.

What you have to do to solve this is: once you have received something, you have to call this function again "USB_DeviceCdcAcmRecv(handle, USB_CDC_VCOM_BULK_OUT_ENDPOINT, s_currRecvBuf, g_UsbDeviceCdcVcomDicEndpoints[0].maxPacketSize);" so you can receive again. In the example, the code was calling this after sending something, so that's why the 'error' of not couldn't receive more.

I see this question is almost two years old but maybe it helps someone

[ryanlush]

I have drilled this down a little more. It seems .NET was trying to use some flow control that doesn't really work on the cdc example. Once I disabled that I was able to receive data. I have a new problem thought that exists both in my terminal emulators as well as .NET

If I receive data, I can't receive any more data unless I send data first. It seems like the receive puts it in a state where it can't receive any more data and the send is getting it back out of that state. I am only receiving 6 characters so nothing is overflowing as far as I know.

[ryanlush]

I see this is true even for the original example. Once you receive a USB frame you can't receive another one until you send one. I'm not seeing and USB events after the first frame.

[kevinlfw]

This looks to be true Ryan.  I ran into the same thing with the FRDM-K22F board.  I simply don't want it to echo everything back!  Commenting out the line doesn't do any good, because then everything break.  So it seems that the SDK call to UB_Class_CDC_Send_Data must be crucial to proper operation of the Virtual COM Port.  What I did to get around it was simply send nothing back, but still made the call, and that seems to work.  In the Virtual_Com_App(void) function this is the original line of code:

error = USB_Class_CDC_Send_Data(g_app_handle, DIC_BULK_IN_ENDPOINT, g_curr_send_buf, size);

I changed it to:

error = USB_Class_CDC_Send_Data(g_app_handle, DIC_BULK_IN_ENDPOINT, NULL, 0);

Simply just changing the size to send to 0 works as well.  After doing this, every character is still process coming into the virtual COM port.  Hopefully this helps.

NXP/Freescale, can you give us some clarity on what is happening when we comment out the above line completely, it causes the virtual COM port to malfunction and no events are fired?  At the very least, can you confirm Ryan's statement, that every USB TX needs an RX?

Thanks,

Kevin

[mjbcswitzerland]

Ryan

I don't have any explanation for the effects that you are seeing but you may like to try a binary for the FRDM-K64F from http://www.utasker.com/kinetis/FRDM-K64F.html where there is one for USB-CDC to 5 UARTs where you can bridge to physical UARTs or connect to a command line shell (on the first USB-CDC interface).

All bridges perform end-to-end flow control so you can verify whether it is a particular problem with the implementation that you are using at the moment or something general, or .NET specific.

Regards

Mark