Geek Answers Handbook

The problem of virtual COM communication

I am working on a Communication Device Class (CDC) driver for an embedded device - Full Speed. COM port settings: 115200, 8 bits, no parity, 1 stop bit, no flow control. Our PC application (32-bit, Windows 7, .NET 2.0) communicates with the target device via a virtual COM port, which on the target device can be connected either to the FTDI chip (USB-to-SCI bridge) or to the built-in USB peripheral interface in the microcontroller, depending on which port is selected by the application.

Both virtual COM ports work without problems using Realterm. However, although our desktop application uses a virtual COM port connected through an FTDI chip, it freezes when trying to use a virtual COM port connected through an integrated microcontroller peripheral peripheral device.

When connected via a virtual COM port using the built-in USB, the application hangs sequentially during the second call to SerialPort.Write(...) . Using the Serial Monitor from the HHD software I can see that the data is transmitted on the first call to SerialPort.Write(...) . However, this data is never accepted by the target device.

This is strange because the only time I saw similar problems in previous projects was when the flow control settings on each side of the bus were inconsistencies.

Additional Information...

Here are the data obtained from various port monitoring tools when launching our PC application connected to the target device via the built-in USB peripheral. Any insight would be appreciated.

For those interested, I am using CodeWarrior 10.2 with the MCF51JM128 from Freescale.

Any ideas or suggestions would be appreciated. Thanks.

+4
source share
1 answer

From the logs, you can see that you are making a classic mistake without worrying about hardware confirmation signals. This ever happens by accident, a terminal emulator such as Realterm will never make this error.

You must set the DtrEnable property to true. This includes a data terminal ready signal. This is important because the RS-232 is an unused bus, so electrical interference occurs when the cable is disconnected or the power is turned off. The DTR convinces the device that it is actually connected to a powered device. This, of course, is emulated in your case, but the driver or firmware will still normally perform RS-232 behavior.

And the RtsEnable property is important, used to shake hands with the device and prevent the reception buffer from overflowing when the application does not release the buffer in a timely manner. You really have to set the Handshake property to Handshake.RequestToSend, the most common way to implement it. Which then also takes care of enabling RTS. If you need to use Handshake.None for some reason, you must enable it yourself by setting RtsEnable to true.

This should solve the problem. If you still have problems, use PortMon to keep track of how Realterm initializes the driver. Compare the commands you see with the commands that the SerialPort class sends. Make sure they are the same. In value not in sequence.

+3
source

More articles:


All Articles