[support]

Hi,

We don’t support this board yet due to relatively low popularity. We will keep on monitoring its popularity and reconsider this once the board becomes more popular.

[support]

Hi,

Please double-check that your project includes a system_stm32xxxx.c file. It should either come from the code generated by STM32CubeMX or from the VisualGDB BSP directory (enabled by referencing ‘default system file’ framework on the Embedded Frameworks page of VisualGDB Project Properties).

[support]

Hi,

That should work. Another option would be to add “-x c++” to the CFLAGS to explicitly tell GCC to treat the file as a .cpp file.

[support]

Hi,

Thanks, looks like a bug on our side. We have updated our mbed package; please update it on your side via Tools->VisualGDB Package Manager.

[support]

Hi,

It looks like the replies sent via our support system don’t reach your email address, so please add ticket@sysprogs.com to your spam filter whiltelist.

Below is a copy of our last reply regarding ESP32-WROOM.

Unfortunately the general problem with ESP32 devices is that they are less reliable than ARM devices and don’t provide adequate diagnostic means, so we have to limit our support to a few popular devices that we could test on our side and a few very basic scenarios.

To make it easier to diagnose the problems that we cannot handle on our side, we made all our ESP8266/ESP32 support open-source: https://github.com/sysprogs/BSPTools/tree/master/DebugPackages/ESP8266DebugPackage

When VisualGDB programs an ESP32 firmware, it loads 3 regions of FLASH:

• The bootloader (at 0x1000)
• The partition table (at 0x8000)
• The image itself (typically at 0x10000)

You can find the related logic in ESP32StartupSequence.cs, line 180. If the program fails to start on the ESP32-WROOM module, it could be caused by one of the 3 reasons:

• The memory is not programmed correctly
• The bootloader configuration or the partition table is wrong
• The compiled program is doing something unsupported (e.g. it was compiled with no optimization and hence triggers a bug in the ESP-IDF)

In order to diagnose this, please try using the esptool.py to read the FLASH memory contents back to the disk and then compare it with the bootloader file, partition table file and the <program>-esp32.bin file. This should help understand if the programming itself succeeds.

If the programming succeeds, please try programming the version that works (e.g. the one built via ESP-IDF build scripts) and compare the bootloader and the partition table contents. If they are different, please try overriding them.

If both the bootloader and the partition table are the same, please send us the downloaded first 1024 bytes of FLASH memory at offset 0x10000 for both the version that works and then one that does not so we could quickly compare the ESP32 image headers and check if there is any obvious reason for this.

[support]

Hi,

Sorry, we tried reproducing it and could not get the problem to appear. Could you try reproducing it on a smaller project that you could archive and send to us?

[support]

Hi,

Sorry, could not reproduce this. The problem could easily be caused by a corrupt VS installation on one specific machine. Please try enabling the debug logging for the installer:

msiexec /l* visualgdb.log /i VisualGDB.msi

Then reproduce the problem and check for Visual Studio-related entries in the log file. This should explain what exactly is done by the installer.

[support]

Hi,

VisualGDB 5.2 should already be doing double-buffering for the parse data. I.e. while a file is being parsed, it will use the previous parse data to highlight local references and handle other similar functionality. The Ctrl-Space code completion should also work completely parallel to this. If you observe the opposite, please share the repro steps and the diagnostic log so that we could investigate this.

Ophidian14: we will try to include this feature in one of the early preview builds of v5.3. We will post an update here once it becomes available.

[support]

Hi,

For a 3rd-party toolchain you would need to manually specify “–specs=nosys.specs” via LDFLAGS to include the necessary libraries. The toolchains shipped by us have this flag conveniently mapped to a checkbox in the settings, but 3rd-party toolchains would require specifying it manually.

[support]

Hi,

VisualGDB does not have a free community edition. Please note that we only offer support to the users of our paid products like VisualGDB. To get general Qt-related support, please try asking on the Qt forums.

[support]

Hi,

Please let us know which edition of VisualGDB you are using.

[support]

Hi,

Those are actually 2 different processes. The long one-time indexing (that uses all CPU cores) happens one time after you import a project and builds a large database of all cross-references in your code, so you can instantly execute commands like “Find all references”. The 7169 msec check mentioned in the log file above only checks one single source file and should normally happen in the background and not cause any delays (as long as you are using v5.2, code completion and other IntelliSense functionality can run in parallel with the long “Parse – Check” operation).

[support]

The bootstrap script (and other autotools) don’t work very well on Windows.

We would recommend getting a checkout of our OpenOCD fork that uses CMake and manually merging it with the latest code from the main OpenOCD repository. We will also do that on our side in the next couple of weeks, so you can simply wait for that.

[support]

Strange. Can you confirm that just installing VisualGDB again solves the problem?

[support]

Hi,

Oops. Sorry about that. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1467.msi

[Author]

Posts