I'm using the Nordic 400092 nrf51 dev board with an embedded Segger. The firmware on the Segger is "J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 12 2018 16:05:20".

I think there has been a regression in the J-Link firmware. I have been using these boards for *months* without issue, but very recently I've been seeing a case where the RTS line (from the SAM3U to the Nordic) will go high and stay high.

It's fairly easy to reproduce: Have the Nordic spew data to the Segger while the PC is reading from the virtual COM port, and then "disconnect" from the virtual COM port. The Nordic will continue to fill the Segger's UART buffer and then when that buffer is full, the Segger will de-assert RTS and the Nordic will stop sending.

However, if I connect the terminal program (Teraterm) to the virtual COM port again, RTS is *not* de-asserted. Cycling power tends to fix the issue until the next time the Nordic fills the Segger's UART buffer and the Segger de-asserts the RTS signal to the Nordic again.

This problem does not appear to happen on OSX or Linux, leading me to think that perhaps a recent Segger firmware update does not flush the SAM3U's UART buffer when the CDC DTR signal is asserted.

edit: I have downgraded the JLink firmware all the way back to March of 2017, and the same problem occurs with Windows. I have confirmed that SAM3U CTS assert/deassert works fine under OSX/Linux, but never re-asserts under Windows.

Another datapoint: JLink 5.10h (January 12, 2016) DOES NOT have this issue. I can start and stop the virtual COM connection as many times as I like and the CTS line to the Nordic does not get stuck.

I've got about a dozen copies of JLink on my system now.

The regression occured in the firmware shipped with 610b. The firmware shipping with 610a is good.


610b (CTS does not re-assert if the UART buffer is filled and a USB connection is made) ships with J-Link OB-SAM3U128-V2-NordicSemi compiled Sep 26 2016 11:30:32
610a (CTS will re-assert if the USB buffer is full and a USB connection is made) ships with J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09

This regression has been in the JLink releases for a very long time now. I hope this groundwork helps you create a speedy fix.

It's not an issue specific to the dev board; I was using the larger devboard to try to diagnose the problem. It's the "NRF51-Dongle" (Digi-Key part number 1490-1037-ND) that we first noticed the problem on.


I'm absolutely positive it can be reproduced on any J-Link using vcom.


Reproducing it:
- configure target to send a continuous stream of data to the Segger over UART (we are using 460800,N81 but baudrate should not matter). Make sure that target observes hardware flow control as required by the Segger
- Connect the segger+target to the Windows PC via USB. Our system is powered from USB so the Segger and target power up at the same time
- open serial terminal on the PC. We're using TeraTerm. Observe data coming from target through virtual com on Segger.
- close the serial port, observe that the CTS line from Segger to target will de-assert after 256 characters as Segger RX buffer is full
- open serial terminal on PC again. Observe that CTS does not assert, and never will until power is cycled.


These same steps on OSX or Linux do not result in the CTS from Segger to target being stuck, and downgrading the Segger firmware to "J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09" or earlier shows correct operation even on Windows.


I can provide a minimal test-case sample source+binary for the nRF51-dongle if it will help.

*bump*

Any word on this? It's completely reproducible. Alternatively, is there a better way to contact Segger for support on this issue?