USB-UART, half-duplex problem has returned! Linux issue?

[Ladasky]

Hello everyone,

This is the second time that I've had the problem I am about to describe.  I fixed it, and now it is broken again.  I am fairly certain that it is not (only) a Nordic problem, but I think that discussing the problem here will help isolate the cause, for myself and for other people.

I am doing development work with PCA10040 boards using nRF5 SDK 12.3.  I build software in a pure Linux environment on an Intel desktop machine.  My OS is Ubuntu 17.10.  The version of SEGGER J-Link that I am currently using is 6.22d.  I'm using the Nordic-tested gcc-arm-none-eabi toolchain, version 4_9-2015q3.  My compiler is gcc 7.2.0.  I know that the version of gcc is more recent than the one that Nordic tests with the SDK (4.9.3), however I have had people here in the Dev Zone tell me to use more recent gcc versions if I can.  Ubuntu installs more recent versions of gcc, and they have been working for me.

Between three days ago and today, something broke.  I lost the ability to transmit from my desktop PC to the Nordic dev board using the USB-UART.  The desktop PC receives transmissions from the Nordic board just fine.  I just went back and re-tried the UART example program in the SDK.  It prints "Start:", but it no longer echoes the characters you type.

All of my development software was installed about two months ago.  I haven't touched anything.  The only changes to my system would be software updates from Ubuntu, and I know that at least one update occurred.  Perhaps Ubuntu updated my gcc.  But my nRF5 SDK, J-Link, and toolchain would be untouched.

For most of last year, I had this exact same problem, which I documented here.  In addition to asking questions here, I inquired on the SEGGER forums.  I was advised to update JLink.  I tried a few different versions, but none of them helped.  I also asked questions on Ubuntu Forums.  I was assured that anything as serious as breaking a serial port driver would be immediately noticed and repaired by the Linux developers.  I'm not sure whether this is true.  Maybe we have a special case with the Nordic boards? 

So how did I fix this problem the last time?  Well, I didn't really.  When I upgraded from Ubuntu 17.04 to 17.10, two-way UART communication was restored.  That is a strong hint to me that the OS is involved.  Furthermore: I can tell you that two-way UART communication between my Nordic boards and the Windows OS still functioned even when Linux was not.  I haven't tested that yet today.  I will post an update if I discover that is not true this time.

I hope that someone can offer some insight and advice.  Thanks!

[ivansanchez]

There are a few tricks you can use:

* Temporarily disable ModemManager. On some cases, ModemManager sends spurious AT commands to anything which looks like a serial port. Some programs loaded as firmware might not behave properly when AT commands appear on the serial port.

* Run Wireshark, sniffing the USB traffic to the devkit (remember to use a filter based on the USB bus / USB peripheral address). This will tell you if, in fact, there is data flowing even if your application doesn't display it (even if your application is a minicom or something like that).

* Bypass the Segger IMCU, and connect a serial port adapter to GPIO pins 6 and 8. You can use an off-the-shelf $10 serial port to USB adaptor (which will do the same job as the Segger IMCU), or even solder together a RS-232 DE-9 connector. Do check the datasheets and pin assignments before attempting this. If there is a problem in the Segger IMCU, this should bypass it.

* If you have the equipment, plop a logic analyzer (or even a hi-res scilloscope, if you have that) into GPIO pins 6 and 8.

[Simen August Tinderholt]

That sounds like an issue with flow control. In addition to Ivans suggestions you can try pulling RTS (P0.05) low, and see if that fixes your problem.
In some setups the IMCU can have issues detecting the correct setup for flow control, especially when combined with the ModemManager issues.

[Ladasky]

Thank you Simen for your suggestions, please see my reply to ivansanchez.

[Ladasky]

Thank you ivansanchez for your suggestions.  As of now, I have full UART function again.  Once again, I did nothing!  I updated nothing from Nordic, nor from SEGGER.  An Ubuntu system update is my only explanation for why things might be working again.

I have a logic analyzer connected to my system.  I have looked at the UART lines when running either the Nordic UART example or the transmit-only version of my own application.

In all cases, CTS as viewed from the Nordic side appears to be low all the time.  I think that CTS and RTS are active low?  So that's good?

When running the Nordic UART app, RTS is low almost all the time.  It goes high and then back low about 100 μsec before the "Start:" message is transmitted. I am surprised to see almost identical activity on both TXD and RXD when "Start:" is sent.  The only difference between the two signals appears to be in the timing of pulse edges.  I would have thought that only TXD would be active at that time.

I am less surprised to see both TXD and RXD respond when I type, since of course the Nordic first receives a character and then it echoes it back.  Still, it's a little strange to me.  RXD is active first.  The character is being received.  But then RXD immediately repeats itself while TXD simultaneously transmits the same thing.

In my own app, I have not been able to observe CTS or RTS ever go high.  Since data is flowing, I think that's fine.  Once again though, even though the Nordic is currently only transmitting, both TXD and RXD show nearly identical activity.  That part I do not understand. 

I am going to attempt to restore the ability of my host computer to send commands to the Nordic and see how that goes.

If anyone has any suggestions as to why this problem ever exists in the first place, I would be grateful.  Thanks!

[mon2]

If indeed HARDWARE flow control is active on the UART then RTS & CTS work together as allow for the stop / go of the UART traffic. Review the schematic of the UART pinout to see if RTS and/or CTS pins are being used at all in the kit. If not, strap them together to bypass the hardware flow control feature. This is a quick work around to pacify these interface lines.