[support]

Hi,

Strange. We tried the example above and ESP-IDF failed to parse it (100000 and 180000 are valid decimal values as well, but 1FFE000 caused it to crash). If it doesn’t fail in your msys32 environment, please double-check that you are using the same versions of ESP-IDF (perhaps it has already been fixed in the master branch of ESP-IDF).

[support]

Hi,

Thanks for the detailed description. We are planning to support the display of the function definition (not just declaration) in the popup hints in one of the next VisualGDB releases (currently you can view the declaration, call graph, references and code/data relations). We will post an update here once this is supported.

[support]

Hi,

Thanks for the very detailed description. We have rechecked this and it indeed looks like the logic for handling the ranges for hex entries still expects decimal values.

This is logic, however, is a part of the ESP-IDF itself and is unfortunately outside of VisualGDB’s control. Please consider submitting a bugreport in the ESP-IDF bugtracker for this.

The range checking is indeed not yet supported by VisualGDB, sorry. We will try to add it in one of the next releases, although we have a few other features queued (e.g. ESP32 unit test integration) ahead of that.

[support]

Hi,

Thanks for the email address update. We have linked the new email address to your forum profile.

Regarding the problem, is looks like you are missing the “0x” prefix (e.g. see how PARTITION_TABLE_OFFSET is defined in esp-idf\v3.1\components\partition_table\Kconfig.projbuild).

[support]

Hi,

Yes, please select “Import an existing project” -> “Project is built with command-line tools” in the Linux Project Wizard, then point VisualGDB at the directory you would like to synchronize and set a dummy build command line (e.g. “echo done”). Finally, reference the pseudo-project from the regular project so that it will get built before the regular project, and VisualGDB will synchronize the files for you.

[support]

Hi,

Thanks for checking this. It indeed looks like your J-Trace is using a USB ID that is not listed in the regular J-Link driver files and hence not being recognized by VisualGDB.

You can work around this by adding the following entry to %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\edp.xml:
<UsbIdentity>
  <VID>1366</VID>
  <PID>0120</PID>
</UsbIdentity>

Let us know if this works and we will update the file on our end.

[support]

Hi,

Most likely, you are referencing files from a directory that is not uploaded to the Linux side (VisualGDB will normally only upload the files from the project directory).

You can configure VisualGDB to upload additional directories via VisualGDB Project Properties -> Custom Build Steps or Synchronized Directories (Custom edition), or by creating a separate pseudo-project for the secondary directory you want to transfer (Linux edition). The pseudo-project should have no actual build action and will only be used to transfer the additional directory during build.

[support]

Hi,

This might be triggered by some Qt-level configuration settings. Are you using the stock Qt library installed via apt-get, or have you built it from scratch?

Either way, please try browsing through the Qt examples and locating an example with similar functionality. Then:

• Try building it on the device (without VisualGDB at all).
• Try importing it into VisualGDB and building/debugging it.
• Try creating a new VisualGDB project with the default flags and then copying the sources from that sample to it.

If you encounter different behavior between some of the setups mentioned above, try analyzing the differences between them.

You can find the exact command used by VisualGDB to run/debug the app via View->Other Windows->VisualGDB Diagnostics Console. You can also use VisualGDB Project Properties -> Debug Settings to configure VisualGDB to display the GUI on the Raspberry Pi desktop instead of forwarding it via XMing.

You could also try running the app via SmarTTY – it uses the same X11 redirection logic as VisualGDB, but won’t run the app under debugger.

[support]

Hi,

Thanks for reporting this, looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2645.msi

[support]

Hi,

Sorry for the confusion. The screenshot looks like J-Trace is actually recognized (it is shown as J-Link due to backward compatibility). Do you mean that you would expect it to be shown as “J-Trace”, not “J-Link”, or do you have both J-Trace and J-Link plugged in at the same time? In the latter case, what is the USB VID/PID of J-Trace?

[support]

Hi,

In order to debug chibios threads with VisualGDB, you would need to create a thread plugin as described in this tutorial.

Once the plugin is loaded into VisualGDB, it will show the threads the same way it currently shows FreeRTOS and RTX threads.

[support]

Hi,

VisualGDB automatically uses the compilers from the <Keil installation directory>\ARMCC and <Keil installation directory>\ARMClang. As long as you install the updates in those directories, VisualGDB will automatically pick them up.

We have reproduced the problem with the “$$com.sysprogs.bspoptions.primary_memory$$” macro and fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2642.msi

Please ensure that you generate a Keil project from STM32CubeMX, not a GPDSC project, and that you select the Keil compiler in the Keil importer settings (first page of VisualGDB Project Wizard).

If the SVD files does not contain the register, VisualGDB won’t be able to display it as it takes the register definitions from the Keil-supplied SVD files. Please consider editing the file to add any extra registers that you would like to view with VisualGDB.

The tutorial we mentioned describes how to diagnose embedded firmware getting stuck without the debugger attached. The steps described there do not depend on a specific compiler type, so you should be able to use it with the Keil compiler as well as with GCC. Simply attach to the project to see where exactly.

[support]

Hi,

Please try updating the Segger debug plugin via Tools->VisualGDB->Manage VisualGDB Packages.

If this doesn’t help, please attach a screenshot of the settings page with the missing settings.

[support]

Hi,

No problem. Most likely VisualGDB cached some older version of the member list and was displaying it instead. This could be caused by incorrect clock settings (VisualGDB uses timestamps to determine which parts of the IntelliSense cache need to be updated), or cache corruption. Either way, closing the solution and deleting the CodeDB folder should normally clear the IntelliSense cache and resolve this type of problem.

If you encounter it again, please let us know the repro steps and we will reinvestigate this.

[support]

Hi,

The register definitions when using the Keil compiler are taken from the SVD files shipped with Keil. E.g. for the STM32F407ZG that would be Keil_v5\ARM\PACK\Keil\STM32F4xx_DFP\<version>\CMSIS\SVD\STM32F40x.svd. If you believe the files are missing some registers, please double-check it with Keil support, as they supply the files.

[Author]

Posts