Thursday, March 22nd 2018, 11:21am UTC+1

You are not logged in.

  • Login
  • Register


Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Message information
Automatically converts internet addresses into links by adding [url] and [/url] around them.
Smiley code in your message such as :) is automatically displayed as image.
You can use BBCode to format your message, if this option is enabled.
Security measure

Please enter the letters that are shown in the picture below (without spaces, and upper or lower case can be used).

The last 5 posts

Tuesday, March 13th 2018, 3:39pm

by akohlsmith

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.

Tuesday, March 13th 2018, 10:40am

by SEGGER - Nino


Thank you for your inquiry.
Such an issue is not known to us.
We will investigate this further and fix it if necessary.
Unfortunately we currently do not have that particular dev kit in house but numerous other so we will see if it is reproducible with other boards as well.

Best regards,

Thursday, March 8th 2018, 8:20pm

by akohlsmith

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.

Thursday, March 8th 2018, 5:56pm

by akohlsmith

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.

Thursday, March 8th 2018, 4:46pm

by akohlsmith

vcom RTS (from JLink to Nordic) "sticks"

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.