Thursday, September 21st 2017, 10:51am UTC+2

You are not logged in.

  • Login
  • Register

nikpe

Beginner

Date of registration: Jun 11th 2015

Posts: 3

1

Thursday, June 11th 2015, 2:20pm

Linux UART stops to listen

Hi,

I'm developing a project using the Nordic Semiconductor nRF51-dongle that has components from SEGGER. My project consists of a PC application and a dongle firmware where the two parts communicates over UART. I am facing issues when running my project in Linux(Ubuntu 14.04), after a few open/close of the UART terminal the communication is dead. I'm not facing this problem when I'm running the same code and dongle firmware in Windows. In Linux I'm opening a correctly configured UART channel to, for example, /dev/ttyACM0 and when it works it never fails until I restart the UART connection.

I have tried some different boards from Nordic with the same behavior and since it works for hours once the UART is opened I'm confident that my implementation is good. The dongle should always give a response to any data put on the UART, but nothing arrives. The only solution is to unplug/re-plug the dongle into the USB port. The problem shows up after a random amount of close/open events but usually less than 10 times. Sometimes it is possible to send a command to the dongle but I never get the expected response. On some other machines with the same OS the dongle might never respond.

First I thought that I could solve it by toggling the DTS and RTS signals but nothing seems to work. I have tried most of the terminals as CuteCom, Putty, minicom etc..) so I really think it's Linux related. I cal also mention that my PC has only USB 3.0 ports and I have the j-link 4.98e driver installed.

The support at Nordic Semiconductor said it's most likely related to an issue with the SEGGER and CDC driver in Linux and that I should report it here. I tried to use unload the cdc_acm driver with "rmmod cdc_acm" and load it again but it didn't seem to help me. Do you have any idea of what it could be related to?


Best Regards,
Niklas

SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

2

Monday, June 22nd 2015, 10:46am

Hi nikpe,

Could you please provide us the dmesg output at the time of the error?

Regards,

Yan

nikpe

Beginner

Date of registration: Jun 11th 2015

Posts: 3

3

Monday, June 22nd 2015, 2:23pm

Hi,

Please find the attached log. There is no change in the dmesg log before and after the occurrence of the error.

Best Regards,
Niklas
nikpe has attached the following file:
  • dmesg log.txt (3.33 kB - 787 times downloaded - Last download: Today, 6:35am)

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

4

Monday, August 24th 2015, 7:37pm

I have the exact same problem! The UART communication through the virtual COM for the J-Link MCU on my NRF51-Dongle fails maybe about 20%. I can receive data from it just fine, but it cannot receive any data from me.

Any solutions?

SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

5

Tuesday, August 25th 2015, 2:39pm

I have the exact same problem! The UART communication through the virtual COM for the J-Link MCU on my NRF51-Dongle fails maybe about 20%. I can receive data from it just fine, but it cannot receive any data from me.

Any solutions?
Hello jcady92,

We are currently looking into this, we will post here as soon as we have any news.

Regards,

Yan

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

6

Friday, August 28th 2015, 2:59am

I have the exact same problem! The UART communication through the virtual COM for the J-Link MCU on my NRF51-Dongle fails maybe about 20%. I can receive data from it just fine, but it cannot receive any data from me.

Any solutions?
Hello jcady92,

We are currently looking into this, we will post here as soon as we have any news.

Regards,

Yan
http://forum.segger.com/index.php?page=User&userID=5289
Hi Yan,

Thanks for looking into this. I contacted Nordic directly and they said this is a known issue with the Segger chip.

I was able to get around this by buying a FTDI USB dongle and soldering the pins to the NRF51-Dongle's GPIO, then configuring the NRF51 UART to use the GPIO pins instead of USB. This completely bypasses the Segger chip. I've confirmed that this "fixes" the problem. It's really more of a hack to get it working in the interim, though, ideally I'd like to use the Segger directly.

Please let me know of any discoveries/updates.

Jay

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

7

Friday, August 28th 2015, 3:02am

This looks like the same problem as well:

nRF51822 Linux Driver Source Code

SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

8

Wednesday, September 2nd 2015, 11:12am

Hello jcady92,

We are having serious trouble reproducing this on our side.
Could you please provide a few details about your setup?
(GNU/Linux Distribution, J-Link version, firmware string (shown when you start the jlink commander), method of communicating with the UART from GNU/Linux.)
When exactly does the issue occur?

Regards,

Yan

nikpe

Beginner

Date of registration: Jun 11th 2015

Posts: 3

9

Friday, September 4th 2015, 2:43pm

Problem solved

Hello again,

I have today identified that my problem was solved when going from the kernel distribution 3.13.0-24-generic to 3.13.0-64-generic.
Your kernel version is printed by typing " uname -r" in a terminal.
I upgraded my kernel by:
sudo apt-get update; sudo apt-get dist-upgrade

I don't know what caused the issue but I can no longer re-produce it.

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

10

Friday, September 4th 2015, 9:08pm

Hello jcady92,

We are having serious trouble reproducing this on our side.
Could you please provide a few details about your setup?
(GNU/Linux Distribution, J-Link version, firmware string (shown when you start the jlink commander), method of communicating with the UART from GNU/Linux.)
When exactly does the issue occur?

Regards,

Yan

Hi Yan,

Thank you for your response. Let me get you that information:

Device: NRF51-Dongle PCA10031 v1.1.0 with S110 v8.0 softdevice.
J-Link: OB-SAM3U128-V2-NordicSem V1.00
Distribution: Raspbian (Latest, 2015-05-05)
Raspbian Kernel: 4.1.6-v7+

Our device is a Raspberry Pi 2 that is communicating with the NRF51-Dongle through one of the Pi's USB ports. The software that is communicating with it is a Qt 5.5 application using QSerialPort.

If you're serious about reproducing this and happen to have an NRF51-Dongle and Raspberry Pi laying around, I can write up a test program to show you the problem. It occurs about 15-20% of the time when booting the system.

Best,
Jay
Hello again,

I have today identified that my problem was solved when going from the kernel distribution 3.13.0-24-generic to 3.13.0-64-generic.
Your kernel version is printed by typing " uname -r" in a terminal.
I upgraded my kernel by:
sudo apt-get update; sudo apt-get dist-upgrade

I don't know what caused the issue but I can no longer re-produce it.
Hi nikpe,

I see, perhaps we are experiencing different problems. My kernel for Raspbian is the most up to date, but the issue still occurs for me.

Jay

SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

11

Monday, September 7th 2015, 11:11am

Hi Jay,

Unfortunately we do not have a PCA1003, but we have a couple of PCA10000 dongles.
Would this also work?

Also we only have Raspberry Pi V1, but I assume the application would work on that as well.

A test program would be much appreciated.
There is only one thing which is not quite clear to me, you write:

Quoted

It occurs about 15-20% of the time when booting the system.
Does this mean that the issue only occurs right after booting the system?
Or does this mean that there are cases where the issue does not occur at all unless you re-boot?

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

12

Monday, September 7th 2015, 9:50pm

Hi Jay,

Unfortunately we do not have a PCA1003, but we have a couple of PCA10000 dongles.
Would this also work?

Also we only have Raspberry Pi V1, but I assume the application would work on that as well.

A test program would be much appreciated.
There is only one thing which is not quite clear to me, you write:

Quoted

It occurs about 15-20% of the time when booting the system.
Does this mean that the issue only occurs right after booting the system?
Or does this mean that there are cases where the issue does not occur at all unless you re-boot?
Hi Yan,

PCA10000 and the Raspberry Pi V1 should work. I have both of those, so I will test with them before I send you the program to ensure it can be reproduced. I'll write up the program in the next few days and send it over in a PM.


As for the 15-20% question: The issue occurs right on boot of the system. For example, say you boot the system, communicate over serial, then power down the system and boot again. Repeating this say 10 times, serial communication should fail one or two of those times. It's not an exact science, but when the communication does fail, it will not work until the system is rebooted or the serial device is physically unplugged and plugged back in. Then it works properly.

SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

13

Tuesday, September 8th 2015, 9:05am

Hi Jay,
As for the 15-20% question: The issue occurs right on boot of the system. For example, say you boot the system, communicate over serial, then power down the system and boot again. Repeating this say 10 times, serial communication should fail one or two of those times. It's not an exact science, but when the communication does fail, it will not work until the system is rebooted or the serial device is physically unplugged and plugged back in. Then it works properly.
This seems to be an entirely different issue from what Niklas experienced.
It was not related to the boot-up "session".

Thank you for taking the time to write the program.

Regards,

Yan

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

14

Friday, September 11th 2015, 1:57am

Hi Yan,

I finished the test programs for you today. In my testing I had some very interesting findings. Here they are:

I tested (for sanity's sake) using the NRF51-Dongle (PCA10031) again and, as expected, it exhibited the serial failures. Then I tested using the NRF51822 USB Dongle (PCA10000) and could not reproduce the serial failure (perhaps this is why you are having trouble reproducing it).

I was pretty interested in why this was happening, so I took a closer look at the firmwares on the boards. Here is what I was running:

PCA10000: SEGGER J-Link OB-SAM3U128 V1.00 (2014 Nov 28 10:24)
PCA10031: J-Link OB-SAM3U128-V2-NordicSemi V1.00 (2015 Aug 28 19:26)

I confirmed that both boards had the latest supported J-Link firmware. But the firmware for the PCA10000 was almost a year older. But oddly enough, the older firmware worked properly with serial, while the newer didn't. So this led me to do some more digging.

I decided to start reverting the firmware of the PCA10031 to older versions (using older versions of J-Link Configuration). I did 30 trials of powering up the Raspberry Pi running my serial test software with the PCA10031 connected using 4 different versions of the interface firmware to see how many times it failed. Here are my results:

2014 Nov 28 10:32 - 0/30 (0% failure)
2015 Mar 11 16:29 - 0/30 (0% failure)
2015 Apr 23 19:13 - 4/30 (13.33% failure)
2015 Aug 28 19:26 - 8/30 (26.67% failure)

Aha! From this it's very clear to me that a regression in the serial part of the interface firmware was introduced between the Mar 11, 2015 and Apr 23, 2015 releases. I did another 30 trials (for a total of 60) of the Mar 11, 2015 firmware just to be absolutely certain it did not fail, and there was not a single failure.

My problem is solved by just using the older March 11, 2015 firmware in our product. But I'd still like to help you solve this so that we can get the fix into the latest firmware (I'm not sure if we're introducing other problems by using an older firmware). I have the test software ready to go, but as I mentioned above, it will not reproduce on your PCA10000 board. You will need a board that can support an interface firmware of April 23, 2015 or later. It would probably be easiest to just buy an NRF51-Dongle to reproduce it on.

Let me know if you'd like me to send over the test software!

Best,
Jay

This post has been edited 1 times, last edit by "jcady92" (Sep 11th 2015, 3:15am)


SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

15

Friday, September 11th 2015, 10:05am

Hi jcady92,

Thank you for your analysis.
The test program would be much appreciated.

Quoted

PCA10000: SEGGER J-Link OB-SAM3U128 V1.00 (2014 Nov 28 10:24)
There are newer versions available for this firmware. Did you install the newest official package from https://www.segger.com/jlink-software.html ?

Regards,

Yan

jcady92

Beginner

Date of registration: Aug 24th 2015

Posts: 7

16

Saturday, September 12th 2015, 9:10pm

Hi Yan,

Ah, I see that you are correct. I forgot to use the newest software for the PCA10000. I went ahead and flashed the latest firmware (2015 Aug 28 19:26) and tested it.

Unfortunately, the rabbit hole continues. The PCA10000 using the latest Aug 28, 2015 firmware does not exhibit the serial problems that are exhibited in the firmware for the PCA10031 from the same date. In other words, the problem is unable to be reproduced on the PCA10000 entirely.

Perhaps the bug was only introduced in the PCA10031 version of the firmware. Or perhaps there is more at play, I'm not sure.

I went ahead and sent all the test software in a private message to you. Please keep me updated on your progress and if you need anything else.

Best,
Jay

SEGGER - Yan

Super Moderator

Date of registration: Feb 28th 2014

Posts: 23

17

Monday, September 14th 2015, 11:31am

This case has been resolved through different channels.
If you experience a similar issue please contact support@segger.com directly.

This post has been edited 1 times, last edit by "SEGGER - Yan" (Feb 8th 2016, 3:24pm)