Hello everyone,
Thanks in advance for your patience in reading this long message.
I have been having problems with UART over USB on PCA10040 boards for almost four months now. Something changed around March of this year. I have seen some other posts from other users which may be related.
The problem with intermittent failures is that they do not behave the same way every time. I had to try a lot of things to deduce a pattern. Here are the details.
I have several PCA10040 boards, some revision 1.1.0, others 1.1.1. The Nordic engineer who answered my previous questions back in March said that this minor version difference should not matter.
I have some nRF52 software which is compiled using SDK 11, and some which is compiled with SDK 12.3. Again, I think this is not important. Obviously I want to run my own nRF52 apps, but in my investigations I have gone back to Nordic's own simple UART example programs, and they also have connection problems no matter which SDK I use.
My host computer is a dual-boot system, running either Ubuntu 17.04, or less often, Windows 10.
On both operating systems, when I connect a PCA10040 board to a USB port, The JLink mass storage device appears every time. If I execute JLinkExe from the command prompt, the host connects to the nRF52 peripheral every time, from both operating systems, and I can flash the nRF52 without any problems.
The host computer apps that I wrote myself are written in Python, run on top of Linux, and use the USB to UART to pass data. These apps are hanging when they attempt to connect to the nRF52 peripheral, roughly three times out of four. They used to work. I didn't write any UART connection diagnostics in these programs, because they weren't needed. All of my own apps use the same UART configuration used in Nordic's own examples: 115200 baud, 8 bits, 1 stop bit, no parity, RTS/CTS handshaking.
As a fallback, I just look at the output of UART programs with a raw terminal emulator program. I am currently using PuTTY because it is available on both Windows and Linux. But I have also used GTKTerm on Linux, and have seen the same problems. When I try to start PuTTY, I get a "PuTTY Fatal Error: Unable to open connection to: Unable to open serial port" message. The GTKTerm equivalent error appears to be "Cannot open /dev/tty/ACM0: device or resource busy".
If I quit the terminal emulator and restart it, the error message might disappear on the first try, or the second. The UART output may or may not appear when restarting the software. If I don't get the error message, sometimes pushing the IF BOOT/RESET button on the PCA 10040 will start the UART output.
That's the inconsistent, intermittent part of the problem in detail.
Meanwhile: I have discovered that if I run PuTTY on Windows 10, I can establish a connection to the nRF52 UART over USB the first time, every time. I am taking care to use the exact same physical USB port on the computer, the same USB cable, and the same PCA10040 board running the same program. The only thing that I'm changing is the OS.
I am also asking questions about this problem on Ubuntu Forums. I wondered whether I had uncovered a UART driver problem in Linux on my host computer. The prevailing opinion is that it was unlikely that I have uncovered a Linux kernel bug, which had not only broken something that previously worked, but also had gone uncorrected for four months. I just posted the results I'm sharing here to Ubuntu Forums as well. We'll see what they have to say.
If it turns out that there is nothing wrong with the UART driver in Linux, what could have changed on the Nordic side? I've had to update JLinkExe to make the newer SDK versions work. When I connect a board to JLinkExe, it sometimes performs a firmware update. I think this happens when I connect a board to the latest version of JLinkExe for the first time. What is this firmware, and exactly what does it do? Might these updates be responsible for changing the behavior of my UART connection?
Why don't I just use Windows on the host computer side, you may ask? Well, I'm also working on that option. My Python-based host applications are theoretically cross-platform apps -- but Scipy is used, and Scipy requires BLAS. Installing BLAS is easy on Linux, but difficult on Windows. I'm working on it.
Thanks for reading this all the way through. Our group's nRF52 development efforts are stuck right now because of this issue. Hope you can help!
