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

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

tjh — Tue, 31 Jul 2018 07:38:36 GMT

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.

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

Martin Lesund — Fri, 27 Jul 2018 11:33:08 GMT

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.

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

tjh — Mon, 02 Jul 2018 08:15:42 GMT

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.

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

ivansanchez — Tue, 19 Jun 2018 14:17:39 GMT

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.

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

tjh — Tue, 19 Jun 2018 09:51:48 GMT

Hello Martin,

Using the same hex file as in SDK v12.3.0, I used this command:

$> picocom /dev/ttyACM0 --baud 115200 --databits 8 --parity n --flow n

Which unfortunately has the same effect. Please also note that:

These are the default settings in picocom (as well as minicom, screen, tmux, etc), but I made them more explicit.
The stop-bit setting is default set to 1.

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

Martin Lesund — Tue, 19 Jun 2018 09:35:23 GMT

Hi Tyler,

I would like you to try one more thing could you try with minicom with these settings?:

Same result?

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

tjh — Thu, 14 Jun 2018 12:51:44 GMT

Certainly.

Both were compiled with unmodified SDK versions v12.3.0 and v15.0.0 under examples/peripherals/uart/pca10056/blank/armgcc.

This is the version for SDK v15.0.0, which works.

devzone.nordicsemi.com/.../nrf52840_5F00_xxaa_5F00_sdk_5F00_15_5F00_0_5F00_0.hex

This is the version for SDK v12.3.0, which does not work.

devzone.nordicsemi.com/.../nrf52840_5F00_xxaa_5F00_sdk_5F00_12_5F00_3_5F00_0.hex

For both, I used this command:

$> picocom /dev/ttyACM0 --baud 115200

However, I've tried with other serial emulators (screen, etc) which all had the same effect. I have also tested with different baud rates, to no effect.

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

Martin Lesund — Thu, 14 Jun 2018 12:43:01 GMT

Hi Tyler,

Could you share your .hex files you are using and the program/script which is reading/writing to the serial port?

We could make this case private if it's sensitive information.

Thanks

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

tjh — Thu, 14 Jun 2018 06:47:43 GMT

Hello Martin,

This seems to solve the issue. It appears that the development kit is also connected in a different way, as such:

  13 Jun 14 08:38:23 tylerpc kernel: [  871.719864] usb 1-4: new high-speed USB device number 9 using xhci_hcd
  14 Jun 14 08:38:23 tylerpc kernel: [  871.860484] usb 1-4: config 1 interface 1 altsetting 0 bulk endpoint 0x83 has invalid maxpacket 64
  15 Jun 14 08:38:23 tylerpc kernel: [  871.860491] usb 1-4: config 1 interface 1 altsetting 0 bulk endpoint 0x4 has invalid maxpacket 64
  16 Jun 14 08:38:23 tylerpc kernel: [  871.860904] usb 1-4: New USB device found, idVendor=1366, idProduct=1015
  17 Jun 14 08:38:23 tylerpc kernel: [  871.860911] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  18 Jun 14 08:38:23 tylerpc kernel: [  871.860916] usb 1-4: Product: J-Link
  19 Jun 14 08:38:23 tylerpc kernel: [  871.860920] usb 1-4: Manufacturer: SEGGER
  20 Jun 14 08:38:23 tylerpc kernel: [  871.860924] usb 1-4: SerialNumber: 000683607511

Although I need to also support nRF51 as well, so that means I'm using SDK v12.3.0. Will this pose an issue? Was the problem in the JLink driver?

Edit: Testing with SDK v12.3.0 seems to repeat the problem, and I'm almost certain it has to do with being classified as "cdc_acm". If I flash with SDK v12.3.0 and leave it connected, it works perfectly. As soon as I reconnect, I get this output with "cdc_acm":

186 Jun 14 08:58:46 tylerpc kernel: [ 2095.495558] usb 1-4: new high-speed USB device number 12 using xhci_hcd
 187 Jun 14 08:58:46 tylerpc kernel: [ 2095.636358] usb 1-4: config 1 interface 1 altsetting 0 bulk endpoint 0x83 has invalid maxpacket 64
 188 Jun 14 08:58:46 tylerpc kernel: [ 2095.636367] usb 1-4: config 1 interface 1 altsetting 0 bulk endpoint 0x4 has invalid maxpacket 64
 189 Jun 14 08:58:46 tylerpc kernel: [ 2095.636962] usb 1-4: New USB device found, idVendor=1366, idProduct=1015
 190 Jun 14 08:58:46 tylerpc kernel: [ 2095.636970] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 191 Jun 14 08:58:46 tylerpc kernel: [ 2095.636975] usb 1-4: Product: J-Link
 192 Jun 14 08:58:46 tylerpc kernel: [ 2095.636980] usb 1-4: Manufacturer: SEGGER
 193 Jun 14 08:58:46 tylerpc kernel: [ 2095.636985] usb 1-4: SerialNumber: 000683607511
 194 Jun 14 08:58:46 tylerpc kernel: [ 2095.638647] cdc_acm 1-4:1.0: ttyACM0: USB ACM device
 195 Jun 14 08:58:46 tylerpc kernel: [ 2095.640415] usb-storage 1-4:1.3: USB Mass Storage device detected
 196 Jun 14 08:58:46 tylerpc kernel: [ 2095.641006] scsi host3: usb-storage 1-4:1.3
 197 Jun 14 08:58:46 tylerpc mtp-probe: checking bus 1, device 12: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4"
 198 Jun 14 08:58:46 tylerpc mtp-probe: bus: 1, device: 12 was not an MTP device
 199 Jun 14 08:58:47 tylerpc kernel: [ 2096.668515] scsi 3:0:0:0: Direct-Access     SEGGER   MSD Volume       1.00 PQ: 0 ANSI: 4
 200 Jun 14 08:58:47 tylerpc kernel: [ 2096.670032] sd 3:0:0:0: Attached scsi generic sg1 type 0
 201 Jun 14 08:58:47 tylerpc kernel: [ 2096.670135] sd 3:0:0:0: [sdb] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB)
 202 Jun 14 08:58:47 tylerpc kernel: [ 2096.670588] sd 3:0:0:0: [sdb] Write Protect is off
 203 Jun 14 08:58:47 tylerpc kernel: [ 2096.670598] sd 3:0:0:0: [sdb] Mode Sense: 0b 00 00 08
 204 Jun 14 08:58:47 tylerpc kernel: [ 2096.671166] sd 3:0:0:0: [sdb] No Caching mode page found
 205 Jun 14 08:58:47 tylerpc kernel: [ 2096.671184] sd 3:0:0:0: [sdb] Assuming drive cache: write through
 206 Jun 14 08:58:47 tylerpc kernel: [ 2096.675434]  sdb:
 207 Jun 14 08:58:47 tylerpc kernel: [ 2096.676814] sd 3:0:0:0: [sdb] Attached SCSI removable disk
 208 Jun 14 08:58:48 tylerpc udisksd[4618]: Mounted /dev/sdb at /media/tyler/JLINK on behalf of uid 1000

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

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

Martin Lesund — Wed, 13 Jun 2018 15:58:00 GMT

Hi Tyler,

Could you try the example from the newest SDK (v15) instead?

Also I would recommend you to downgrade the Jlink software to v6.22 instead. (it is the latest known stable version)

Please report back with your findings.

Thanks