knurling-rs / probe-run

Run embedded programs just like native ones
Apache License 2.0
643 stars 75 forks source link

Access denied USB error despite non-root access enabled for probe #220

Closed ssnover closed 3 years ago

ssnover commented 3 years ago

Describe the bug I have followed directions for setting up a toolchain with probe-run as specified in the knurling-rs session 2020-q4. However, probe-run is not able to open the USB device.

The probe's file permissions are set to allow access from non-root users (via TAGS+="uaccess"):

$ lsusb
Bus 001 Device 004: ID 1366:1015 SEGGER J-Link
$ ls -l /dev/bus/usb/001/004
crw-rw-r--+ 1 root root 189, 3 May 31 16:18 /dev/bus/usb/001/004

To Reproduce Steps to reproduce the behavior:

Attempt to flash a binary with probe-run to the board connected to the probe (in my case the nRF52840 development kit):

probe-run --chip nRF52840_xxAA --probe '1366:1015' target/thumbv7em-none-eabihf/debug/hello

Expected and observed behavior A clear and concise description of what you expected to happen. Please include relevant console output.

probe-run successfully runs the binary:

$ cargo run --bin hello
     Running `probe-run --chip nRF52840_xxAA target/thumbv7em-none-eabihf/debug/hello`
  (HOST) INFO  flashing program (30.09 KiB)
  (HOST) INFO  success!

Observed instead:

$ probe-run --chip nRF52840_xxAA --probe '1366:1015' target/thumbv7em-none-eabihf/debug/hello
Error: An error specific to a probe type occured

Caused by:
    USB error while opening USB device: Access denied (insufficient permissions)

config.toml The contents of your project's .cargo/config.toml file

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip nRF52840_xxAA"
rustflags = [
  "-C", "linker=flip-link",
  "-C", "link-arg=-Tlink.x",
  "-C", "link-arg=-Tdefmt.x",
  # This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x
  # See https://github.com/rust-embedded/cortex-m-quickstart/pull/95
  "-C", "link-arg=--nmagic",
]

[build]
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)

[alias]
rb = "run --bin"
rrb = "run --release --bin"

Probe details You can get this information from probe-rs-cli. Your microcontroller must be connected to your PC / laptop when you run the command below.

$ probe-rs-cli list
The following devices were found:
[0]: J-Link (VID: 1366, PID: 1015,  JLink)

Operating System: Linux, Ubuntu 20.04, kernel 5.4.0-73-generic

ELF file (attachment) Don't believe it's relevant in this case, but I've saved a copy of the current ELF file and can provide it if necessary.

Additional context Add any other context about the problem here.

This is the udev rule associated with the device:

$ cat /etc/udev/rules.d/50-knurling.rules 
# udev rules to allow access to USB devices as a non-root user
# nRF52840 Dev Kit
ATTRS{idVendor}=="1366", ATTRS{idProduct}=="1015", TAG+="uaccess"

probe-run version:

$ probe-run -V
0.2.3
supported defmt version: 0.2

I have another system with the same versions of all the tools and same file permissions on the mounted USB device, but for which the command works so it appears there's another factor in play. If there's any additional debugging I can do to help determine the root cause and what's different I'm happy to do so. This doesn't block my developing since I can use the other system; it's only a minor inconvenience.

jonas-schievink commented 3 years ago

Does it work with a rule like this?

ATTRS{idVendor}=="1366", ATTRS{idProduct}=="1015", MODE="664", GROUP="plugdev"

(and you have to be in the plugdev group, of course)

ssnover commented 3 years ago

Yes, that did it! Thanks for the very quick response.

I noted that the symlink udev was creating was /dev/ttyACM0 under the dialout group, but this didn't seem all that suspicious to me since that's I'm used to seeing when working with serial ports on USB devices.