STM32F401 Debug GDB error

[orestst]

We are getting the following error when debugging a STM32F401 board:

Unable to start debugging. unexpected GDB output from command "-target-select remote:3333". :3333: The system tried to join a drive to a directory on a joined drive.

What should be done to correct this isue?

[lt72]

[sorry for the late answer, I missed the notification]

most likely what is going on is
a) you did not install the USB driver from ST that creates a virtual serial port
(see https://developer.mbed.org/teams/st/wiki/ST-Link-Driver)
b) if you did install the driver, then the debugger script is looking for the wrong drive

check if you have the driver installed by trying and connect ot the board with the ST micro tools from the link above. If you do, check your debugger script or visual studio debugger settings for what values are being passed by Vidual Studio to GDB. you will find that in the project settings for your solution.

[lt72]

BTW, we may have discussed this on email and you may have solved the issue already, in which case please close it.

[orestst]

Hello Lorenzo,

The properties page for the native project Llilum open ocd Args is:

-f C:\Program Files\Microsoft\Llilum\tools\openocd\scripts\interface\stlink-v2-1.cfg -f C:\Program Files\Microsoft\Llilum\tools\openocd\scripts\board\st_nucleo_f4.cfg

I don’t see where to set the drive that I assume the Discovery board shows up as.

Thank you,

Orest

From: Lorenzo Tessiore [mailto:notifications@github.com]
Sent: Tuesday, July 12, 2016 11:45 AM
To: NETMF/llilum llilum@noreply.github.com
Cc: orestst orestst@comcast.net; Author author@noreply.github.com
Subject: Re: [NETMF/llilum] STM32F401 Debug GDB error (#217)

[sorry for the late answer, I missed the notification]

most likely what is going on is
a) you did not install the USB driver from ST that creates a virtual serial port
(see https://developer.mbed.org/teams/st/wiki/ST-Link-Driver)
b) if you did install the driver, then the debugger script is looking for the wrong drive

check if you have the driver installed by trying and connect ot the board with the ST micro tools from the link above. If you do, check your debugger script or visual studio debugger settings for what values are being passed by Vidual Studio to GDB. you will find that in the project settings for your solution.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #217 (comment) , or mute the thread https://github.com/notifications/unsubscribe/AMjl4X0Y9iCZKvD3TpqUyxcBHeF-0jEdks5qU7aWgaJpZM4I2wG4 . https://github.com/notifications/beacon/AMjl4fj78F0CPntyp2aFt5sEEaZa0OY9ks5qU7aWgaJpZM4I2wG4.gif

[kail]

In the Visual Studio output window, you should be able to see what command is actually being called when it gives you that error.

Also, you can right click on the Native project, go to Properties, and look at the Llilum tab, debug section, and make sure you are using the correct debugging file for OpenOCD.

What's probably happening is you either have the wrong file selected in the settings, the file did not get copied over correctly with the SDK, or the file is being passed an incorrect parameter. Have a look at \Zelig\LLVM2IR_results\mbed\simple\debugSTM32F401 (pretty crappy location for it to be in, sorry)

IIRC, tmp_debug.bat is what calls to launch OpenOCD. If you delete tmp_debug.bat (in your project root directory), it should get regenerated. Again, verify that you are using OpenOCD in the debug settings, and that all paths in the settings are correct.

[orestst]

Hello Mikhail,

I checked the paths, the drive (even tried making the drive that the discovery board shows up as shared), files and everything seems correct.

I don’t know where to check for incorrect parameters, which I suspect might be the issue.

What should we try next?

Could we schedule a screen share session?

Thank you,

Orest

From: Mikhail Skobov [mailto:notifications@github.com]
Sent: Wednesday, July 13, 2016 11:38 AM
To: NETMF/llilum llilum@noreply.github.com
Cc: orestst orestst@comcast.net; Author author@noreply.github.com
Subject: Re: [NETMF/llilum] STM32F401 Debug GDB error (#217)

In the Visual Studio output window, you should be able to see what command is actually being called when it gives you that error.

Also, you can right click on the Native project, go to Properties, and look at the Llilum tab, debug section, and make sure you are using the correct debugging file for OpenOCD.

What's probably happening is you either have the wrong file selected in the settings, the file did not get copied over correctly with the SDK, or the file is being passed an incorrect parameter. Have a look at \Zelig\LLVM2IR_results\mbed\simple\debugSTM32F401 (pretty crappy location for it to be in, sorry)

IIRC, tmp_debug.bat is what calls to launch OpenOCD. If you delete tmp_debug.bat (in your project root directory), it should get regenerated. Again, verify that you are using OpenOCD in the debug settings, and that all paths in the settings are correct.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #217 (comment) , or mute the thread https://github.com/notifications/unsubscribe/AMjl4TtMVNl2atyU9oB5O7yPSXis-vNXks5qVQZSgaJpZM4I2wG4 . https://github.com/notifications/beacon/AMjl4YOWHPfoZTVqo8445iaW9m4An4asks5qVQZSgaJpZM4I2wG4.gif

[kail]

I can try helping you out by looking at your configurations. Could you post a screenshot of:

1. Llilum properties
2. Debug properties
3. Verbose output when you try to deploy/debug

If you want to try and tackle the problem yourself, do the following:

1. Open llilum/VisualStudio/LlilumProjectType/LlilumApplication.sln (call this VS1)
2. Debug the LlilumProjectType project
3. That should launch a new Visual Studio instance (call this VS2)
4. Open your project in VS2
5. Open llilum/VisualStudio/LlilumProjectType/LlilumApplication/LlilumApplication.ProjectType/LlilumDebuggerLaunchProvider.cs in VS1
6. Put a breakpoint at the top of QueryDebugTargetsAsync.cs in VS1
7. Try to deploy/debug your project in VS2
8. Try and figure out your issue from debugging that method in VS1

If nothing works with VS, you can manually copy your .bin and .elf file to llilum\Zelig\LLVM2IR_results\mbed\simple\<board name> and then debug using GDB with the appropriate debug script in the simple folder.

[orestst]

Hello Mikhail,

Thank you for your assistance.

I am not sure how to specify verbose output (I did attempt a -v option but did not get any change in output).

Is the following what you needed to see?

Thank you,

Orest

Llilum properties:

The one thing that might be incorrect is Board Support Package

1> startup_stm32f401xe.S

1> pch.h

1> pch.h

1> Source.cpp

1> mbed_adc.cpp

1> mbed_clock.cpp

1> mbed_core.cpp

1> mbed_debug.cpp

1> mbed_ethernet.cpp

1> mbed_gpio.cpp

1> mbed_i2c.cpp

1> mbed_mem.cpp

1> mbed_memory.cpp

1> mbed_nvic.cpp

1> mbed_overrides.cpp

1> mbed_pwm.cpp

1> mbed_serial.cpp

1> mbed_socket.cpp

1> mbed_spi.cpp

1> mbed_system_timer.cpp

1> mbed_systick.cpp

1> mbed_threading.cpp

1> mbed_unwind.cpp

1> Native.vcxproj -> C:\CPS192\LlilumApplication2\ARM\Debug\LlilumApplication2.elf

1> text data bss dec hex filename

1> 170180 2988 1152 174320 2a8f0 C:\CPS192\LlilumApplication2\ARM\Debug\LlilumApplication2.elf

2>------ Deploy started: Project: Native, Configuration: Debug ARM ------

2>STM32 ST-LINK CLI v2.4.0

2>STM32 ST-LINK Command Line Interface

2>

2>ST-LINK SN : 066CFF505256656767193514

2>ST-LINK Firmware version : V2J23M9

2>Connected via SWD.

2>SWD Frequency = 4000K.

2>Target voltage = 3.3 V.

2>Connection mode : Connect Under Reset.

2>Device ID:0x433

2>Device flash Size : 512 Kbytes

2>Device family :STM32F401xD/E

2>

2>Full chip erase...

2>Flash memory erased.

2>

2>Loading file...

2>Flash Programming:

2> File : C:\CPS192\LlilumApplication2\ARM\Debug\LlilumApplication2.hex

2> Address : 0x08000000

2>Memory programming...

2>±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±± 0%

2> 0%ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ 36%ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ 72%ÛÛÛÛÛÛÛÛÛÛÛÛÛÛ 100%

2>Memory programmed in 4s and 719ms.

2>Programming Complete.

2>

2>Hardware breakpoints cleared.

2>

2>Hard reset is performed.

2>

2>

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

From: Mikhail Skobov [mailto:notifications@github.com]
Sent: Thursday, July 14, 2016 11:42 AM
To: NETMF/llilum llilum@noreply.github.com
Cc: orestst orestst@comcast.net; Author author@noreply.github.com
Subject: Re: [NETMF/llilum] STM32F401 Debug GDB error (#217)

I can try helping you out by looking at your configurations. Could you post a screenshot of:

1. Llilum properties
2. Debug properties
3. Verbose output when you try to deploy/debug

If you want to try and tackle the problem yourself, do the following:

1. Open llilum/VisualStudio/LlilumProjectType/LlilumApplication.sln (call this VS1)
2. Debug the LlilumProjectType project
3. That should launch a new Visual Studio instance (call this VS2)
4. Open your project in VS2
5. Open llilum/VisualStudio/LlilumProjectType/LlilumApplication/LlilumApplication.ProjectType/LlilumDebuggerLaunchProvider.cs in VS1
6. Put a breakpoint at the top of QueryDebugTargetsAsync.cs in VS1
7. Try to deploy/debug your project in VS2
8. Try and figure out your issue from debugging that method in VS1

If nothing works with VS, you can manually copy your .bin and .elf file to llilum\Zelig\LLVM2IR_results\mbed\simple and then debug using GDB with the appropriate debug script in the simple folder.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #217 (comment) , or mute the thread https://github.com/notifications/unsubscribe/AMjl4fOFYJx82rV4ydggDh8AAs9tCf7eks5qVli3gaJpZM4I2wG4 . https://github.com/notifications/beacon/AMjl4SP219shjwz-OXR7LKJp1bix0k6Qks5qVli3gaJpZM4I2wG4.gif

[kail]

That is the output from build and deploy, but your issue is on debug, so I would need to see the output from that (if any exists). As long as you haven't suppressed verbose output, it should be the default, so everything that's getting printed out seems ok