TL;DR: It ignores whatever the computer tells it to do and does an automatic detection.
And the reason? UART terminals are not doing flow control settings in a consistent way, and in some cases incorrectly. Therefore the JLink OB firmware will detect automatically if flow control is used. So the use of flow control will only depend on the target firmware.
It all started when I saw a weird issue with pyserial flow control, and after some digging I finally found out how things really worked. Read on for the full explanation.
The significant behavior is as follows:
As mentioned, one of the important design consideration for the nRF51 and nRF52 DKs is to allow accurate power measurements. When the UART is enabled it means that IOs are driven or set as inputs, and that will affect the result. A state where all the IOs are tri-stated is needed for this.
To enable the UART the only reliable signal you can get from a PC that a COM port is opened is the setting of the baud rate. The flow control settings are too varied and unreliable to consider.
Furthermore, some terminals will not send any notification when the port is closed. So there is no sure way to know if the computer program is done using the UART or expecting it to be available. Therefore the UART TX is disabled when the JLink OB is done transmitting, and re-enabled when there is new data to transmit. The RX will remain enabled until the OB is power cycled.
Just was searching for an explanation for my strange behavior with the serial port of my nRF52DK boards and found your post. I'm using the nRF52 DK with the jLink VCOM with flow control. The behavior I see is that sometime the communication is blocked and no data is transfered to the nRF chip. Only a power cycle seems to fix this issue.
I thought that your explanation may fit for may behavior. If so opening the serial port and change the Baudrate should activate the UART on the board, but it didn't fix my problem.
What can cause the jLink VCOM to be stucked? How to resolve this? Any ideas?