openocd
The Nucleo-L476RG board includes an embedded ST-Link/V2-1 debugger and programmer. This allows you to program and debug the STM32 microcontroller on the board using. The ST-Link interface provides a bridge between your development environment and the microcontroller on the Nucleo board.
OpenOCD stands for “Open On-Chip Debugger”.
install OpenOCD
You can build OpenOCD from source. Clone the Git repository and follow the build instructions: First, if necessary, you need to install ‘git’ and ‘libtool’.
sudo apt-get install git
sudo apt-get install libtool
sudo apt-get install libusb-1.0-0-dev (libusb-1.x is required for the ST-Link Programmer)
git clone https://github.com/ntfreak/openocd.git
or download zip and unzip the file
You can use also https://sourceforge.net/p/openocd. At this time of writing, the latest version is 0.12.0.
cd openocd
./bootstrap
./configure
make
sudo make install
./bootstrap
./bootstrap is a script that helps set up the necessary build configuration for a software project that uses the Autotools build system. It prepares the project for building on a specific system by generating the appropriate scripts and templates.
./configure
./configure –enable-stlink –enable-maintainer-mode
The primary purpose of ./configure is to configure the build environment for a specific system. It checks your system for various dependencies, librariesand capabilities and generates a Makefile based on the results.
This Makefile is then used by the make command to compile the source code and build the executable binary.
Without the –enable-stlink, you only get Bus Pirate.
enable-maintainer-mode When OpenOCD is built with maintainer mode enabled, it includes additional features and tools that can be helpful for developers who are actively working on the OpenOCD codebase. This can include extra debugging information, additional checks, and features that may not be needed in a standard user deployment, but are valuable during development and debugging.
make
The make command is a build automation tool used to compile and build projects based on a set of instructions specified in a makefile. The makefile contains rules and dependencies that describe how the source code of a program should be compiled and linked to produce an executable or other target files.
sudo make install
The ‘sudo make install’ command is often used to install the compiled software on your system after the build process is complete. This step is part of the standard build process and is especially common when building software from source code. The sudo command is used to execute the make install command with elevated privileges, allowing it to write to system directories.
Don’t forget that libusb-1.x is required for the ST-Link Programmer.
You should get:
OpenOCD configuration summary
MPSSE mode of FTDI based devices yes (auto)
ST-Link Programmer yes
TI ICDI JTAG Programmer yes (auto)
Keil ULINK JTAG Programmer yes (auto)
ANGIE Adapter yes (auto)
Altera USB-Blaster II Compatible yes (auto)
Bitbang mode of FT232R based devices yes (auto)
Versaloon-Link JTAG Programmer yes (auto)
TI XDS110 Debug Probe yes (auto)
CMSIS-DAP v2 Compliant Debugger yes (auto)
OSBDM (JTAG only) Programmer yes (auto)
eStick/opendous JTAG Programmer yes (auto)
Olimex ARM-JTAG-EW Programmer yes (auto)
Raisonance RLink JTAG Programmer yes (auto)
USBProg JTAG Programmer yes (auto)
Espressif JTAG Programmer yes (auto)
CMSIS-DAP Compliant Debugger no
Nu-Link Programmer no
Cypress KitProg Programmer no
Altera USB-Blaster Compatible no
ASIX Presto Adapter no
OpenJTAG Adapter no
Linux GPIO bitbang through libgpiod no
SEGGER J-Link Programmer no
Bus Pirate yes (auto)
Use Capstone disassembly framework no
Configuration files
You need the two following configuration files
interface/stlink.cfg
The OpenOCD installation already includes a suitable “interface/stlink.cfg” file, in the <b>openocd/tcl/interface</b>directory. The stlink.cfg is used since the stlink-v1, stlink-v2 and stlink-v2-1.cfg” files are deprecated.
The “interface/stlink.cfg” file is a configuration file used by OpenOCD that defines the communication interface and settings for a specific hardware debugger or programmer. In the context of a Nucleo-L476RG board, which uses an ST-Link debugger, this file is crucial for configuring the communication between OpenOCD and the ST-Link hardware.
Here’s an example of the contents of a “interface/stlink.cfg” file for a Nucleo-L476RG:
# interface/stlink-v2.cfg # Configuration for ST-Link V2 interface
interface stlink stlink_device_desc “ST-LINK/V2” stlink_transport select hla_swd
Let’s break down the key components:
interface stlink: This line specifies the interface to be used, in this case, the ST-Link debugger.
stlink_device_desc “ST-LINK/V2”: Describes the type of ST-Link device being used. This is just a description and doesn’t impact functionality.
stlink_transport select hla_swd: this line selects the Serial Wire Debug (SWD) transport for communication. SWD is a 2-pin debugging and programming protocol used by many ARM Cortex-M microcontrollers, including the one on the Nucleo-L476RG.
target/stm32f1x.cfg
Install python
./configure –enable-optimizations –enable-shared
The script will perform several checks to ensure that all necessary dependencies are present on your system. Running ./configure with –enable-optimizations will optimize the Python binary by running multiple tests. This can make the build process slower but will result in a faster and more efficient Python installation.
make -j 4
To significantly increase the compiling speed, you can use the -j <number of CPUs> option, which specifies the number of CPUs you want to utilize.
make -j 6
Install Python Binaries on Ubuntu
After finishing the building process, install the Python binaries by running the following command: sudo make altinstall. Using the make altinstall command is recommended to avoid overwriting the default Python 3 binary system.
sudo make altinstall
Finally, configure the dynamic linker run-time bindings by running the ldconfig command after installation:
sudo ldconfig
Example only:
sudo ldconfig /opt/Python3.8.16
lsof -nP -i4TCP:6666 | grep LISTEN openocd 116088 fhc 3u IPv4 2199698 0t0 TCP 127.0.0.1:6666 (LISTEN) [1]- Killed arm-none-eabi-gdb fhc.elf [2]+ Killed arm-none-eabi-gdb fhc.elf
need to kill openocd !!!
$ lsusb Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 046a:b092 Cherry GmbH USB Optical Mouse * Bus 001 Device 004: ID 0483:374b STMicroelectronics ST-LINK/V2.4* Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Note the bus number (001) and the Device (004)
You should then do: ls -l /dev/bus/usb/001/004
Create a new file ‘99-nucleo.rules’ in /etc/udev/rules.d/ The rules typically include information about the vendor and product IDs.
content: SUBSYSTEM==”usb”, ATT99-nucleo.rulesR{idVendor}==”<YourVendorID>”, ATTR{idProduct}==”<YourProductID>”, MODE=”0666”
99-openocd.rules file:
# STLink v2-1 ATTRS{idVendor}==”0483”, ATTRS{idProduct}==”374b”, GROUP==”uucp” ———————–
stlink.rules file:
# STLink v2-1 KERNEL==”tty[A-Z]*[0-9]”, MODE=”0666” SUBSYSTEM==”usb”, ATTRS{idVendor}==”0483”, ATTRS{idProduct}==”374b”,MODE=”0666”,GROUP=”uucp” ———————–
$whereis udev udev: /usr/lib/udev /etc/udev /usr/share/man/man7/udev.7.gz </pre>
Replace <YourVendorID> and <YourProductID> with the actual Vendor and Product IDs of your Nucleo board.
After creating or modifying the udev rules file, you may need to reload the udev rules or restart your system for the changes to take effect.
You can reload udev rules using the following command: <pre>sudo udevadm control –reload-rules</pre>
Then, reconnect your Nucleo board to see if the rules are applied correctly.
The udev rules are typically used to set permissions and create device symlinks when a particular device is connected to a Linux system.
Open On-Chip Debugger 0.12.0+dev-01507-g9659a9b5e (2024-01-31-00:47) Licensed under GNU GPL v2 For bug reports, read
Error: The specified debug interface was not found (hla) The following debug adapters are available: 1: buspirate
Run OpenOCD
Let’s check the version number:
$ openocd -v Open On-Chip Debugger 0.12.0+dev-01507-g9659a9b5e (2024-01-31-00:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html
Then, we use the “arm-none-eabi-gdb” command.
arm-none-eabi-gdb
openocd -f interface/stlink.cfg -f target/stm32l4x.cfg
Open On-Chip Debugger 0.12.0+dev-01507-g9659a9b5e (2024-02-01-14:42) Licensed under GNU GPL v2 For bug reports, read
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select <transport>’.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 500 kHz Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B Info : Target voltage: 3.269862 Info : [stm32l4x.cpu] Cortex-M4 r0p1 processor detected Info : [stm32l4x.cpu] target has 6 breakpoints, 4 watchpoints Info : [stm32l4x.cpu] Examination succeed Info : starting gdb server for stm32l4x.cpu on 3333 Info : Listening on port 3333 for gdb connections
openocd -f /home/fhc/openocd/tcl/board/st_nucleo_l4.cfg
Open On-Chip Debugger 0.12.0+dev-01507-g9659a9b5e (2024-02-01-14:42) Licensed under GNU GPL v2 For bug reports, read
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
The message is an informational message generated by OpenOCD. It indicates that the chosen transport protocol, which is responsible for low-level communication with the target device, has taken control.
This message often appears when using a specific transport protocol, such as the DAP (Debug Access Port) for ARM-based microcontrollers. The DAP is commonly used in SWD (Serial Wire Debug) mode.
Here are a few points to understand:
Transport Protocols: OpenOCD supports various transport protocols, including JTAG (Joint Test Action Group) and SWD. The transport protocol is determined by the debug adapter and the capabilities of the target device.
Differences in Behavior: The message is informing you that, due to the selected transport, the behavior of low-level target control might differ compared to traditional JTAG/SWD. This difference could affect the debugging experience or the results obtained.
- Common Scenarios:
If you are working with ARM-based microcontrollers, using SWD is quite common, and this message might be expected. If you are using a specific debugging/programming probe or board (like an ST-Link), it may utilize a specific transport protocol.
Potential Impact: While the message is informational, it’s essential to be aware that the behavior might differ, and you should consider this when interpreting results or debugging your target device.
If your OpenOCD setup is working as expected and you are not facing any issues, you can typically proceed with your debugging and programming tasks without significant concern about this message. However, if you encounter any unexpected behavior, it’s always a good idea to review your OpenOCD configuration, check compatibility with your debug adapter, and consult the documentation for your target device.
sudo netstat -tulpn|grep openocd tcp 0 0 127.0.0.1:6666 0.0.0.0:* LISTEN 31515/openocd tcp 0 0 127.0.0.1:4444 0.0.0.0:* LISTEN 31515/openocd tcp 0 0 127.0.0.1:3333 0.0.0.0:* LISTEN 31515/openocd </pre> </p> <p> 4444 telnet</br> 6666 gdb