J-Link Virtual COM Port

From SEGGER Wiki
Jump to: navigation, search

Virtual COM port (VCOM) is a technology used to replace the traditional COM ports on modern PCs and laptops. From the hosts perspective, there is no difference between a "real", physical COM port and a virtual COM port. The virtual COM port presents itself in the same way and offers the same functionality. The virtual COM port is a COM port via USB. In case of the J-Link, if the virtual COM port is enabled, J-Link presents itself as a composite device with multiple interfaces: The J-Link functionality (One bulk in, one bulk output) and the COM Port interface. Both can be used simulteously.

USB to Virtual COM Port adapters

Most modern PCs and notebooks no longer provide COM connectors on their mainboards due to the large size factor of the COM port connector and the fact that very few consumer users have any use for them. The typical replacement is a a USB device to show up as a COM port at the PC. These USB to COM adapters that have a USB connector on one side and a COM connector on the other one allow retrofitting a modern machine with a COM port. Once the adapter has been connected to the PC, a new COM port will show up which can then be used as a normal COM port by terminal applications etc.

Identifying Virtual COM Ports on a windows machine

Device Manager before VCOM device has been connected:

VCOM DevManBefore.png

Device Manager after VCOM device has been connected:

VCOM DevManAfter.png

VCOM on J-Link

The SEGGER J-Link as well as most J-Link OBs support VCOM as an additional feature to avoid the need to expose an additional COM port or additional USB connector on the target board. The Tx and Rx pins of the target UART are connected to the J-Link or J-Link OB which will forward this data via the VCOM functionality over USB to the PC the J-Link is connected to. So a J-Link in this case is a multi-interface USB device. One interface exposing the VCOM port that may be used by any terminal application etc. to get terminal data from the target device and one exposing the J-Link USB interface that is used by IDEs etc. to debug the target device.
Some J-Link OBs offer up to 3 VCOMs.

Typical use cases

There are many different use cases, as any kind of communication can be done via a virtual COM port. In many cases, the communication port is simply used for terminal I/O, allowing the device to communicate with the user (typically the application programmer). But we have seen cases where it has been used for entirely different purposes, such as system setup, firmware updates.

Hardware flow control

On some J-Link OB models, hardware flow control is enabled, but optional. Hardware flow control is designed to make sure the receiver (on both ends) does not get data faster than it can process the data, to stop the flow of data before bytes are lost due to buffer overflow. The following pins are defined for hardware flow control:

  • CTS, sampled to check if the other side is ready to receive more data
  • RTS, driven to indicate to the other side if driving side is ready to receive more data

These lines exist on both ends (sender + receiver) and are crossed for connection, so:

  • J-Link-OB-RTS -> Target-CTS
  • J-Link-OB-CTS <- Target-RTS

Encoding of CTS/RTS:

  • HIGH (logic 1) == Not ready
  • LOW (logic 0) == Ready

For an overview about which J-Link OB models can support VCOM, please refer to the J-Link OB model overview

Performance of VCOM

What performance can be achieved depends on 3 factors:

  • Baudrate
  • USB interface of J-Link or J-Link OB (Full-speed, Hi-speed, ...)
  • Fragmentation of data

For the baudrate, the max. data throughput is relatively easy to calculate. For UART communication, 10-bits (1 start, 8 payload, 1 stop) are needed to transmit 1 byte of payload data. So the max. throughput in bytes/sec is:

NumBytesPerSec = <Baudrate> / 10

So for 1MBaud we have a max. throughput of 1,000,000 / 10 = 100,000 bytes/sec = ~98 KiB/s.

However, what the actual throughput is, also depends on if the data is received continuously. This is because the data needs to be forwarded via USB to the host PC and for USB there is latency between USB transactions. So, the more fragmented the data is received by J-Link, the more USB transactions need to be triggered (with very few payload bytes in them) which brings down the max. throughput in certain cases. Having the bulk of data transmitted in a continuous UART transmission is better.

Maximum baudrate

The maximum VCOM baudrate supported by J-Link depends on the model of J-Link.
An overview over the J-Link models and their supported maximum baudrate can be found here: J-Link Model Overview.

Disadvantages of VCOM

The main disadvantage when using this to communicate with the target processor is that 2 pins on the target processor are lost (Rx and Tx) for this purpose, typically in addition to the pins used for the debug interface. If hardware flow control is used, then even more pins (typically 4) are required. Some people also consider the speed a limitation. A better alternative in many cases is RTT, where J-Link communicates with the application via the debug interface, not needing pins in addition to the debug interface itself (which is 2 pin in most cases, such as SWD), and also delivering performance of up to 3MB/sec.

Enabling VCOM on J-Link

How to enable VCOM functionality of J-Link or J-Link-OB models that support it, is handled in this wiki article.

USB class

For VCOM, the USB CDC-ACM class is used.