git clone git://repo.or.cz/openocd.git
./configure --enable-maintainer-mode --enable-stlink
sudo make install
cd openocdReplace "32" by "64" and "bin" by "bin-x86" to create a 64-bit windows binary.
git clone git://repo.or.cz/openocd.git
export LIBUSB1_CFLAGS="-I$HOME/openocd/libusbx-1.0.12-win/include/libusbx-1.0/ -DHAVE_LIBUSB_ERROR_NAME"
export LIBUSB1_LIBS="-L$HOME/openocd/libusbx-1.0.12-win/MinGW32/static/ -lusb-1.0"
./configure --enable-maintainer-mode --host=i686-w64-mingw32 --prefix= --enable-stlink
make bindir="bin" pkgdatadir=
According to the usual procedure, this will show up in the next release of openocd (0.9.0). At some point Freddie Chopin might provide binaries for windows. Check for releases later than 22.09.2014.
Using a test setup with two ST nucleo boards, everything works fine: Find the serial number of the first embedded stlink (e.g. use lsusb -v) and create a config file for openocd like this one. Then create the config file for the second board. Now you are able to address each board individually using its config file. Note the only difference between the two files is the serial number of the embedded stlink.
Another way is to supply the serial number as an additional parameter:
openocd -f board/st_nucleo_f103rb.cfg -c "hla_serial "066EFF534951775087194310""
This way, you won't have to create new or modify the supplied configuration files. You'll have to add options to set the gdb port etc. if you want to run more than one instance of openocd.
Things start to get interesting when you use the standalone ST-Link/V2:
Imagine a test setup like this one:
This is basically a homemade dev board with two STM32F103CB chips, one of them connected to the LCD module, the other isn't, but e.g. acquires some analog values. I want to read the value at the LCD. The controllers are connected using a SPI port. So I have to implement something like this:
While creating and testing the necessary config files, I've noticed that the standalone ST-Links use serial numbers containing unreadable characters.
Look at the output of lsusb -v to see what I mean. Well, it's still possible to put such a serial number into a
openocd config file, and here is the second one.
Basically you'll have to convert the strange characters to a "\xnn" notation, where 'nn' is the hexadecimal value of the char. I did this manually here,
it depends on your console or file viewer how easy this task will be.
Note that you won't be able to use them both at the same time by starting two instances of openocd and gdb. To accomplish this, you'll have to specify different port numbers for openocd like I did in this config file with port numbers.
Having done that, I discovered that connecting to the st-link works only once. After the first usage, the st-link magically changes its serial number to "000000000001". See the lsusb -v output. Someone posted this problem at the code review page of openocd, to be honest, I didn't test this before, but I was able to reproduce the behaviour here. It's of no use to create config files with that serial number, since both st-link will have the same serial after their first usage. You can power cycle the ST-Links to restore the serial, but this is not the intended way I want to use them.
And now, just keep calm and get your update from the ST website. Update the ST-Link devices to the lastest version (V2.J21.S4), even if the updater reports this version for your ST-Link before the update. I had this once, but cannot reproduce, since the old version is gone after updating and you cannot read out the STM32 chip inside the ST-Link. You might have to use the evil (windows) to update the adapters, I didn't try wine, since a windows box was available.
Having successfully updated the ST-Link/V2 devices, my setup works as intended. The strange serial numbers are still there, but at least they are constant now and do not change any more while using the stlink.
Look here for some of my logs and config files that I created while testing the setup.
Look here: The STM32 files for my other
STM32 related pages.
Table of contents