Unable to send data via UART using NRF52-DK on Ubuntu

[tjh]

Hi!

I'm using a barebones example project from SDK 12.3.0, under examples/peripheral/uart, with two versions of nRF52-DK boards (pca10056 and pca10040). The goal is to read and write UART data from a serial port.

I can confirm this works both ways on a Windows machine, but on an Ubuntu machine, I can only read. Furthermore, it *sometimes* works to send data, but it is not reliable. I suspect this has something to do on how Ubuntu is handling the serial ports, in reference to cdc_acm, as this isn't a problem that I'm seeing on nRF devices using a different UART solution. In fact, it seems related to this issue: https://devzone.nordicsemi.com/f/nordic-q-a/29209/nrf52-dk-embedded-serial-port-issues-on-ubuntu but I have removed ModemManager, with no effect.

My output in /var/log/syslog is as follows:

   53 Jun 13 10:44:06 tylerpc kernel: [ 8534.941739] usb 1-2.2.1: new high-speed USB device number 11 using xhci_hcd
   54 Jun 13 10:44:06 tylerpc kernel: [ 8535.054587] usb 1-2.2.1: config 1 interface 1 altsetting 0 bulk endpoint 0x83 has invalid maxpacket 64
   55 Jun 13 10:44:06 tylerpc kernel: [ 8535.054594] usb 1-2.2.1: config 1 interface 1 altsetting 0 bulk endpoint 0x4 has invalid maxpacket 64
   56 Jun 13 10:44:06 tylerpc kernel: [ 8535.055120] usb 1-2.2.1: New USB device found, idVendor=1366, idProduct=1015
   57 Jun 13 10:44:06 tylerpc kernel: [ 8535.055127] usb 1-2.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
   58 Jun 13 10:44:06 tylerpc kernel: [ 8535.055131] usb 1-2.2.1: Product: J-Link
   59 Jun 13 10:44:06 tylerpc kernel: [ 8535.055136] usb 1-2.2.1: Manufacturer: SEGGER
   60 Jun 13 10:44:06 tylerpc kernel: [ 8535.055140] usb 1-2.2.1: SerialNumber: 000683607511
   61 Jun 13 10:27:47 tylerpc gnome-session[8986]: (gnome-software:9697): Gs-WARNING **: failed to call gs_plugin_refine_app on icons: Ikonet "application-x-firmware" er ikke tilgængeligt i temaet (null)
   62 Jun 13 10:44:06 tylerpc mtp-probe: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2.1"
   63 Jun 13 10:44:06 tylerpc mtp-probe: bus: 1, device: 11 was not an MTP device
   64 Jun 13 10:44:06 tylerpc kernel: [ 8535.111709] cdc_acm 1-2.2.1:1.0: ttyACM0: USB ACM device
   65 Jun 13 10:44:06 tylerpc kernel: [ 8535.113025] usbcore: registered new interface driver cdc_acm
   66 Jun 13 10:44:06 tylerpc kernel: [ 8535.113027] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
   67 Jun 13 10:44:06 tylerpc kernel: [ 8535.114276] usb-storage 1-2.2.1:1.3: USB Mass Storage device detected
   68 Jun 13 10:44:06 tylerpc kernel: [ 8535.116376] scsi host3: usb-storage 1-2.2.1:1.3
   69 Jun 13 10:44:06 tylerpc kernel: [ 8535.117242] usbcore: registered new interface driver usb-storage
   70 Jun 13 10:44:06 tylerpc kernel: [ 8535.121310] usbcore: registered new interface driver uas
   71 Jun 13 10:44:07 tylerpc kernel: [ 8536.146845] scsi 3:0:0:0: Direct-Access     SEGGER   MSD Volume       1.00 PQ: 0 ANSI: 4
   72 Jun 13 10:44:07 tylerpc kernel: [ 8536.148478] sd 3:0:0:0: Attached scsi generic sg1 type 0
   73 Jun 13 10:44:07 tylerpc kernel: [ 8536.148774] sd 3:0:0:0: [sdb] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB)
   74 Jun 13 10:44:07 tylerpc kernel: [ 8536.149072] sd 3:0:0:0: [sdb] Write Protect is off
   75 Jun 13 10:44:07 tylerpc kernel: [ 8536.149080] sd 3:0:0:0: [sdb] Mode Sense: 0b 00 00 08
   76 Jun 13 10:44:07 tylerpc kernel: [ 8536.149380] sd 3:0:0:0: [sdb] No Caching mode page found
   77 Jun 13 10:44:07 tylerpc kernel: [ 8536.149393] sd 3:0:0:0: [sdb] Assuming drive cache: write through
   78 Jun 13 10:44:07 tylerpc kernel: [ 8536.153410]  sdb:
   79 Jun 13 10:44:07 tylerpc kernel: [ 8536.155003] sd 3:0:0:0: [sdb] Attached SCSI removable disk
   80 Jun 13 10:44:08 tylerpc udisksd[9849]: Mounted /dev/sdb at /media/tyler/JLINK on behalf of uid 1000

I am using the latest JLink software, V6.32f.

[ivansanchez]

I'm testing out those .hex files on a nRF52840 pca10056 devkit, and works as expected, with no other setup than setting the permissions of /dev/ttyACM0 with a "chmod 666 /dev/ttyACM0" on a stock Ubuntu 17.10.

What I'm doing is:

* Open up a console, start a "cat /dev/ttyACM0"

* Reset the devkit

* See the text "UART example started" appear

* Open up another console, run a "echo q > /dev/ttyACM0"

* See "q" echo back, then "Exit" on the first console

Can you please try this, and then report your exact results?

---

I am using the latest JLink software, V6.32f.

J-link software doesn't apply. The IMCU exposes three functional interfaces: MSD (mass storage, automatically mounts at /media/tyler/JLINK in your case), CDC-ACM (automatically maps to /dev/ttyACM0 or ttyACM1, etc), and the proprietary j-link interface. The J-link software is only needed for the latter.

You can check this by running "lsusb --tree". You'll see how the different linux kernel drivers take charge of handling each specific funcional interface. Note that there are two interfaces for USB CDC ACM; this is normal and they are linked through something called a "functional interface descriptor" (you can find more information about this in the USB specs about the PSTN class interfaces).

Also note that the USB interfaces do NOT depend on the firmware loaded in the nRF chip. The USB functionality on the USB connector on the short side of the board is handled exclusively by the segger IMCU. If you intend to use the USB connector on the long side of the board (marked "nRF USB") then you want to have a look at the USB libraries on the nRF SDK, and specifically at the USB CDC ACM library. In this case you can be sure that the USB behaviour depends exclusively on the firmware loaded on the nRF chip, and not on the IMCU.

If you really really think that data is not flowing out of your computer and into the IMCU, I suggest using Wireshark to sniff the USB data. It's cumbersome (and you'll need to refer to some semi-obscure USB specs), but the USB transfers for the baud rate, data lines, and actual data can be seen.

If you really really think that the IMCU is not sending data to the nRF's UART, then I suggest plopping a logic analyzer into pins P0.06 and P0.08 (and 5 and 7 as well if you can). Yes, I know that logic analyzers are expensive and not all people have access to one. Remember that the nRF has a UART, but what you're seeing from the IMCU is a USB CDC ACM interface with the same data. If in doubt (or if USB is giving you too much trouble), procure some hardware capable of communicating directly to the UART and use pins P0.05-P0.08 directly.

Is there a way that I can force it to stay in "xhci_hcd" for SDK v12.3.0?

You're mixing concepts here. "xhci_hcd" is the kernel driver that handles the Host Controller Interface, that is, the hardware in your computer that handles the USB ports and detects when a new USB device is plugged in (or out; it also handles stuff like link speed negotiation). Once again, running "lsusb --tree" will help you visualize this.

Also try unplugging / plugging a USB mouse. You'll see how the xhci_hcd kernel driver detects a new device, enumerates it, and then tells the "usbhid" kernel driver to take care of the actual data.

Also note that if you use different (older) hardware, there will be a "ehci" or "ohci" kernel driver instead of a "xhci" one.

[tjh]

Thank you very much for the in-depth explanation!

I have a couple of interesting findings.

• I've switched to SDK v15.0.0 just to confirm that I have the same error. For all tests, I'm not using the nRF USB.
• If I flash the UART example (without a softdevice), everything works. However, after performing 'cat /dev/ttyACM0' one time, I can no longer write to the serial port, be it with picocom or with 'echo q > /dev/ttyACM0'. Perhaps something in Ubuntu is holding the port?
• If I flash the softdevice, and run the application in a different place in memory, then I can never write to the serial port. This one is especially puzzling, because if I do the above first (flash UART w/o softdevice), disconnect/reconnect via USB, and flash the softdevice/UART application, then everything works. If I do the reverse (softdevice + application, disconnect/reconnect, flash UART w/o softdevice) then it does not work.

I'm still not entirely sure if it's just my machine, because I tested with a different Ubuntu 16.04 and it looked like it worked, but I can't remember if I had done UART w/o softdevice or softdevice + UART.

I can provide 'dmesg' logs, or anything else that may give an indication towards the error. I still suspect that there's some strange configuration or package I've installed on Ubuntu that is giving me trouble.

[Martin Lesund]

Hi Tyler,

Sorry for the delay.

I assume that you may have found the reason behind this issue?

Or hopefully you keep using Ubuntu 16.04 with no problems.

[tjh]

Hello Martin,

Unfortunately, I still have the same issue. I'm using a workaround which may give a clue to the problem. If I flash with the UART example program from SDK 15.0.0, then it works every time, and I can write to the serial port. Afterwards, if I flash with the softdevice and the BLE example, then I can still write to the serial port.

Only if I unplug and plug in the nRF52 devkit, while running the softdevice, does it give me issues.