Difference between revisions of "Openocd-setup"

From Wiki at Neela Nurseries
Jump to: navigation, search
m (^ Openocd and Multiple Programmers: adding quick note and example of `udevadm info` output.)
m (^ How to configure openocd-0.11.0 sources for build)
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
This local page for notes on `openocd` configuration and use in remote debugging tasks.
 +
 +
== [[#top|^]] openocd Site Documentation ==
 +
 +
*  https://openocd.org/doc/html/index.html#SEC_Contents
 +
*  https://openocd.org/doc/html/Config-File-Guidelines.html#JTAG-Clock-Rate
 +
*  https://openocd.org/doc/html/Reset-Configuration.html#Types-of-Reset
 +
 +
<!-- comment -->
 +
 +
== [[#top|^]] First Page Entry 2021 Q1 ==
 +
 
On the Linux side, openocd set up on Debian type distros follows more or less the 2021 Q1 'getting started' instructions for the toolchain needed by Oresat firmware developers.  There were some small differences getting full working cross-compiling and debugging toolchain installed on an Ubuntu 20.04 LTS system, to be documented here soon.  One of the more difficult pieces was to obtain a version of arm-none-eabi-gcc which did not produce warnings about a known bug with ticket in the 86000 range.
 
On the Linux side, openocd set up on Debian type distros follows more or less the 2021 Q1 'getting started' instructions for the toolchain needed by Oresat firmware developers.  There were some small differences getting full working cross-compiling and debugging toolchain installed on an Ubuntu 20.04 LTS system, to be documented here soon.  One of the more difficult pieces was to obtain a version of arm-none-eabi-gcc which did not produce warnings about a known bug with ticket in the 86000 range.
  
Line 22: Line 34:
  
  
== openocd use ==
+
== [[#top|^]] openocd Use ==
  
 
*  http://openocd.org/doc/html/Debug-Adapter-Configuration.html
 
*  http://openocd.org/doc/html/Debug-Adapter-Configuration.html
Line 65: Line 77:
 
Looks like a very good, short tutorial and article on how to specify to openocd the serial number of a specific STLINK programmer, when two or more are attached to a given server:
 
Looks like a very good, short tutorial and article on how to specify to openocd the serial number of a specific STLINK programmer, when two or more are attached to a given server:
 
*  https://www.bergzand.net/programming-with-multiple-st-link-programmers.html
 
*  https://www.bergzand.net/programming-with-multiple-st-link-programmers.html
 
+
<pre>
 
guest@localhost:/dev/serial/by-id$ ls -l
 
guest@localhost:/dev/serial/by-id$ ls -l
 
total 0
 
total 0
Line 71: Line 83:
 
lrwxrwxrwx 1 root root 13 Jul 21 00:50 usb-STMicroelectronics_STM32_STLink_066FFF535455886687124209-if02 -> ../../ttyACM1
 
lrwxrwxrwx 1 root root 13 Jul 21 00:50 usb-STMicroelectronics_STM32_STLink_066FFF535455886687124209-if02 -> ../../ttyACM1
 
guest@localhost:/dev/serial/by-id$  
 
guest@localhost:/dev/serial/by-id$  
 +
</pre>
 +
 +
<!-- comentario -->
 +
 +
== [[#top|^]] stm32wlx.cfg ==
 +
 +
*  https://review.openocd.org/gitweb?p=openocd.git;hb=refs%2Fchanges%2F50%2F6050%2F16;f=tcl%2Ftarget%2Fstm32wlx.cfg
 +
 +
*  https://github.com/zephyrproject-rtos/zephyr/issues/22562 . . . `west sign` pull request
 +
 +
<!-- comentario -->
 +
 +
== [[#top|^]] How to configure openocd-0.11.0 sources for build ==
 +
 +
2022-08-24 - needed to disable treating build time warnings as errors, and add a few libraries via `aptitude`, but following configuration call useful
 +
 +
./configure --disable-werror --enable-ftdi --enable-stlink --enable-verbose --enable-verbose-usb-io --enable-verbose-usb-comms --enable-malloc-logging --enable-cmsis-dap-v2 --enable-usbprog --enable-cmsis-dap --enable-openjtag --enable-jlink --enable-imx_gpio
 +
 +
And issued this command, a modified version of the echoed command from calling `west flash`.  Got furthest when running this in the discouraged way preceding it with `sudo`:
 +
 +
/usr/bin/openocd -s /usr/local/share/openocd/scripts/interface -s /usr/local/share/openocd/scripts/target -f stlink.cfg -f stm32wlx.cfg '-c init' '-c targets' -c 'reset halt' -c 'flash write_image erase /home/ted/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/ted/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown
 +
 +
Ok, above command works.  Must also note that in Zephyr RTOS sample app directory ~/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world Ted added symlinks:
 +
 +
<pre>
 +
~/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world$ ls -l
 +
total 24
 +
drwxrwxr-x 7 ted ted 4096 Aug 24 17:40 build
 +
-rw-rw-r-- 1 ted ted  194 Jul 22 15:23 CMakeLists.txt
 +
lrwxrwxrwx 1 ted ted  43 Aug 24 22:07 interface -> /usr/local/share/openocd/scripts/interface/
 +
-rw-rw-r-- 1 ted ted  15 Jul 22 15:23 prj.conf
 +
-rw-rw-r-- 1 ted ted  610 Jul 22 15:23 README.rst
 +
-rw-rw-r-- 1 ted ted  340 Jul 22 15:23 sample.yaml
 +
drwxrwxr-x 2 ted ted 4096 Jul 22 15:23 src
 +
lrwxrwxrwx 1 ted ted  40 Aug 24 22:06 target -> /usr/local/share/openocd/scripts/target/
 +
</pre>
  
<!-- comment -->
+
Made this choice because Zephyr openocd config file contained relative paths 'interface/stlink.cfg' and 'target/stm32wlx.cfg', and yet these two config files are not found in Zephyr 3.1.0.  The symlinks create pointers to these needed configurations which at the moment live outside of local Zephyr RTOS source tree.  Not sure what we're doing wrong here, or installed wrong, to keep `west flash` from correctly flashing our target nucleo board which has board support in this Zephyr RTOS release.
 +
 
 +
<!-- comentario -->
 +
 
 +
== [[#top|^]] References ==
 +
 
 +
<pre>
 +
1063  vi ./boards/arm/nucleo_wl55jc/doc/nucleo_wl55jc.rst
 +
1064  vi ./boards/arm/lora_e5_dev_board/doc/lora_e5_dev_board.rst
 +
</pre>
 +
 
 +
<!-- comentario -->

Latest revision as of 05:52, 25 August 2022

This local page for notes on `openocd` configuration and use in remote debugging tasks.

^ openocd Site Documentation


^ First Page Entry 2021 Q1

On the Linux side, openocd set up on Debian type distros follows more or less the 2021 Q1 'getting started' instructions for the toolchain needed by Oresat firmware developers. There were some small differences getting full working cross-compiling and debugging toolchain installed on an Ubuntu 20.04 LTS system, to be documented here soon. One of the more difficult pieces was to obtain a version of arm-none-eabi-gcc which did not produce warnings about a known bug with ticket in the 86000 range.

Alternately on Windows 10 hosts, a similar toolchain can be installed via the following steps, and not strictly in the order of these steps:

  • install 'Git for Windows', provides 'gitbash'
  • install arm-none-eabi-gcc toolchain
  ( https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads )

Key download sites include:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/download
https://chocolatey.org/
https://community.chocolatey.org/packages/make
https://gnutoolchains.com/arm-eabi/openocd/

This short notes page a work in progress and more to come.


^ openocd Use

Successful programming of Oresat ACS card:

ted@localhost ~/projects/psas/oresat-firmware/src/f0/app_imu $ sudo make write

[sudo] password for ted: 
openocd -s ../../../boards/ORESAT_ACS_V4 -f oocd.cfg -c "hla_serial ; program ./build/app_imu.hex verify reset exit"
Open On-Chip Debugger 0.11.0-rc2+dev-00001-g5c17ce5-dirty (2021-01-25-00:53)
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
Error: expected exactly one argument to hl_serial <serial-number>
Info : clock speed 1000 kHz
Info : STLINK V3J3M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.258964
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32f0x.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0x08000190 msp: 0x20000200
** Programming Started **
Info : device id = 0x10006442
Info : flash size = 256kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

ted@localhost ~/projects/psas/oresat-firmware/src/f0/app_imu $


^ Openocd and Multiple Programmers

Looks like a very good, short tutorial and article on how to specify to openocd the serial number of a specific STLINK programmer, when two or more are attached to a given server:

guest@localhost:/dev/serial/by-id$ ls -l
total 0
lrwxrwxrwx 1 root root 13 Jul 21 00:43 usb-STMicroelectronics_STM32_STLink_066CFF343334434257144338-if02 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jul 21 00:50 usb-STMicroelectronics_STM32_STLink_066FFF535455886687124209-if02 -> ../../ttyACM1
guest@localhost:/dev/serial/by-id$ 


^ stm32wlx.cfg


^ How to configure openocd-0.11.0 sources for build

2022-08-24 - needed to disable treating build time warnings as errors, and add a few libraries via `aptitude`, but following configuration call useful

./configure --disable-werror --enable-ftdi --enable-stlink --enable-verbose --enable-verbose-usb-io --enable-verbose-usb-comms --enable-malloc-logging --enable-cmsis-dap-v2 --enable-usbprog --enable-cmsis-dap --enable-openjtag --enable-jlink --enable-imx_gpio

And issued this command, a modified version of the echoed command from calling `west flash`. Got furthest when running this in the discouraged way preceding it with `sudo`:

/usr/bin/openocd -s /usr/local/share/openocd/scripts/interface -s /usr/local/share/openocd/scripts/target -f stlink.cfg -f stm32wlx.cfg '-c init' '-c targets' -c 'reset halt' -c 'flash write_image erase /home/ted/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/ted/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown

Ok, above command works. Must also note that in Zephyr RTOS sample app directory ~/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world Ted added symlinks:

~/projects-sandbox/workspace-zephyr-sdk/zephyr/samples/hello_world$ ls -l
total 24
drwxrwxr-x 7 ted ted 4096 Aug 24 17:40 build
-rw-rw-r-- 1 ted ted  194 Jul 22 15:23 CMakeLists.txt
lrwxrwxrwx 1 ted ted   43 Aug 24 22:07 interface -> /usr/local/share/openocd/scripts/interface/
-rw-rw-r-- 1 ted ted   15 Jul 22 15:23 prj.conf
-rw-rw-r-- 1 ted ted  610 Jul 22 15:23 README.rst
-rw-rw-r-- 1 ted ted  340 Jul 22 15:23 sample.yaml
drwxrwxr-x 2 ted ted 4096 Jul 22 15:23 src
lrwxrwxrwx 1 ted ted   40 Aug 24 22:06 target -> /usr/local/share/openocd/scripts/target/

Made this choice because Zephyr openocd config file contained relative paths 'interface/stlink.cfg' and 'target/stm32wlx.cfg', and yet these two config files are not found in Zephyr 3.1.0. The symlinks create pointers to these needed configurations which at the moment live outside of local Zephyr RTOS source tree. Not sure what we're doing wrong here, or installed wrong, to keep `west flash` from correctly flashing our target nucleo board which has board support in this Zephyr RTOS release.


^ References

1063  vi ./boards/arm/nucleo_wl55jc/doc/nucleo_wl55jc.rst
1064  vi ./boards/arm/lora_e5_dev_board/doc/lora_e5_dev_board.rst