nRf9151 Development Kit (nRF9151DK) connection to laptop does not result in character device file creation (no /dev/ttyACM* ).

Hello nordic team! 

Issue:

I am reaching out because one of my nRF9151DK does not seem to  have associated character device files created when I plug it into my laptop, and thus I am not able to target it to flash application code. I do not think there is an issue with my laptop or associated kernel drivers, as my other nRF9151DK seems to work fine, and upon plugging into my machine, results in two character devices (/dev/ttyACM0 and /dev/ttyACM1) being created which I can use to flash binaries and serial print logs. 

 

Troubleshooting / What I've done

Looking at my dmesg logs below, it appears  that my  kernel 'cdc_acm' driver does not recognize the 'not-working' devkit, but recognize and create the associated character device files for the 'working' devkit. 

Not working devkit dmesg log:

[  555.740952] usb 1-1.4.2: new full-speed USB device number 16 using xhci_hcd
[  555.844023] usb 1-1.4.2: New USB device found, idVendor=1366, idProduct=0101, bcdDevice= 1.00
[  555.844040] usb 1-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  555.844047] usb 1-1.4.2: Product: J-Link
[  555.844052] usb 1-1.4.2: Manufacturer: SEGGER
[  555.844057] usb 1-1.4.2: SerialNumber: xxxxxxxxxxxxx

Working devkit dmesg log:

[  649.949527] usb 1-1.4.2: new full-speed USB device number 17 using xhci_hcd
[  650.052185] usb 1-1.4.2: New USB device found, idVendor=1366, idProduct=1059, bcdDevice= 1.00
[  650.052202] usb 1-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  650.052208] usb 1-1.4.2: Product: J-Link
[  650.052213] usb 1-1.4.2: Manufacturer: SEGGER
[  650.052218] usb 1-1.4.2: SerialNumber: xxxxxxxxxxxxx
[  650.084752] cdc_acm 1-1.4.2:1.0: ttyACM0: USB ACM device
[  650.086108] cdc_acm 1-1.4.2:1.2: ttyACM1: USB ACM device
[  650.088693] usb-storage 1-1.4.2:1.5: USB Mass Storage device detected
[  650.089609] scsi host3: usb-storage 1-1.4.2:1.5
[  650.091694] hid-generic 0003:1366:1059.000A: hiddev1,hidraw7: USB HID v1.00 Device [SEGGER J-Link] on usb-0000:00:14.0-1.4.2/input6
[  651.141165] scsi 3:0:0:0: Direct-Access     SEGGER   MSD Volume       1.00 PQ: 0 ANSI: 4
[  651.141946] sd 3:0:0:0: Attached scsi generic sg0 type 0
[  651.145083] sd 3:0:0:0: [sda] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB)
[  651.146009] sd 3:0:0:0: [sda] Write Protect is off
[  651.146021] sd 3:0:0:0: [sda] Mode Sense: 0b 00 00 08
[  651.146669] sd 3:0:0:0: [sda] No Caching mode page found
[  651.146681] sd 3:0:0:0: [sda] Assuming drive cache: write through
[  651.174603]  sda:
[  651.174676] sd 3:0:0:0: [sda] Attached SCSI removable disk

I also noticed that  the 'not-working' devkit appears to the 'lsusb' command as a 'SEGGER J-Link PLUS' device, while the 'working' devkit appears just as a 'SEGGER J-Link' device.

I have also tried to press and hold the RESET button on the devkit with no results - but I assume that only resets the application core or nRF9151 itself, not the OB debugger chip.

Possible solutions?

I was wondering if someone could share with me the recommended way to go about 're-flashing' the nRF9151DK with the factory firmware for it, so I may check and see if this resolves my issue, or if perhaps something is corrupt in the underlying hardware or with the OB Debugger itself, and thus it would not be worth trying to resolve.

I am skeptical that it would be an issue with my host laptop, as one of the devkits seems to work fine (both devkits were shipped as a pair together). 

Devlopment Setup:

Both devkits are : nRF9151DK  - HW v 0.9.0 

Host laptop OS: Ubuntu 24.04.1 

Parents
  • Hello,

    Can you please try running nrfutil device x-update-debug-probe-firmware to see if updating the interface chip resolves the issue?

    Kind regards,
    Abhijith

  • The other 'working' devkit has now begun to behave the same way... What could be causing this? I have done nothing with GPIOs or peripherals or arranged the hardware at all (the board is on an antistatic mat and hasn't been touched since it was working).

    All I have been doing is using minicom as a serial  terminal, and flashing the board with our project executables using west cli commands to build and flash the board .... 

    When I run the west 'flash' command, I have not been providing any information on the board target (I Imagine this is determined implicitly given its the only serial device I have connected to my laptop at the time)

    ---

    Turns out, when I use the vscode extension to flash the board, it now works ! 

    It looks like when I use the vscode extension the flash command is:

    west flash -d blahblahpath/example_programs/at_client/build --dev-id xxxxxxxxxx --erase

    The command I am entering manually into my terminal is:

    west flash -d blahblahpath/example_programs/at_client/build

    That being said, it would be nice to know why the second command (what I have traditionally been using via cli to build and flash the board) would work intermittently , while the first command 'revived' the OB debugger and allowed my kernel cdc_acm driver to 'see' the device.

  • What is the output when you run the command manually in the terminal? Also, what's the output of nrfutil device --version?

Reply Children
No Data
Related