pyOCD icon indicating copy to clipboard operation
pyOCD copied to clipboard

cannot find any libusb even though 2 are installed

Open nonchip opened this issue 3 years ago • 6 comments

First things first, OS: void Linux 5.11.15_1 #1 SMP 1618703302 x86_64 GNU/Linux PyOCD 0.30.2 installed through Mbed Studio (/home/kyra/.config/Mbed\ Studio/mbed-studio-tools/python/bin/pyocd and so on).

While Mbed Studio correctly identifies (in its target selection etc.) both my STLink (clone) and a board with builtin DFU bootloader (not using the STLink for that one, planning to go directly through the DFU mode), PyOCD doesn't even seem to be able to find a suitable libusb (showing a manual run there because mbed suppresses some info, stacktrace is the same tho):

$ /home/kyra/.config/Mbed\ Studio/mbed-studio-tools/python/bin/pyocd cmd -vv
0000388:WARNING:pyusb_backend:CMSIS-DAPv1 probes may not be detected because no libusb library was found.
0000418:WARNING:common:STLink and CMSIS-DAPv2 probes are not supported because no libusb library was found.
0000450:DEBUG:session:Project directory: /home/kyra
0000450:CRITICAL:__main__:No backend available
Traceback (most recent call last):
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/__main__.py", line 402, in run
    self._COMMANDS[self._args.cmd](self)
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/__main__.py", line 808, in do_commander
    PyOCDCommander(self._args, cmds).run()
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/commands/commander.py", line 65, in run
    if not self.connect():
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/commands/commander.py", line 166, in connect
    unique_id=self.args.unique_id,
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/core/helpers.py", line 138, in choose_probe
    allProbes = ConnectHelper.get_all_connected_probes(blocking=blocking, unique_id=unique_id)
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/core/helpers.py", line 82, in get_all_connected_probes
    allProbes = DebugProbeAggregator.get_all_connected_probes(unique_id=unique_id)
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/probe/aggregator.py", line 64, in get_all_connected_probes
    probes += cls.get_all_connected_probes(unique_id, is_explicit)
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/probe/picoprobe.py", line 333, in get_all_connected_probes
    return [cls(dev) for dev in PicoLink.enumerate_picoprobes()]
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pyocd/probe/picoprobe.py", line 108, in enumerate_picoprobes
    return [PicoLink(probe) for probe in core.find(find_all=True, custom_match=FindPicoprobe(uid))]
  File "/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/usb/core.py", line 1299, in find
    raise NoBackendError('No backend available')
usb.core.NoBackendError: No backend available

so i have 2 issues here: why does the picoprobe code (which isn't supposed to be used here, i don't even have that probe) crashing pyocd after 2 other devices were only warned about for the same reason? and why is it even thinking libusb to be unavailable?

$ ls -l /lib/libusb*
lrwxrwxrwx 1 root root     19 Nov 20  2018 /lib/libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
-rwxr-xr-x 1 root root  22432 Nov 20  2018 /lib/libusb-0.1.so.4.4.4
-rw-r--r-- 1 root root 208486 Apr  2 19:29 /lib/libusb-1.0.a
lrwxrwxrwx 1 root root     19 Apr  2 19:29 /lib/libusb-1.0.so -> libusb-1.0.so.0.3.0
lrwxrwxrwx 1 root root     19 Apr  2 19:29 /lib/libusb-1.0.so.0 -> libusb-1.0.so.0.3.0
-rwxr-xr-x 1 root root 116824 Apr  2 19:29 /lib/libusb-1.0.so.0.3.0
-rw-r--r-- 1 root root  20626 Nov 20  2018 /lib/libusb.a
lrwxrwxrwx 1 root root     19 Nov 20  2018 /lib/libusb.so -> libusb-0.1.so.4.4.4
lrwxrwxrwx 1 root root     23 Nov 10 04:19 /lib/libusbmuxd-2.0.so.6 -> libusbmuxd-2.0.so.6.0.0

(with /lib, /usr/lib, ... all being symlinked together on this distro)

libusb-1.0 being one of the names usb.backend.libusb1 explicitely tries:

def _load_library(find_library=None):
    #...
    return usb.libloader.load_locate_library(
                ('usb-1.0', 'libusb-1.0', 'usb'),
                'cygusb-1.0.dll', 'Libusb 1',
                win_cls=win_cls,
                find_library=find_library, check_symbols=('libusb_init',))

just in case, 32bit versions also exist in /lib32,/usr/lib32,... but i sure hope python won't need those. even the headers are installed and everything:

$ xbps-query -Rs libusb
[*] libgusb-0.3.6_1                   GLib wrapper around libusb1
[-] libgusb-devel-0.3.6_1             GLib wrapper around libusb1 - development files
[*] libusb-1.0.24_1                   Library which allows userspace access to USB devices
[*] libusb-compat-0.1.5_7             A libusb-0.1 compatibility library
[*] libusb-compat-devel-0.1.5_7       A libusb-0.1 compatibility library - development files
[*] libusb-devel-1.0.24_1             Library which allows userspace access to USB devices - development files
[-] libusbip-5.10.4_4                 USB device sharing system over IP network - runtime library
[-] libusbip-devel-5.10.4_4           USB device sharing system over IP network - development files
[*] libusbmuxd-2.0.2_1                USB Multiplex Daemon library
[-] libusbmuxd-devel-2.0.2_1          USB Multiplex Daemon library - development files
[*] libgusb-32bit-0.3.6_1             GLib wrapper around libusb1 (32bit)
[-] libgusb-devel-32bit-0.3.6_1       GLib wrapper around libusb1 - development files (32bit)
[*] libusb-32bit-1.0.24_1             Library which allows userspace access to USB devices (32bit)
[*] libusb-compat-32bit-0.1.5_7       A libusb-0.1 compatibility library (32bit)
[*] libusb-compat-devel-32bit-0.1.5_7 A libusb-0.1 compatibility library - development files (32bit)
[*] libusb-devel-32bit-1.0.24_1       Library which allows userspace access to USB devices - development files (32bit)
[-] libusbip-32bit-5.10.4_4           USB device sharing system over IP network - runtime library (32bit)
[-] libusbip-devel-32bit-5.10.4_4     USB device sharing system over IP network - development files (32bit)
[-] libusbmuxd-32bit-2.0.2_1          USB Multiplex Daemon library (32bit)
[-] libusbmuxd-devel-32bit-2.0.2_1    USB Multiplex Daemon library - development files (32bit)

oh and just to add insult to injury i just realized i'm regularly successfully using pyUSB with that very libusb1 to talk to a device of mine on that very machine.

nonchip avatar Apr 24 '21 16:04 nonchip

First thing, please update to pyocd 0.30.3. This fixes the first issue with the picoprobe related exception raised when it can't find libusb.

Short answer: I don't have any immediate ideas… 😓 pyusb has always "just worked" on every Linux system I've used. (And I'm not really much of a Linux user, mostly only using it through Docker on macOS.)

What distro are you using? I've always used Debian based distros, primarily Ubuntu. Though I know others have used pyocd successfully only other distros (Alpine comes to mind, there were a few others too).

Since pyusb works for you with another tool, let's look at what could be different between running that tool and pyocd.

  • Python executable and version?
  • Version of pyusb?
  • LD_LIBRARY_PATH (or equivalent)?
  • Anything else? As you've indicated, 32/64-bit shouldn't matter.

flit avatar Apr 24 '21 20:04 flit

I have observed similar problem on FreeBSD for some time/reason, reinstalling system dependencies and python modules helped :-) Let me know if that helps :-)

cederom avatar Apr 24 '21 20:04 cederom

First thing, please update to pyocd 0.30.3.

afraid i'd have to ask the mbed people to do that probably

This fixes the first issue with the picoprobe related exception raised when it can't find libusb.

i mean letting it find libusb would "fix" the issue for me too, and pretty sure i need libusb to work anyway to have it talk to the device via dfu over usb

What distro are you using?

void linux. used pyocd in mbed successfully a while ago on this very machine+os, they did an update to their IDE since though, probably that's what broke it.

let's look at what could be different between running that tool and pyocd.

that's the thing, i've been running it from both the ide (with whatever wrapping magic like LD_LIBRARY_PATH they might be doing there) and the terminal (so it's "just" the different wrapper), same difference. so it's probably something related to either the libs delivered with that or they're doing some more advanced wrapper magic

Version of pyusb?

$ cat ~/.config/Mbed\ Studio/mbed-studio-tools/python/lib/python3.7/site-packages/usb/_version.py
# coding: utf-8
# file generated by setuptools_scm
# don't change, don't track in version control
version = '1.1.1'

nonchip avatar Apr 24 '21 20:04 nonchip

void linux.

😄 I saw "void Linux" in the uname output you provided, but didn't realise that was the distro.

that's the thing, i've been running it from both the ide (with whatever wrapping magic like LD_LIBRARY_PATH they might be doing there) and the terminal (so it's "just" the different wrapper), same difference. so it's probably something related to either the libs delivered with that or they're doing some more advanced wrapper magic

I'm not sure if running the tools included with Mbed Studio directly from a shell is the same as running from the IDE. This might be more of a packaging issue than specifically related to pyocd; at this point it's not clear.

Can you try installing pyocd outside of Mbed Studio and see if that can find libusb? Assuming you already have Python 3.6 or above installed at the system level, you can run this to install pyocd (run from some directory like your home):

python3 -m venv pyocd-venv
source pyocd-venv/bin/activate
pip install pyocd
pyocd list

This creates a virtualenv for pyocd, activates the virtualenv, installs pyocd, and lists connected boards. (You can get out of the virtualenv by executing deactivate.)

flit avatar Apr 24 '21 20:04 flit

python3 -m venv pyocd-venv
source pyocd-venv/bin/activate
pip install pyocd
pyocd list
Successfully installed appdirs-1.4.4 capstone-4.0.2 cffi-1.14.5 cmsis-pack-manager-0.2.10 colorama-0.4.4 future-0.18.2 intelhex-2.3.0 intervaltree-3.1.0 milksnake-0.1.5 naturalsort-1.5.1 prettytable-2.1.0 psutil-5.8.0 pycparser-2.20 pyelftools-0.27 pylink-square-0.10.0 pyocd-0.30.3 pyocd-pemicro-1.0.4 pypemicro-0.1.6 pyusb-1.1.1 pyyaml-5.4.1 six-1.15.0 sortedcontainers-2.3.0 wcwidth-0.2.5

(pyocd-venv) 
# kyra @ firefly in ~/pyocdtest [7:23:08] 
$ pyocd list
No available debug probes are connected

so here it clearly loads libusb but sees no devices, even with the DFU one connected (and what looks like the correct perms):

$ lsusb
Bus 001 Device 021: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
$ ls -l /dev/bus/usb/001/021 
crw-rw-rw- 1 root root 189, 20 Apr 25 07:26 /dev/bus/usb/001/021

the STLink clone is getting detected though:

$ pyocd list                

  #   Probe          Unique ID                 
-----------------------------------------------
  0   STM32 STLink   0D0D01013212364D434B4E00  

so guess the DFU-not-showing-up thing is a separate issue then, will tinker with some udev rules and see what happens there.


after finding that ~/.config/Mbed\ Studio/mbed-studio-tools/python/bin/pip is a thing (and defaults to the correct paths), i ran an install -U pyocd pyusb usb for:

Successfully installed pyocd-0.30.3
Requirement already up-to-date: pyusb in ./.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages (1.1.1)
Successfully installed usb-0.0.83.dev0

which made it hang indefinitely running /home/kyra/.config/Mbed Studio/mbed-studio-tools/python/bin/python /home/kyra/.config/Mbed Studio/mbed-studio-tools/python/bin/pyocd flash --uid 358F345B3336 --target STM32F411RE --erase=chip --frequency 1800000 --pack /home/kyra/.config/Mbed Studio/mbed-studio-tools/cmsis-packs/Keil.STM32F4xx_DFP.2.15.0-small.pack -O connect_mode=under-reset /home/kyra/Mbed Programs/blackpill_tests/BUILD/NUCLEO_F411RE/ARMC6/blackpill_tests.bin, so i killed that and then it reported:

0000473:WARNING:pyusb_backend:CMSIS-DAPv1 probes may not be detected because no libusb library was found.
0000511:WARNING:common:STLink, CMSIS-DAPv2 and PicoProbe probes are not supported because no libusb library was found.

which i can only describe as weird. it was clearly trying to do something (at least i hope that's what the "hanging" meant), but after what i assume was trapping the sigterm it claims there's no libusb?

manually running /home/kyra/.config/Mbed\ Studio/mbed-studio-tools/python/bin/python /home/kyra/.config/Mbed\ Studio/mbed-studio-tools/python/bin/pyocd list with both the STLink and the DFU device (after adding a udev rule to give me permissions for it) gives:

0000382:WARNING:pyusb_backend:CMSIS-DAPv1 probes may not be detected because no libusb library was found.
0000416:WARNING:common:STLink, CMSIS-DAPv2 and PicoProbe probes are not supported because no libusb library was found.
No available debug probes are connected

the plot thickens:

$ find ~/.config/Mbed\ Studio -name "libusb*"
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libusb-1.0.so.0
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/pkgconfig/libusb-1.0.pc
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/pypemicro/libs/MacOS/libusb.dylib
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/usb/backend/__pycache__/libusb1.cpython-37.pyc
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/usb/backend/__pycache__/libusb0.cpython-37.pyc
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/usb/backend/libusb0.py
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/python3.7/site-packages/usb/backend/libusb1.py
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libusb-1.0.so
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libusb-1.0.so.0.3.0
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1/lib/libusb-1.0.so
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1/lib/pkgconfig/libusb-1.0.pc
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1/lib/libusb-1.0.so.0.3.0
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1/lib/libusb-1.0.so.0
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1/include/libusb-1.0
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1/include/libusb-1.0/libusb.h
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/pkgs/libusb-1.0.24-h9f566bc_1.tar.bz2
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/include/libusb-1.0
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/include/libusb-1.0/libusb.h
/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/conda-meta/libusb-1.0.24-h9f566bc_1.json

looks like they're packaging an ancient version?

$ ldd '/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libusb-1.0.so'
	linux-vdso.so.1 (0x00007ffd38fa1000)
	libudev.so.0 => not found
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f5ef4c49000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f5ef4c28000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f5ef4a62000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007f5ef4c9b000)

yeah, so um... i'm not exactly an expert but i'm pretty sure udev is both required for what it's trying to do there and way newer than .0 on my system

which they appear to have prepared for by supplying this BROKEN link:

lrwxrwxrwx 1 kyra kyra 34 Apr 24 14:21 '/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libudev.so.0' -> /lib/x86_64-linux-gnu/libudev.so.1
$ rm '/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libudev.so.0'
$ ln -s /lib/libudev.so.1 '/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/lib/libudev.so.0'
$ /home/kyra/.config/Mbed\ Studio/mbed-studio-tools/python/bin/python /home/kyra/.config/Mbed\ Studio/mbed-studio-tools/python/bin/pyocd list 

No available debug probes are connected

note the sudden lack of "libusb doesn't exist"!

there's still a problem with the DFU bootloader though, because mbed studio still just gets stuck at the "erasing" part with:

/home/kyra/.config/Mbed Studio/mbed-studio-tools/python/bin/python /home/kyra/.config/Mbed Studio/mbed-studio-tools/python/bin/pyocd flash --uid 358F345B3336 --target STM32F411RE --erase=chip --frequency 1800000 --pack /home/kyra/.config/Mbed Studio/mbed-studio-tools/cmsis-packs/Keil.STM32F4xx_DFP.2.15.0-small.pack -O connect_mode=under-reset /home/kyra/Mbed Programs/blackpill_tests/BUILD/NUCLEO_F411RE/ARMC6/blackpill_tests.bin

and a suspicious lack of any error messages/etc. killing that now results in mbed studio going "pyocd deploy failed, trying deploy via mass storage" which appears to be something the bootloader in my device doesn't support (i certainly don't see any block devices) and then just gives up, without any other error messages

nonchip avatar Apr 25 '21 05:04 nonchip

Well, I got this pyocd.probe.pydapaccess.dap_access_api.DeviceError: No USB backend found issue again on a fresh FreeBSD workstation, looks like something to investigate and fix, as all other applications work with USB with no problem :-)

(venv37zephyr) pyocd
Traceback (most recent call last):
  File "/home/x/usr/local/venv37zephyr/bin/pyocd", line 11, in <module>
    load_entry_point('pyocd==0.30.4.dev30', 'console_scripts', 'pyocd')()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 490, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2862, in load_entry_point
    return ep.load()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2462, in load
    return self.resolve()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2468, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/__init__.py", line 21, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/gdbserver/__init__.py", line 17, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/gdbserver/gdbserver.py", line 49, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/commands/commander.py", line 22, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/core/helpers.py", line 19, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/probe/aggregator.py", line 84, in <module>
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/core/plugin.py", line 88, in load_plugin_classes_of_type
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2462, in load
    return self.resolve()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2468, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/probe/cmsis_dap_probe.py", line 24, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/probe/pydapaccess/__init__.py", line 17, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 29, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.30.4.dev30-py3.7.egg/pyocd/probe/pydapaccess/interface/__init__.py", line 62, in <module>
pyocd.probe.pydapaccess.dap_access_api.DeviceError: No USB backend found


(venv37zephyr) uname -a
FreeBSD hexagon 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC  amd64

Update 1 Looks like I got the board with SEGGER J-Link not DAPLink. Is only DAPLink supported by pyOCD?

ugen5.5: <SEGGER J-Link> at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

Update 2 It looks that pyOCD does not work with SEGGER JLink only DAPLink. However, on the laptop with pyOCD 0.29.0, after connecting that particular board I have no traceback only a message that pyOCD is waiting for the probe :-)

(venv37zephyr) pyocd flash build/zephyr/zephyr.hex
Waiting for a debug probe to be connected...

(venv37zephyr) uname -a
FreeBSD 0xCFMX4 12.2-RELEASE-p3 FreeBSD 12.2-RELEASE-p3 #0 r358209M: Sat Jan 30 15:39:23 CET 2021     root@0xCFMX4:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

Update 3 pyOCD only works with DAPLink not with SEGGER JLink. After upgrading interface firmware to DAPLink v254 pyOCD we have:

  • On laptop with 0.29.0 still does not run because of kernel module unlock fails. This brings back the https://github.com/pyocd/pyOCD/issues/675..?
(venv37zephyr) pyocd flash build/zephyr/zephyr.bin
0001444:CRITICAL:__main__:uncaught exception: cannot import name 'ENODATA' from 'errno' (unknown location)
Traceback (most recent call last):
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/__main__.py", line 401, in run
    self._COMMANDS[self._args.cmd](self)
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/__main__.py", line 571, in do_flash
    with session:
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/core/session.py", line 343, in __enter__
    self.open()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/core/session.py", line 457, in open
    self._probe.open()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/probe/cmsis_dap_probe.py", line 148, in open
    self._link.open()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/utility/concurrency.py", line 28, in _locking
    return func(self, *args, **kwargs)
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 590, in open
    self._interface.open()
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd/probe/pydapaccess/interface/pyusb_backend.py", line 101, in open
    if dev.is_kernel_driver_active(interface_number):
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/usb/core.py", line 1100, in is_kernel_driver_active
    interface)
  File "/home/x/usr/local/venv37zephyr/lib/python3.7/site-packages/usb/backend/libusb0.py", line 624, in is_kernel_driver_active
    from errno import ENODATA
ImportError: cannot import name 'ENODATA' from 'errno' (unknown location)
  • On desktop pyOCD 0.30.4dev30 tracebacks with no USB backend. No change here :-( Here is the pyusb version information:
(venv37zephyr) pip show pyusb
Name: pyusb
Version: 1.1.1
Summary: Python USB access module
Home-page: https://pyusb.github.io/pyusb
Author: Robert Wlodarczyk
Author-email: [email protected]
License: UNKNOWN
Location: /home/x/usr/local/venv37zephyr/lib/python3.7/site-packages
Requires:
Required-by: pyocd
  • I can see that my proposition https://github.com/pyocd/pyOCD/issues/1032 of traceback was not used?

Update 4

  • Reinstalling latest upstream pyusb from sources does not help. There are no build problems but pyOCD still lacks USB backend on desktop. That error comes from pyusb so probably this is the cause of the problem. Already reported here https://github.com/pyusb/pyusb/issues/362 :-)

Update 5 Running USB device detection by hand with pyusb seems to find the interface and no backend issues are encuontered. Looks like pyOCD problem..? Maybe the kernel module unload? Note that standard user is not allowed (and should not be allowed) to remove kernel modules. We need to review this part of pyOCD code :-)

(venv37zephyr) pip install pyusb
Collecting pyusb
  Using cached pyusb-1.1.1-py3-none-any.whl (58 kB)
Installing collected packages: pyusb
Successfully installed pyusb-1.1.1
(venv37zephyr) python
Python 3.7.10 (default, Apr  8 2021, 01:15:14)
[Clang 10.0.1 ([email protected]:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611a on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> usb.core.find()
<DEVICE ID 0d28:0204 on Bus 000 Address 018>
ugen5.5: <ARM DAPLink CMSIS-DAP> at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0210
  bDeviceClass = 0x00ef  <Miscellaneous device>
  bDeviceSubClass = 0x0002
  bDeviceProtocol = 0x0001
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0d28
  idProduct = 0x0204
  bcdDevice = 0x0100
  iManufacturer = 0x0001  <ARM>
  iProduct = 0x0002  <DAPLink CMSIS-DAP>
  iSerialNumber = 0x0003  <110136025020312038534751303036203530303897969903>
  bNumConfigurations = 0x0001

Update 6 The problem comes from static list of supported platforms and USB backends at pyocd/probe/pydapaccess/interface/__init__.py - none of BSD platforms was checked and there is no default backend to use.

  • I have added detection of BSD to use pyusb as their backend. Fix here: https://github.com/pyocd/pyOCD/pull/1153.
  • I have modified error message not to mislead with pyusb errors ("No USB backend found" -> "Unknown platform! No USB Interface backend autoselected."). Fix here: https://github.com/pyocd/pyOCD/pull/1154.
  • I have added a helper script to allow quick debug python directly form the Unix shell (https://github.com/pyocd/pyOCD/pull/1151).
  • We can consider pyusb as the default USB Interface fallback. Discussion is opened here: https://github.com/pyocd/pyOCD/issues/1157.
  • I have noticed that internals of pyOCD chaged dramatically recently. I would highly suggest a major release number bump. Discussion here: https://github.com/pyocd/pyOCD/issues/1155.

cederom avatar May 11 '21 14:05 cederom