I have cloned the usb device virtual com example to my K60 board. It communicates fine with teraterm but will not talk to my c# application. I get the same results on win7 and xp. Any suggestions?
No response to this? I have the same problem and it's holding me up. I can see send packets through a terminal program and see the device respond as I expect, but when making a basic C# app the send never gets through. I expect it might be some driver issue, but I haven't found it yet...
I'm using a JM128 with the 4.0.0 Freescale USB stack and driver.
this is just a wild guess, but here is what I heard (I have not used C# myself), but I know that others reported a similar problem to me. The problem seems to be that the C# libraries seem to have a bug dealing with USB CDC. If I remember correctly, there should be a patch/fix from Microsoft available. Sorry, I do not have a pointer/link to this.
Otherwise, what I know is that sending too much data too fast causes problems with many USB CDC implementations. Try to add delays to the send/receive methods. Start with a slow data traffic, and find out if this 'fixes' your problem.
Hope this helps,
I'm not sure about that. In the past I used the CMX usb stack and created a CDC project. With that I didn't have any problems creating a windows app. There are some differences between the descriptors for CMX and Freescale, though, and that's where I'm looking at the moment.
I may end up just going back to the CMX usb driver in the end. We'll see...
Yes, it was just a shoot into the dark water from my side. I had used the CMX stack for ColdFire, and ended up fixing several bugs in the stack myself too (but using USB keyboard class).
I have used the FSL Stack, but faced strange problems with some buffer sizes as well (blocking terminal applications on the PC), see http://mcuoneclipse.wordpress.com/2012/04/17/fsl_usb_stack-updated-sending-16-or-32-byte-blocks/
That solved a lot problems for me. Not sure if this related.
That link ended up helping quite a bit. The CDC code in that PE module mentioned there has been modified quite a bit from the Freescale download. I dug into it some and not only is it easier to set up, it doesn't have the problem wpekrul and I seemed to be describing when talking to the USB with C#. I'm able to send and receive packets from my PC app now.
If I find some free time I'll spend a bit of it digging into the diffences, but at first glance it seems my expecation of descriptor issues isn't right. For now, this will solve the problem I was having and let me finish up my PC app.
Thanks a ton BK!
I was having the same problem and found the answer in one of the other posts (don't have the link). If you are using the Processor Expert module from the USB Stack, then in your C# program set the following two SerialPort options to "true":
This will allow you to communicate using the C# SerialPort class without making any modifications to the firmware.
For anyone that comes across this in the future, I'm running the USB CDC Virtual COM demo found in KSDK 1.3.0 with my MK22F device and I was required to only set DtrEnable = true in my C# application.
m_SerialPort = new SerialPort("COM1", 115200, Parity.None, 8, StopBits.One)
DtrEnable = true
If you set a breakpoint in the firmware, when start_transactions = TRUE, then you know the data will be received.
Thank you very much
Visual studio is a bit strange for Virtual com port...
I plucked my hair !
I believe its the settings in the KSDK USB driver. I've never had to set that property with a COM port/SerialPort over the 5 years I've worked with C# and heavy usage of SerialPort.
If anybody is willing to take on the challenge, I'd be interested to know why DTR is required to be set, and a solution on how to edit the KSDK so its not required to be set, like most modern day COM devices.
Retrieving data ...