Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


After update debug does not work, failed to execute MI command

Checked for updates and the SW4STM32 found three having to do with the ARM plugins. After the update the debugger will not run anymore and fails everything that used to run with:
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333

Error message from debugger back end:
localhost:3333: Connection timed out.
localhost:3333: Connection timed out.

The console shows:
This GDB was configured as ” host=i686-linux-gnu target=arm-none-eabi”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type “help”.
Type “apropos word” to search for commands related to “word”.

I went into the Properties>Run/Debug Settings under the Debugger tab and found the OpenOCD Command: to be “${openstm32_openocd_path}/openocd”. I then went into Build Variables and showed the system variables and find the openstm32_openocd_path to be an which is set to /home/greg/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.openocd.linux64_1.9.0.201605241152/tools/openocd/bin which is correct. I pointed to the previous openocd tools 1.8.0..... with no success.

Is it safe to say this IDE tool is too fagile for real application beyond hobby use? I find most of my time is spent fighting the tool and second guessing a very unstable system.


I had the same problem. After going back to the previous version 1.8.0 (using the Eclipse Installation History) the problem was solved for the moment.

Hello,

Since yesterday after an upgrade to version 1.9, I have the same problem. After going back to version 1.8, the problem was solved too.
My real problem is that I must deploy the compilation environnement on new computer and I have no history. How can I do ?

Thanks.

Can you copy the error message from the OpenOCD process console (On Debug perpective, expend the debug configuration then click on the openocd process to display the openocd console.

Can you also tell me on which board / mcu are you working to reproduce the problem ?
Regards,
Kevin

Hello Kevin,

here is what the degug console shows when the error occurs:

/home/andreas/bin/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.openocd.linux64_1.9.0.201605241152/tools/openocd/bin/openocd: error while loading shared libraries: libhidapi-hidraw.so.0: cannot open shared object file: No such file or directory

I attached a screenshot of the two lib directories (1.8.0 left, 1.9.0 right). The library, openocd wants to load exists.

I use a custom board with an STM32F407VET6 connection via SWD using a STLinkV2.

Regards

Andreas

Is there meanwhile a solution for that?
I have the same issue here.
I’m in the phase of my project I have to write the firmware,
but I can’t. Schnief.

Hello, I am new in ARM microcontrollers, and I have the same problem.

I develop in linux and solve the problem installing libhidapi-hidraw0 library from package manager.

I hope that help you.

Sorry for my english.


The best solution I have found is to not use workbench. I loaded the latest Eclipse (Mars.2) and added the plugins for GNU arm, installed the latest openOCD, installed the latest texane STLink, and installed the GNU Utilities and copied make.exe from there over to the ARM tool set directory. After that I am able to start a new project based on the STM32fx I am using (such as STM32F7) and compile, then run the debugger.

Also something else helpful to know. In the debugger settings under the “Debugger” tab and in the “Config options” text box where you enter “-f C:\path to scripts\scripts\board\your board .cfg file” you also need to continue the argument line with a space and then “-s C:\path to scripts\scripts”. Make sure you keep the .cfg files tree starting with “scripts” intact such that the tree looks like:
scripts\boards
scripts\target
scripts\interface

that way when openOCD runs the first script as directed by the -f switch, the other .cfg files called for target and interface will be found. -s switch tells openOCD what the working directory (or base directory) is for openOCD scripts.