JLink serial (ttyACM0 over usb) drops out, usb device re-enumerates but ttyACM isn't found

[sdpan]

I'm using three nrf52840-dk's, from an ubuntu 16.04 x64 host. 

• JLink v6.30b
• nrfjprog v9.7.2

I can program and interact with two boards fine, with zero of the failures below.  However, the third board is having problems.  This may be the first time I've tried to use the board, and it's always possible there is a HW issue.  I'm hoping to understand what, if any, steps there may be to bring the board back (eg, is there FW on the Jlink or nrf52 side that could possibly be in a bad state that I could fix without scrapping the board).  I've tried different cables; also as mentioned my two other boards work fine.

The problems is that any attempt to write to the ttyACM cause the part to disconnect.

On the board I'm seeing issues:

1. plug in via USB. 
   1. Enumerates fine as both Mass-storage (seems to work fine) and Abstract control module serial (/dev/ttyACM0).
2. Run, for example:  
   1. `nrfjprog -f nrf52 -e --log`
3. The next message on both `dmesg` and `/var/log/syslog` is: 
   1. "Usb disconnect"
4. This is followed by the device re-enumerating ... BUT the ttyACM and filesystem do not come back
5. I can unplug and re-plug the device, and my pc enumerates both the ttyACM and the mass-storage

nrfjprog log:

--------------------------------------------------------------------------------
nrfjprog -f nrf52 -e --log
nrfjprog verion 9.7.2
--------------------------------------------------------------------------------
FUNCTION: open_dll.
FUNCTION: open_dll.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_without_snr.
FUNCTION: enum_emu_snr.
Updating firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 12 2018 16:05:20
Replacing firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12
JLinkARM.dll OpenEx returned error 'Communication timed out - Can not execute firmware update'.
FUNCTION: close_dll.
FUNCTION: close_dll.
developer@7a2d4d5d225c:~/nRF5_tools/nrf5_sdk/examples/ble_peripheral/ble_app_hts/pca10056/s140/armgcc$ exit
exit

As above, immediately after executing the nrfjprog, the device disconnects, then re-enumerates (but, apparently in a problematic state as ttyACM0 doesn't return)

kernel: [1116808.385970] usb 1-5.1: USB disconnect, device number 64
udisksd[2229]: Cleaning up mount point /media/mike/JLINK1 (device 8:16 no longer exist)
kernel: [1116808.422544] FAT-fs (sdb): unable to read boot sector to mark fs as dirty
kernel: [1116808.654667] usb 1-5.1: new high-speed USB device number 65 using xhci_hcd
mtp-probe: checking bus 1, device 65: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1"
mtp-probe: bus: 1, device: 65 was not an MTP device
kernel: [1116808.755452] usb 1-5.1: New USB device found, idVendor=1366, idProduct=0101
kernel: [1116808.755454] usb 1-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [1116808.755455] usb 1-5.1: Product: J-Link
kernel: [1116808.755455] usb 1-5.1: Manufacturer: SEGGER
kernel: [1116808.755456] usb 1-5.1: SerialNumber: 000683350409
wpa_supplicant[1618]: wlp2s0: CTRL-EVENT-SCAN-FAILED ret=-100

What can i do to triage / possibly fix this?

[ivansanchez]

Could you please post the result of running "lsusb -v -d 1366:"? That will display the USB descriptors for any Segger IMCUs connected through USB.

Please note that a Segger IMCU can enable/disable mass storage and USB-CDC-ACM, as noted in http://docs.zephyrproject.org/tools/nordic_segger.html#nordic-segger-msd . Also be aware that the USB Product ID (0x0101 in your case) changes as the IMCU is configured (as you can see from having a look at /etc/udev/rules.d/99-jlink.rules )

[sdpan]

pasting instead of attaching:

Bus 001 Device 085: ID 1366:1015 SEGGER 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x1366 SEGGER
  idProduct          0x1015 
  bcdDevice            1.00
  iManufacturer           1 SEGGER
  iProduct                2 J-Link
  iSerial                 3 000683350409
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          121
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          4 Configuration
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       0 None
      iFunction               5 CDC
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              5 CDC
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x87  EP 7 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               8
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              6 CDC DATA interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              7 BULK interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              8 MSD interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

[ivansanchez]

This tiny bit here:

      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       0 None

tells me that, in fact, the USB device has a CDC ACM interface. The cdc_acm kernel driver should pick that up on re-enumeration, and create the /dev/ttyACM* node, and then let udev handle it (to create symlinks under /dev/serial/*).

In those cases when the devkit reenumerates and /dev/ttyACM0 doesn't appear, please run lsusb again, and check for the above lines in the interface descriptors. Also confirm that the cdc_acm kernel module is loaded ("lsmod"), and that it does **not** output "cdc_acm 1-1.4.3:1.0: ttyACM0: USB ACM device" on your syslog and on dmesg.

I just want to be sure there are no inconsistencies in how Linux is handling this.

[sdpan]

Yes, the above post is BEFORE trying to touch the part via the nordic tools; Here is the same lsusb AFTER the device spontaneously re-enumerates (sans ttyACM).  The Interface descriptor appears to be 0xFF?

Bus 001 Device 104: ID 1366:0101 SEGGER J-Link PLUS
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1366 SEGGER
  idProduct          0x0101 J-Link PLUS
  bcdDevice            1.00
  iManufacturer           1 SEGGER
  iProduct                2 J-Link
  iSerial                 3 000683350409
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 Configuration
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              5 J-Link
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

[ivansanchez]

No, look at the normal case. There are four interface descriptors: two for USB-CDC-ACM (the serial port) with class/subclass 2/2 and 10/0; one for the mass storage with class/subclass 8/6, and one for the propietary jlink protocol with class/subclass 255/255. It's perfectly legal for a USB device to have many interfaces. It's also legal for a USB device to re-enumerate itself with different interfaces and different descriptors. (And yeah, it's a PITA when those changes are not intended by an user)

Keep in mind that you can enable/disable the mass storage interface and the USB-CDC-ACM interface as described in this bit of documentation for the Zephyr project.

It's weird that the mass storage and USB-CDC-ACM interfaces are disabled in a segger without an explicit request to disable them, though.

I must suggest upgrading the segger firmware manually through the mass storage interface - get segger firmware files from here and copy them to the mass storage volume. The board should reset after that, and hopefully you will **not** see the string "J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12" when running JLinkExe.

I mean, it's worth a try.

[sdpan]

The latest at that link is "J-Link...170724.bin"  That looks a lot like at datestamp of Jul 24 2017 (?)

I tried copying it over several times.  One time, the device did reset.  I am not 100% sure which section of dmesg this was, so can't tell 100% it did a full re-enumeration.  The other times (I tried 5 times, power cycling the device each time):

### unplug USB

[1528937.666008] usb 1-5.2: USB disconnect, device number 114

### plug it back in

[1528941.983432] usb 1-5.2: new high-speed USB device number 115 using xhci_hcd
[1528942.084148] usb 1-5.2: config 1 interface 1 altsetting 0 bulk endpoint 0x83 has invalid maxpacket 64
[1528942.084153] usb 1-5.2: config 1 interface 1 altsetting 0 bulk endpoint 0x4 has invalid maxpacket 64
[1528942.084642] usb 1-5.2: New USB device found, idVendor=1366, idProduct=1015
[1528942.084646] usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1528942.084649] usb 1-5.2: Product: J-Link
[1528942.084651] usb 1-5.2: Manufacturer: SEGGER
[1528942.084654] usb 1-5.2: SerialNumber: 000683350409
[1528942.087099] cdc_acm 1-5.2:1.0: ttyACM0: USB ACM device
[1528942.088279] usb-storage 1-5.2:1.3: USB Mass Storage device detected
[1528942.088501] scsi host6: usb-storage 1-5.2:1.3
[1528943.108201] scsi 6:0:0:0: Direct-Access     SEGGER   MSD Volume       1.00 PQ: 0 ANSI: 4
[1528943.109065] sd 6:0:0:0: Attached scsi generic sg1 type 0
[1528943.109240] sd 6:0:0:0: [sdb] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB)
[1528943.109599] sd 6:0:0:0: [sdb] Write Protect is off
[1528943.109604] sd 6:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[1528943.109898] sd 6:0:0:0: [sdb] No Caching mode page found
[1528943.109906] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[1528943.113960]  sdb:
[1528943.115242] sd 6:0:0:0: [sdb] Attached SCSI removable disk

### enumeration finished, ubuntu auto-mounts sdb
### copy the J-Link OB-SAM3U128-V2-NordicSemi 170724.bin over

[1528962.079410] usb 1-5.2: reset high-speed USB device number 115 using xhci_hcd
[1528962.180672] cdc_acm 1-5.2:1.0: ttyACM0: USB ACM device

### no other activity

The one time the device auto-reset, /dev/sdb was disconnected (as would be expected) and eventually auto-mounted again after it re-enumerated.  With this case, the .bin file was no longer present in sdb

The remainder of the times, which all had the exact dmesg above, sdb remained mounted, and the bin file remained until i power cycled via the usb cable.

After this, firing up JLink again, i see the same result:

$JLinkExe -device nrf52840_xxaa -if swd -speed 1000
SEGGER J-Link Commander V6.30c (Compiled Feb  9 2018 17:22:34)
DLL version V6.30c, compiled Feb  9 2018 17:22:28

Connecting to J-Link via USB...Updating firmware:  J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 12 2018 16:05:20
Replacing firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12
FAILED: Communication timed out - Can not execute firmware update

[tralamazza]

I found that the PlatformIO udev rules were causing this exact problem for me.