[support]

Hi,

You can also check out our UART tutorial explaining how to fix a similar issue: http://visualgdb.com/tutorials/arm/stm32/uart/

[support]

Hi,

Is uploading the same file with SmarTTY also slow? It is using the same SSH engine.

[support]

Hi,

Can you try starting the Driver tool (select ‘manual mode’ in OpenOCD settings) and trying to manually install the WinUSB-LibUSB driver for the ST-Link device?

[support]

Hi,

Most likely some of your symbols refer to an incorrect path. Can you try running arm-eabi-objdump -g and see if the file tables mentioned in the output contain some suspicious names? If not, can you try commenting out parts of your project to see which source file causes it?

[support]

Hi,

What is the final size of the binary you’re debugging? If it’s several tens of megabytes, it could explain why deployment is slow. You can speed it up by adding a custom action that will strip it and deploy a stripped version (don’t forget to disable auto-deployment and don’t strip the version used by GDB to read symbols). We could also add a deployment progress window if it turns out that the deployment is the bottleneck.

[support]

Hi,
Based on the log, the clean action fails because there is no project built yet (it should be normally ignored), but the build succeeds. Does the normal build command (not rebuild) work?

[support]

Hi,

The disassembly window in Visual Studio sometimes behaves strangely is some of the requested code ranges cannot be disassembled. Can you provide a screenshot of the Disassembly window, the address you’re trying to see and the corresponding GDB log showing what gdb reports when asked to disassemble those addresses?

[support]

Hi,

Looks like 374b is mentioned in the stlink-v2-1.cfg configuration file in the OpenOCD directory. You can edit the %LOCALAPPDATA%VisualGDBEmbeddedDebugPackagescom.sysprogs.arm.openocdQuickSetupinterfaces.xml file to make VisualGDB recognize it automatically:

	

stlink-v2-1

ST-Link v2

interface/stlink-v2-1.cfg





0483

374B





true

NotSupported

com.sysprogs.libusb.mini

[support]

Hi,

Sorry for the delay. Can you send us an archive with your test application (or attach it here) so that we could experiment with it on our side to figure out the root cause of the problem?

[support]

Hi,

Thanks, the deployment was indeed skipped. We have added a default option to deploy it to the upcoming maintenance release.

[support]

Hi,

Your Windows itself may not have the limit, but the GNU make may have been compiled with an old version of the cygwin/MinGW runtime that does. That would explain why the shell started from the Make sees the variable, but the Make itself ignores it.
If this is a critical issue, you could rebuild the Make binary from sources and step through it to see why the variables are lost. Let us know if you need instructions on that.

[support]

Hi,

Sorry for the late reply. We have found and resolved the NullReferenceException issue. The fix will be available in the next maintenance release (r4). Let us know if you want an earlier build.
Regarding the ‘clean’ problem you can go to Visual Studio Project Properties (not VisualGDB Project Properties), General page and clear the “Build log file” field or relocate it outside of the ‘Debug’ directory. Then it won’t interfere with the clean command.

[support]

Hi,

This looks like it may be related to the environment block size limit. The older versions of Windows had it limited to 32K and some programs may still have it hardcoded. Try cleaning up some unused environment variables and see if that solves the problem.

[support]

Hi,

The latest release of VisualGDB stores relative paths in the MCU XML file. Simply change the path to devicesstm32f407xx.xml if you have created your project using an older version.
You can browse all VisualGDB-related settings via Tools->Options->VisualGDB.

[support]

Hi,

The include/library directory settings do not support any variables. They do support relative paths, however.
If you want to reference a VisualGDB library project, simply add it to the build dependencies of your main project and VisualGDB will figure out the path to the binary automatically.
We don’t support multiple targets per project as it would make some things overcompilcated (e.g. project references or mapping of source files to targets) and it’s not supported by normal Visual Studio projects. You can instead use one of the following workarounds:
1. Create several VisualGDB projects in different directories
2. Manually edit the makefiles to add more targets (you will then have to manually track which sources belong to which targets)
3. Create several VisualGDB projects in the same directory and override the Makefile name for them (e.g. Makefile2 instead of Makefile).

[Author]

Posts