Linux UART stops to listen

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • 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
  • jcady92 wrote:

    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
    forum.segger.com/index.php?page=User&userID=5289
  • SEGGER - Yan wrote:

    jcady92 wrote:

    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
    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
  • 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
  • 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.
  • SEGGER - Yan wrote:

    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

    nikpe wrote:

    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
  • 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:
    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?
  • SEGGER - Yan wrote:

    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:
    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.
  • Hi Jay,

    jcady92 wrote:

    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
  • 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

    The post was edited 1 time, last by jcady92 ().

  • 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