Recommended
Related

You will never guess how JLink deals with UART flow control

Eirik Midttun

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.

How does it work?

The significant behavior is as follows:

  • After power up the UART interface is disabled. This is the correct state for doing power measurements, as the UART IOs are tri-stated.
  • The UART is activated when the baud rate is set (Set Line Coding USB command).
  • After activation the JLink OB drives the RTS line (target CTS).
  • On the first UART RX or TX the JLink OB will check the CTS line (target RTS):
    • If CTS is high before the JLink OB has received or transmitted anything, flow control is not activated.
    • Otherwise flow control is enabled.

Design considerations for the JLink UART

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.

What if -

  • The target is programmed with firmware that has different flow control settings: By reopening the terminal the JLink OB will receive the baud rate setting again and the flow control detection will rerun.
  • I am doing power measurements or otherwise want to disable the UART: The only way to do that is to power cycle the board.

  • It's worth mentioning that for typical RTS/CTS hardware flow control, the RTS/CTS lines do not cross (unlike TX/RX).  CTS goes to CTS and RTS goes to RTS; on the DTE ('computer'), RTS is an output and CTS is an input; on the DCE ('modem'), RTS is an input and CTS is an output.

  • Hi,

    It was really hard to tell in my case, and I think the same thing applies in this case. When studying the problem I used USBlyzer while monitoring the 4 GPIO lines. That will at least give you some visibility on what goes on, for example if the RTS or CTS is not in the right state.

    I'm afraid you have to do the debugging yourself. If you see any strange behavior that you can't explain I can check if there is a non-obvious design decision behind it, such as the need to do power measurements.

  • Hi

    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?

    Regards Adrian