J-Link Virtual COM Port
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:
Device Manager after VCOM device has been connected:
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:
- 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.
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.
For VCOM, the USB CDC-ACM class is used.