"Unable to connect" in Windows (building with Git for Windows SDK)

[ShawnHymel]

I'm running into the following error after building picotool on Windows 10:

No accessible RP2040 devices in BOOTSEL mode were found.

but:

Device at bus 1, address 20 appears to be a RP2040 device in BOOTSEL mode, but picotool was unable to connect

The Getting Started guide says to use sudo to fix this, but that's for Linux. How do you fix this issue on Windows? I have the Raspberry Pi Pico in BOOTSEL mode as required.

---

Please note that I did not build picotool with Build Tools for Visual Studio. Instead, I did the following:

Set up Pico C/C++ toolchain using Git Bash and MinGW instead of Build Tools for Visual Studio following the instructions here: https://shawnhymel.com/2096/how-to-set-up-raspberry-pi-pico-c-c-toolchain-on-windows-with-vs-code/

In order to get the pacman package manager, I installed Git for Windows SDK from this site: https://gitforwindows.org/.

From there, I opened the git-bash.exe from C:\git-sdk-64 (Git for Windows SDK installation directory) to build OpenOCD:

pacman -Syu 
pacman -Su
pacman -S mingw-w64-x86_64-toolchain git make libtool pkg-config autoconf automake texinfo mingw-w64-x86_64-libusb 
cd /c/VSARM/sdk/pico
git clone https://github.com/raspberrypi/openocd.git --branch picoprobe --depth=1 
cd openocd
./bootstrap
./configure --enable-picoprobe --disable-werror
make -j4

I was also able to use those packages to build picotool:

cd /c/VSARM/sdk/pico
git clone -b master https://github.com/raspberrypi/picotool.git 
cd picotool
mkdir build
cd build
cmake -G "MinGW Makefiles" -DPC_LIBUSB_INCLUDEDIR="/c/git-sdk-64/mingw64/include/libusb-1.0" ..
make
cp /c/git-sdk-64/mingw64/bin/libusb-1.0.dll .

I can run picotool successfully (Pico is connected and in BOOTSEL mode):

./picotool.exe info

However, that results in the error above, and I'm afraid I'm stuck.

I realize that this is not the method outlined in the Getting Started guide, but I would appreciate any help trying to figure out why picotool cannot connect.

[kilograham]

On Windows, you need to add a driver for the non-standard interface used by picotool; this is exactly the same as for setting up a driver (using zadig) for picoprobe near about page 62 here https://datasheets.raspberrypi.org/pico/getting-started-with-pico.pdf

[ShawnHymel]

Thank you for the quick response!

In Zadig, I have two options:

1. RP2 Boot (Interface 0) with driver USBSTOR
2. RP2 Boot (Interface 1) with driver (NONE)

I'm guessing I need to replace Interface 1 driver (NONE) with libusb-win32 (as shown on p. 62), yes?

[kilograham]

Yup

[ShawnHymel]

Tried it, and now it gives me:

Segmentation fault

[ShawnHymel]

Looks like I've now run into this issue: https://github.com/raspberrypi/picoprobe/issues/3. I'll close out this issue. Thanks for the help!

[lurch]

@kilograham @aallan Is it worth us offering a precompiled binary of picotool for Windows users? Or is it still undergoing too much development for that to be practical yet?

[aallan]

@kilograham @aallan Is it worth us offering a precompiled binary of picotool for Windows users? Or is it still undergoing too much development for that to be practical yet?

This was (one of) the original plan(s). We were going to host binaries for picotool on the Landing Page, and Graham did ship me a statically linked picotool binary for Windows at some point. But the binaries aged out so quickly we didn't do it (for that and other reasons).

[ShawnHymel]

@aallan Could you set up something like Travis CI to auto-build various binaries whenever you check in some new code to the repo? I'm only vaguely familiar with continuous integration tools, so I don't know if it will ultimately work.

[lurch]

@ShawnHymel We do have an internal CI system, and that's how e.g. https://raspberrypi.github.io/pico-sdk-doxygen/ gets auto-updated. But I believe there are "issues" with updating the links on the Pico Landing Page.

[ShawnHymel]

@lurch Makes sense. Have you tried using it to build executables in addition to the docs?

[aallan]

@lurch Makes sense. Have you tried using it to build executables in addition to the docs?

Our internal CI is all Linux-based. We do build pico-examples UF2s automatically — although we don't automatically stage them publicly. But we don't have the capability to automatically do Windows or macOS builds for things like picotool.

That said if we were going to do binary distributions we'd want to do so via package management tools rather than distributing binaries via the website. There's a clear route to do this on Raspberry Pi, the route to do so is much less evident on Windows or macOS.

[lurch]

Presumably we'd want to also digitally-sign any binary .exe files we shipped?

[aallan]

Presumably we'd want to also digitally-sign any binary .exe files we shipped?

Right, which is a big part of the problem. Especially on Mac.

[lurch]

P.S. I've no idea how widely-used it is, but when I was working on Etcher a 3rd-party user bundled it up as a https://chocolatey.org/ package for us.

[ShawnHymel]

Digitally signing stuff is a pain, so that makes sense. I know you can cross-compile stuff on Linux for Windows, but I don't think that solves the problem of signing binaries.

I've used chocolatey a few times. It works pretty well, but I wouldn't say it's widely used. If you're going to shave people build executables for Windows (rather than provide a pre-built binary or installer), I think something like chocolatey is a better route than manually installing all the tools to build picotool and openocd.

[lurch]

If you're going to shave people

I don't think that's something we're planning to do... :rofl:

[aallan]

If you're going to shave people

I don't think that's something we're planning to do... 🤣

Let me just check the project plan…

[ShawnHymel]

Wait...are you saying that's not on the roadmap? That's disappointing...I had my razor ready to go 😛

[JeffersonDing]

Hi, I am having this same issue even after installing the libusb-win32 driver to RP2 Boot (Interface 1) using Zadig. Any ideas on whats the issue here? I used mingw32-make to build the executable and it seems to work just fine, but just cannot connect to the pico board.

[lurch]

@JeffersonDing It might be best to open a new issue, rather than comment on an already-closed issue?

[neilenns]

I realize this is an ancient issue but I hit the same problem today. The fix is what's described in the picoprobe issue Shawn mentioned: download https://github.com/libusb/libusb/releases/tag/v1.0.23 instead of 1.0.24 of libusb and then it'll work fine.