Skip to main content

How to install the xPack OpenOCD binaries

The xPack OpenOCD can be installed automatically, using the xpm command (the recommended method), or manually, by downloading and unpacking one of the portable archives.

Automated install​

The easiest (and recommended) way to install OpenOCD is by using the binary xPack, available as @xpack-dev-tools/openocd from the npmjs.com registry.

xPacks 101

While the initial appearance may seem complex, utilizing xPacks is, in fact, straightforward. The design rationale is to automate frequent operations that occur during software development, in this case the installation of dependencies, and to ensure reproducibility.

xPacks are standard archives that are extracted into separate folders within the project. If the xPacks contain executables, links/forwarders to these executables are created in a .bin folder, eliminating the need to add multiple folders to the PATH.

Given that some binary xPacks, such as toolchains, can be quite large, the archives are extracted only once into a user global location to conserve space. In projects, instead of duplicating the content of these archives, symbolic links are created.

Prerequisites​

The only requirement for an automated install is a recent xpm, which is a portable Node.js command line application that complements npm with several extra features specific to C/C++ projects.

To install xpm, follow the instructions in the xpm install page.

If already installed, it is always a good idea to update it to the latest version with:

npm install --location=global xpm@latest
tip

Although not mandated by xpm, it is also a good idea to upgrade npm to the latest version, and node to a reasonably recent version (currently npm requires a node >=18.17.0).

Local installs

One of the xPack design goals is to allow each project to choose the exact versions of the tools it requires.

Similarly to npm being able to install specific versions of the JavaScript tools into each project, xpm was also designed to be able to install specific versions of the required binary tools locally into each project.

Therefore, similarly to the way npm installs the JavaScript packages into node_modules, xpm installs the binary tools into xpacks. Here there will be separate folders with the installed packages, for example xpacks/@xpack-dev-tools/openocd.

Each such folder includes the package.json file with the project metadata and a sub-folder .content with the extracted binary archive. The executables are usually in .content/bin.

tip

On some platforms, names starting with . (dot) might be hidden for normal browsing, and seeing them requires separate options (like ls -A) or, in file browsers, to enable settings like Show Hidden Files.

The xpacks/.bin folder

If multiple binary packages are installed, in order to allow the executables to be accessed, one possible solution is to add all <package>/.content/bin folders to the PATH.

To simplify things, npm employs a separate node_modules/.bin folder where it places links/forwarders pointing to the actual executable files.

Similarly, xpm adds links/forwarders into a separate xpacks/.bin folder.

With this setup, the project needs to prepend only this .bin folder to the PATH, and all the required tools are accesible and prefered to possible system tools.

Global installs and the user global xPacks store

Given that some binary tools (such as toolchains) can be very large (hundreds of megabytes or more), it is impractical to keep multiple copies of these tools, one for each project.

Instead, xpm installs the binary packages only once into a user global store (a platform-dependent folder within the home folder), thereby conserving disk space when the same tools are used across multiple projects.

In order to allow the projects to access the binary tools installed in the user global store, instead of unpacking the archives in xpacks, xpm adds symbolic links pointing to the user global xPacks store.

The outcome is functionally equivalent to installing the tools into each project, but without the wasted disk space.

tip

It is possible to force a local install into a project by passing --copy to xpm install.

if necessary, it is also possible to install packages only globally, without creating local links/forwarders (see below).

The user xPacks cache

To save download time, all archives are first stored in a cache, and all subsequent downloads are replaced with the cached content.

Therefore all published archives should be read-only and it is not allowed to replace them at a later time.

Initialise the project​

Upon initial use, ensure that a package.json file is present in the project root folder.

This can be achieved by running xpm init in the desired project folder (substitute my-project accordingly):

cd my-project
xpm init
Under the hood

The main purpose of xpm init is to create a package.json file, if not already present.

In addition to name & version, the minimal package.json must include a property named xpacks, even empty. This property is mandatory to identify the package as an xPack.

Install into the project​

The next step is to install the openocd package into the project:

xpm install @xpack-dev-tools/openocd@latest --verbose

The main result is a set of forwarders in the .bin folder:

dir xpacks\.bin
PATH setup

With all binary tools installed in xpacks/.bin, the project build configurations need only a single PATH adjustment:

export PATH=<...project-path...>/xpacks/.bin:$PATH
tip

This syntax is for the Git Bash console. When using COMMAND.EXE or Power Shell, adjust the syntax for the corresponding Windows specific shell.

Installation details

The above xpm install command will do the following:

  • identify the platform specific archive for the latest available version of OpenOCD, download it into a cache and unpack it into a versioned folder in the user global xPacks store (if not already there); check the output of the xpm install command for the actual folder used on your platform;
  • create a local symbolic link like xpacks/@xpack-dev-tools/openocd pointing to the versioned folder in the user global xPacks store
  • add links/forwarders into the local xpacks/.bin folder, referring to the binaries in xpacks/@xpack-dev-tools/openocd/.content/bin;
  • add @xpack-dev-tools/openocd to package.json as a development dependency; this associates a specific version of OpenOCD with the current project (details below).
tip

The install location can be configured using the XPACKS_STORE_FOLDER environment variable; for more details please check the xpm folders page.

Reproducibility and devDependencies

To ensure reproducibility, it is essential for each project to always use the exact desired versions of the required tools, regardless of the tools installed in the system.

To achieve this goal, xpm records all locally installed binary packages as development dependencies in the project package.json file.

The result looks like this:

  "xpack": {
    "minimumXpmRequired": "0.19.1",
    "dependencies": {},
    "devDependencies": {
      "@xpack-dev-tools/openocd": {
        "specifier": "0.12.0-4.1",
        "local": "link",
        "platforms": "all"
      }
    },
    "properties": {},
    "actions": {},
    "buildConfigurations": {}
  }

If the package.json is saved in the revision system, the above definition acts as a hard reference to the specific version of xPack OpenOCD.

After cloning the project into a different location, the command xpm install can be used to install all development dependencies.

This is particularly useful for CI/CD environments.

Install globally​

For older development environments, it is also possible to install OpenOCD only globally in the user global xPacks store, without any local links/forwarders; it is the developer's responsibility to configure the path to the tools.

No other files are installed in any system folders or other locations.

xpm install @xpack-dev-tools/openocd@latest --global --verbose
note

Installing packages locally into a project always installs the packages in the user global xPacks store; subsequent attempts to install the packages globally will fail with already installed.

PATH setup

In order to access the GNU RISC-V Embedded GCC binaries installed in the user global xPacks store, the project build configurations need a PATH adjustment:

export PATH=$HOME/AppData/Roaming/xPacks/@pack-dev-tools/openocd /0.12.0-4.1/.content/bin:$PATH
tip

When not using the Git console, adjust the syntax for the corresponding shell.

Uninstall​

The binaries do not use any form of installer; instead they are distributed as portable .tar.gz archives; therefore they do not require to run any uninstaller; simply removing the links and possibly the user global xPack store folder and the user xPack cache folder is enough.

To remove the symbolic links created by xpm in the current project, go to the project folder:

cd my-project

and ask xpm to uninstall the package:

xpm uninstall @xpack-dev-tools/openocd --verbose

To completely remove the package from the user global xPack store:

xpm uninstall --global @xpack-dev-tools/openocd --verbose
Clean-ups

For a thorough clean-up, please note that xpm uses only two folders:

  • %APPDATA%\Roaming\xPacks
  • %APPDATA%\Local\Caches\xPacks

They can be removed at any time and space reclaimed; xpm will recreate them on new installs.

However, projects linking to the user global xPack store will fail with broken paths.

Quick test​

To check if the OpenOCD installed by xpm starts properly, use something like:

C:\> %USERPROFILE%\AppData\Roaming\xPacks\@xpack-dev-tools\openocd\0.12.0-4.1\.content\bin\.exe --version
xPack x86_64 clang version 0.12.0

Manual install​

For all platforms, the xPack OpenOCD binaries are released as portable archives that can be installed in any location.

The archives can be downloaded from the GitHub Releases pages.

Download & unpack​

The Windows versions of xPack OpenOCD are packed as .zip files. Download the latest version named like:

  • xpack-openocd-0.12.0-4-win32-x64.zip
note

In case you wonder where the suffix comes from, it is exactly the Node.js process.platform and process.arch. The win32 part is confusing, but we have to live with it.

To manually install the xPack OpenOCD, unpack the archive and move it to a location of your choice.

The recommended location is the %USERPROFILE%\AppData\Roaming\xPacks\openocd folder, for example C:\Users\ilg\AppData\Roaming\xPacks\openocd\xpack-openocd-0.12.0-4.

note

According to Microsoft, AppData\Roaming is the recommended location for installing user specific packages.

info

For manual installs, the recommended install location is slightly different then the folders created by xpm install, which use the @xpack-dev-tools scope to group different tools, and .content to store the unpacked archive.

Quick test​

To check if the OpenOCD installed manually starts properly, use something like:

C:\> %USERPROFILE%\AppData\Roaming\xPacks\openocd\xpack-openocd-0.12.0-4\bin\.exe --version
xPack x86_64 clang version 0.12.0

Miscellaneous​

Folder hierarchy

After install, the package creates a folder hierarchy like the following (only the first two depth levels are shown):

C:> tree /f %USERPROFILE%\AppData\Roaming\xPacks\@xpack-dev-tools\openocd\0.12.0-4.1\.content
Folder PATH listing
Volume serial number is B02D-925C
├── README.md
├── bin
│   ├── libftdi1.dll
│   ├── libusb-1.0.dll
│   └── openocd.exe
├── distro-info
│   └── licenses
└── openocd
    ├── OpenULINK
    ├── angie
    ├── contrib
    └── scripts

8 directories, 4 files

Drivers​

As usual on Windows, mastering drivers is a challenge and OpenOCD is no exceptions, so don't be surprised to encounter many incompatible drivers for various JTAG probes.

Zadig

The OpenOCD distribution includes some libusb drivers, and recommends to run the zadig.exe tool to activate them.

For example ARM-USB-OCD from Olimex, after installing the vendor drivers, asks to install Zadig and convert the vendor drivers to WinUSB drivers.

caution

Although converting the vendor drivers to WinUSB drivers will make OpenOCD happy, please be aware that other tools using the original drivers will no longer work while Zadig is active, and to make them work you need to uninstall the Zadig driver for the device and reinstall the vendor driver (see Zadig FAQ). Our recommendation is to use Zadig only as a last resort solution, and, when possible, prefer the manufacturer drivers.

ST-LINK

One example of compatible drivers are the ST-LINK USB drivers, from ST, available as part number STSW-LINK009. Download the latest stsw-link009.zip archive, extract its content into a separate folder, and run the dpinst_amd64.exe (or dpinst_x86.exe) with administrative privileges.

As for most Windows drivers, to complete the installation, a restart usually helps.

Connect the ST-LINK or the DISCOVERY board and check in Control Panel  → System → Device Manager if the JTAG is operational.

ST-LINK Windows device

For other probes follow the manufacturer instructions.

note

All Windows tests were performed on Windows 11. If, for any reasons, you still need to use older versions, especially the venerable Windows XP, some differences may be observed in the USB subsystem; to stay on the safe side, try to always use original manufacturer drivers.

Testing​

To test if OpenOCD is able to connect to a specific board, it is generally necessary to select the interface and the processor. As a shortcut, for some well known boards, there are ready made configuration files to set both the interface and the processor. For example to test a connection via ST/LINK to the STM32F4DISCOVERY board, you can use something like this:

$ .../xPacks/@xpack-dev-tools/openocd/0.12.0-4.1/.content/bin/openocd -f board/stm32f4discovery.cfg
xPack OpenOCD x86_64 Open On-Chip Debugger 0.12.0+dev
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.881412
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
^C