CubeMX under linux in couple with System Workbench for Stm32
Yes,
it really happened! During update of CubeMX, I've glanced on list of
changes, and not believed to my eyes: ST released linux version. Time
to try this stuff and get opinion on it.
First of all, CubeMX under linux:
Nothing extremely special, for the first glance everything works fine. Finally, they added support of codegeneration of generic GCC environment. I've generated test project for my F3Discovery board for SystemWorkbench for stm32 IDE.
And if CubeMX have not shown any issues for this time, IDE showed a lot of them:( As always on linux... Really, I LOVE LINUX, but I hate these crude solutions in contrast of windows. (Actually, system workbench on windows also is buggy too, and this compelled me currently work in IAR which is ugliest IDE in the world. But IAR works PREDICTABLE and it is key factor).
Step 1.
Ok, what I get when I run IDE at the first time and tried to debug my board. Error...
What
was wrong? libncurses, but not just it, and 64-bit version. Solution:
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: timed out
localhost:3333: timed out
After this magic I've got first complete test debugging. And what bugs waiting for me again - I do not know:)
First of all, CubeMX under linux:
Nothing extremely special, for the first glance everything works fine. Finally, they added support of codegeneration of generic GCC environment. I've generated test project for my F3Discovery board for SystemWorkbench for stm32 IDE.
And if CubeMX have not shown any issues for this time, IDE showed a lot of them:( As always on linux... Really, I LOVE LINUX, but I hate these crude solutions in contrast of windows. (Actually, system workbench on windows also is buggy too, and this compelled me currently work in IAR which is ugliest IDE in the world. But IAR works PREDICTABLE and it is key factor).
Step 1.
Ok, what I get when I run IDE at the first time and tried to debug my board. Error...
Could not determine GDB version using command:
/home/artsin/bin/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.arm-none.linux64_1.3.0.201507241112/tools/compiler/bin/arm-none-eabi-gdb
--version
/home/artsin/bin/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.arm-none.linux64_1.3.0.201507241112/tools/compiler/bin/arm-none-eabi-gdb:
error while loading shared libraries: libncurses.so.5: cannot open
shared object file: No such file or directory
sudo apt-get install lib32ncurses5
Step 2.
Ok,
move forvard. Next iteration - next error. Now when we tried to debug
on
our
board. We got window with error like this:
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: timed out
localhost:3333: timed out
I
cannot remember full error, but it is concerned to
openocd debugger. Really,attempt to run manually it showed this:
artsin@artsin-K53SJ:~$
/home/artsin/bin/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.openocd.linux64_1.7.0.201602121841/tools/openocd/bin/openocd
-f stm32f3discovery.cfg -s
/home/artsin/bin/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.7.0.201602121829/resources/openocd/scripts/st_board
-s
/home/artsin/bin/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.7.0.201602121829/resources/openocd/scripts
-c gdb_port 3333
Open
On-Chip Debugger 0.9.0-dev-dirty (2015-11-13-11:40)
Licensed under GNU GPL
v2
For
bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first
available session transport "hla_swd". To override
use 'transport select <transport>'.
adapter speed: 1000
kHz
adapter_nsrst_delay: 100
Info : The selected transport
took over low-level target control. The results might differ compared
to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain
connect_assert_srst
srst_only separate srst_nogate srst_open_drain
connect_assert_srst
3333
Info : Unable to match requested speed 1000 kHz,
using 950 kHz
Info : Unable to match requested speed 1000 kHz,
using 950 kHz
Info : clock speed 950 kHz
Error: libusb_open() failed with
LIBUSB_ERROR_ACCESS
Error: open failed
in procedure 'init'
in
procedure 'ocd_bouncer'
Solution
I've found here:
“For
the JTAG probes implemented as USB devices (actually most of them),
the last installation step on GNU/Linux is to configure the UDEV
subsystem. OpenOCD provides an UDEV rules file defining all the
supported IDs; to install it, just copy the file to
/etc/udev/rules.d
and eventually notify the daemon:Note: If you previously installed the J-Link binaries, the USB IDs were already added to UDEV. The above OpenOCD rules file also defines the J-Link ID. Apparently UDEV does not complain; if you encounter problems, just comment out the definition in the OpenOCD file.
$ sudo cp /opt/gnuarmeclipse/openocd/0.10.0-201510281129-dev/contrib/99-openocd.rules \ /etc/udev/rules.d/ $ sudo udevadm control --reload-rules
“
But
for cp command I've used path to file
99-openocd.rules located in SystemWorkbench directory (just search it in
your installation path)
After this magic I've got first complete test debugging. And what bugs waiting for me again - I do not know:)
Hi,
ReplyDeleteThanks for the heads up about libncurses5 for 32 bit executables; this is due to the fact that several utilities we do not want to recompile (for reliability reasons, especially the compiler itself that is heavily tested by Linaro) are only available as 32-bit executables.
I thought the warning was present in the installation instructions, but discover it was missing and I just correct them.
As far as the udev rules are concerned, if you install System Workbench using th einstaller, these rules are automatically installed (after asking for your password through gksudo if installing as a normal user). If you install manually in an existing Eclipse platform the procedure to install the rules file is described (and the proper rules file is provided as a tarball).
Thanks for your posts about System Workbench,
Bernard (Ac6)
Hello, Bernard! Thank you for your attention to my little blog:) One clarification about your udev rules. stuarte83 and Antony(and me too) at OpenStm32 forum faced with problem with udev. I do not remember my error during installation, but Stuarte wrote his issue:
DeleteStarting process Loading STLink/V2 udev rules (3/3)
cp: cannot stat ‘49-stlinkv2.rules’: No such file or directory
I fix my issue by copying 99-openocd.rules, not 49-stlinkv2.rules file. Is this file present in your installation script? Unfortunately, I cannot check your installation script now, but it is possible, that reason is in availability and path to udev rules file.