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.
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.
The post was edited 1 time, last by akohlsmith ().