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


Debug failing NUCLEO-L152RE

I’ve seen reports of similar errors but little resolution, and certainly none that have fixed my issue.

Running System Workbench on a 64 bit Win 7 machine, STlink drivers appear correctly installed, and can certainly progeam the device on the nucleo board using the ST LINK application.

However desperately trying to get debugging working through System Workbench with little success.

Consistent error of the following:

Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333

Error message from debugger back end:
localhost:3333: The system tried to join a drive to a directory on a joined drive.
localhost:3333: The system tried to join a drive to a directory on a joined drive.

Have created projects from both the CubeMX tool and amnually from Workbench and always the same result. Have also done a clean install of the IDE....

Anyone had this issue and managed to resolve it?

Thanks

Hi,

Same behavior, the problem in my case was libusb library. (I have this problem only on Win8.1, working well with Win7 and Win 10 - all x64.)

This is a generic error and not very helpful. If I remember well even if you don’t connect you board/ST-LINK probe you get exactly the same error.

Is good that you can program the device using the STM32 ST-LINK Utility. This means that jumpers on the board are correctly configured. Anyway you can check again just to be sure - check the board User Guide.
If you have some application (ST default app), check the Run/Stop from ST-LINK Utility. If I remember well should be under Target>MCU Core.

Regarding to your problem, I think first you have to get more information’s - enable debug level 3 for OpenOCD.
System Workbench use OpenOCD to connect to hardware debug probe on Nucleo board. OpenOCD send commands over USB to debug probe (in this case ST LINK v2 or v2.1).
GDB will connect to OpenOCD. When a breakpoint/command (e.g Debug) is issued on Eclipse IDE this is transferred to GDB.


BEFORE to do any debug on OpenOCD, be sure to create your project and use the correct OpenOCD script for your Nucleo board as it is describe in next documentation.
This will ensure that you have the correct configuration of GDB and OpenOCD

Creating a new project:
http://www.openstm32.org/Creating+a+new+project?structure=Documentation Question

Importing a STCubeMX generated project:
http://www.openstm32.org/Importing+a+STCubeMX+generated+project?structure=DocumentationQuestion


You will find how to enable debug on OpenOCD in this thread Unable to debug with ST-LinkV2-1:
http://www.openstm32.org/tiki-view_forum_thread.php?comments_parentId=722Question

Get the log file and very important things are:
1) VID and PID of your ST LINK (0x0483 0x3748 or 0x374B in case of v2.1 - don’t use an OpenOCD script for v2.1 if you have 2.0 - will not work
2) return of the function stlink_usb_open() (see debug file)


RESOLVED!

Thanks for the steer cipriansalageanu!

Interestingly worked correctly using the freddie chopin build of OpenOCD via command line with no issues, so just pointed system workbench to this exe and used the associated nucleo L1 script and all appears to be working.

Glad that you solve the problem,

Normally should work also with the OpenOCD that is installed with System Workbench. OpenOCD is installed on this path: \Ac6\SystemWorkbench\plugins\fr.ac6.mcu.externaltools.openocd.win32_1.3.0.201507241045\tools\

This seems to be a win32 executable. Nevertheless seems to work in x64 environments.

Unfortunately last time when I have checked I was not able to start OpenOCD that came wit SW from command line because some paths were not corrected set. If the OpenOCD starts from IDE then the correct paths are added.

If you want to further investigate then maybe you can compare Freddie Chopin OpenOCD logs obtained with -d3 option with the default SW OpenOCD logs.