You will never guess how JLink deals with UART flow control

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.
No Data
  • 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.

No Data