You will never guess how JLink deals with UART flow control

RE: You will never guess how JLink deals with UART flow control

Brian_H — Wed, 21 Feb 2024 19:18:44 GMT

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.

RE: You will never guess how JLink deals with UART flow control

Eirik Midttun — Mon, 04 Dec 2017 12:39:30 GMT

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.

RE: You will never guess how JLink deals with UART flow control

Adrian Eggenberger — Sun, 03 Dec 2017 20:35:01 GMT

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