[support]

Hi,

Sorry, the logs you attached unfortunately don’t show any timing. You can enable generation of timestamped logs via VisualGDB Project Properties -> Advanced GDB Settings -> Save all low-level interaction with GDB.

Please also try using this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.14.1892.msi

It resolves another issue related to Segger GDB stub and might solve the performance issues you are encountering as well.

[support]

Hi,

Thanks, looks like the ‘connect under reset’ indeed doesn’t work on STM32F7. We have fixed this in the upcoming update to the OpenOCD package.

As a workaround, please try changing the following line in stm32f7x.cfg:

reset_config srst_only srst_nogate

replace it with the version from F4X:

reset_config srst_nogate

Then VisualGDB will recognize it and show the “connect under reset” option.

[support]

Hi,

Sorry for the confusion. Changing the location of the main memory to SDRAM would not work as your firmware would need to use the memory for the stack before it can initialize the SDRAM controller.

If you want to make the malloc()/free() functions use SDRAM instead of the regular SRAM, please add an implementation of the _sbrk() function similar to the one described in this tutorial: https://visualgdb.com/tutorials/arm/newlib-nano/

Instead of returning the area between the _end symbol and the stack pointer, change the implementation so that it will return the memory between the start and end of SDRAM.

[support]

Hi,

It looks like your trial has expired. In order to keep on receiving technical support please purchase a license. If you have already purchased a license under a different email, please let us know and we will update our records.

Please also note that the VisualGDB support covers issues that are related to VisualGDB (e.g. functionality that is broken when using VisualGDB, but works otherwise). If the ESP8266 SDK is missing examples/documentation on certain scenarios, please ask on the ESP8266 forums instead.

• This reply was modified 8 years, 2 months ago by support.

[support]

Hi,

We actually have a detailed tutorial showing this: https://visualgdb.com/tutorials/arm/memories/

Feel free to follow it and let us know if you have any questions.

[support]

Hi,

We actually removed the direct mode as it was causing race conditions inside the J-Link DLL and sometimes showing incorrect data. It should normally not affect the normal debugging speed, only the speed of the real-time watch. Can you confirm that all debugging is now slow? Would you be able to share the gdb log with the timing labels so that we could see if we can work around this?

[support]

Hi,

We understand you didn’t change anything, however sometimes the problems are caused by unexpected combinations of small changes or incompatible settings that are hard to predict. We advise following the diagnostic steps in the previous post to resolve this.

[support]

Hi,

The executable file normally has no extension (e.g. …/LinuxProject1/VisualGDB/Debug/LinuxProject1). If you are not sure, please try running the “find <project directory>” command via SSH and post the output here and we will help you locate the right file.

[support]

Hi,

Generally in order for a USART to work, you need to ensure the following:

• The peripheral clock for this USART is enabled
• The corresponding pins are configured to work as USART
• You configure the peripheral correctly (e.g. set the baud rate) and write the correct data registers

We have a detailed tutorial showing how to use STM32 UART here: https://visualgdb.com/tutorials/arm/stm32/uart/hal/

Generally we would advise first sorting this out on a regular non-MBED project and then stepping through the mbed source code to ensure that it does the same initialization/configuration steps as your non-mbed project (hardware register window can help double-check that the necessary parts got initialized).

[support]

Hi,

Please use the Help->About VisualGDB window to enter the new key (or re-enter the same key if it was upgraded).

[support]

Hi,

Sorry, this exception is thrown by the VS itself; VisualGDB simply displays it and cancels the wizard. As this is something very rare that should normally not happen, we won’t be adding any special handling for this case. That said, if anyone else encounters this problem, please feel free to update this thread. If it turns out to be not as rare as we assume, we can easily add a check for it.

[support]

Hi,

Please try updating your VisualGDB to v5.3R3 (latest maintenance release) and also update your OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.

If you still don’t see the options, please try attaching a screenshot of your Debug Settings page so that we could see which version you are using and suggest a way to update it.

[support]

Hi,

OK, we have added an option “Don’t activate GDB Session window” under Tools->Options->VisualGDB->General->GUI in this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.13.1881.msi

The Live Variables tool window should normally appear close to the ‘Output’ window. Either way, if you keep the window open, but put it in the background (i.e. behind any other window), it should stay in the background and not re-appear.

[support]

Hi,

Thanks for the link. Looks like you are using the ‘VisualGDB’ platform for non-MSBuild projects. Unfortunately this is not supported (as VisualGDB internally uses the platform name to distinguish between MSBuild and non-MSBuild configurations). We have added a warning for this in the upcoming v5.3R4 build.

To fix this, please rename the ‘VisualGDB’ platform in your project files to ‘x86’ or ‘Win32’ (depending on the VS version you are using).

We have also noticed that you are using CMake. VisualGDB 5.3 comes with a very powerful Advanced CMake Project Subsystem that basically creates a 2-way mapping between CMakeLists.txt files and the Solution Explorer (see this tutorial). We would advise switching to this subsystem (VisualGDB supports importing Embedded CMake projects) as it provides much better user experience with CMake.

[support]

Hi,

This could happen if your firmware was interfering with the SWD pins or power states, hence preventing the debugger from attaching. Please try setting the “connect under reset” flag in VisualGDB Project Properties -> Debug Settings.

[Author]

Posts