• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 20 replies
  • Subscribers 75 subscribers
  • Views 10640 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 200539
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents Reply Children
  • 0 in reply to ivansanchez

    huh ... i posted a txt file of this dump here yesterday ... I don't see it now?

  • 0 in reply to ivansanchez

    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)

  • 0 in reply to sdpan

    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.

  • 0 in reply to ivansanchez

    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)

  • 0 in reply to sdpan

    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.

Related
Terms of service